Bug 805500
| Summary: | HornetQ failover triggers redeploy | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise SOA Platform 5 | Reporter: | Filip Nguyen <fnguyen> | ||||
| Component: | JBoss HornetQ | Assignee: | Nobody <nobody> | ||||
| Status: | NEW --- | QA Contact: | |||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | urgent | ||||||
| Version: | 5.3.0 GA | CC: | jbertram, ldimaggi, mvecera, rwagner, soa-p-jira | ||||
| Target Milestone: | ER2 | Keywords: | 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: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Associated JIRA https://issues.jboss.org/browse/JBPAPP-8707
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.
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.
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.
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 |
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.