Bug 805500

Summary: HornetQ failover triggers redeploy
Product: [JBoss] JBoss Enterprise SOA Platform 5 Reporter: Filip Nguyen <fnguyen>
Component: JBoss HornetQAssignee: trev <tkirby>
Status: NEW --- QA Contact:
Severity: urgent Docs Contact:
Priority: urgent    
Version: 5.3.0 GACC: dlesage, jbertram, ldimaggi, mvecera, rwagner, smcgowan, soa-p-jira
Target Milestone: ER2Keywords: TestBlocker
Target Release: 5.3.0 GA   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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:
Cloudforms Team: ---
Attachments:
Description Flags
logs from both nodes none

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