Bug 805500 - HornetQ failover triggers redeploy
HornetQ failover triggers redeploy
Status: NEW
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: JBoss HornetQ (Show other bugs)
5.3.0 GA
Unspecified Unspecified
urgent Severity urgent
: ER2
: 5.3.0 GA
Assigned To: trev
: TestBlocker
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-21 09:44 EDT by Filip Nguyen
Modified: 2015-03-12 07:24 EDT (History)
7 users (show)

See Also:
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.
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description Filip Nguyen 2012-03-21 09:44:41 EDT
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 11:26:35 EDT
Associated JIRA https://issues.jboss.org/browse/JBPAPP-8707
Comment 2 Suz 2012-06-14 19:32:23 EDT
    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 08:14:30 EDT
    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-17 20:13:14 EDT
    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 11:56:56 EDT
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.