Bug 805500 - HornetQ failover triggers redeploy
Summary: HornetQ failover triggers redeploy
Keywords:
Status: NEW
Alias: None
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: JBoss HornetQ
Version: 5.3.0 GA
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ER2
: 5.3.0 GA
Assignee: Nobody
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-21 13:44 UTC by Filip Nguyen
Modified: 2023-05-31 23:39 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
In failover situations, HornetQ triggers a redeployment of queues. (The affected queues are those deployed inside ESB archives.) However, this redeployment process results in "already deployed" exceptions.
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)
logs from both nodes (1015.40 KB, application/zip)
2012-03-21 13:44 UTC, Filip Nguyen
no flags Details

Description Filip Nguyen 2012-03-21 13:44:41 UTC
Created attachment 571710 [details]
logs from both nodes

When running in Colocated mode and one server is shut down the other one is trying to redeploy queues resulting in exceptions: 

09:26:19,354 ERROR [org.hornetq.core.deployers.impl.XmlDeployer] Unable to deploy node [queue: null] JbpmTimerQueue
javax.naming.NamingException: queue/JbpmTimerQueue already has an object bound
        at org.hornetq.jms.server.impl.JMSServerManagerImpl.checkJNDI(JMSServerManagerImpl.java:1424)


This happens for all queues that are deployed inside of *esb archives.

Comment 1 Rick Wagner 2012-04-13 15:26:35 UTC
Associated JIRA https://issues.jboss.org/browse/JBPAPP-8707

Comment 2 Suz 2012-06-14 23:32:23 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
When a HornetQ failover was implemented, it would trigger a redeployment. This occurred when using the Colocated mode. When one server was shut down, the other one attempted to redeploy queues resulting in exceptions.

Comment 3 Filip Nguyen 2012-06-15 12:14:30 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-When a HornetQ failover was implemented, it would trigger a redeployment. This occurred when using the Colocated mode. When one server was shut down, the other one attempted to redeploy queues resulting in exceptions.+In failover situation the HornetQ failover triggers a redeployment of queues. The affected queues were those deployed inside of the *esb archives. This redeployment resulted into "already deployed" exceptions.

Comment 4 David Le Sage 2012-06-18 00:13:14 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-In failover situation the HornetQ failover triggers a redeployment of queues. The affected queues were those deployed inside of the *esb archives. This redeployment resulted into "already deployed" exceptions.+In failover situations, HornetQ triggers a redeployment of queues. (The affected queues are those deployed inside ESB archives.) However, this redeployment process results in "already deployed" exceptions.

Comment 6 Rick Wagner 2013-03-22 15:56:56 UTC
Hello Filip,

This issue is currently under analysis.  Could you please tell us if the SOA-P instances are unaffected, other than the ERROR messages?  (That is, if the ERROR messages were ignored, would there be any ill effect?)

Please consider, let us know.  If it will take some time for analysis (replication), please let us know this also.

Thank you,

Rick


Note You need to log in before you can comment on or make changes to this bug.