I'm doing some failover testing for various services of ours that are using QPID. We need to handle failover ourselves so our connection listener returns false to veto qpid's failover and then we go on to re-establish our connection and then re-initialize all of our sessions, producers and consumers.
In my current test I'm just killing the broker, waiting a few second, and starting it back up again.
During re-initialization, everything comes back fine except for queues of the form:
UUID/None; {
'assert': 'always',
'create': 'receiver',
'delete': 'receiver',
'node': {
'type': 'queue',
'x-declare': {
'auto-delete': 'true'
Where UUID is a UUID for the queue name.
When trying to create a consumer for a queue of the above form I get this error:
javax.jms.JMSException: Error registering consumer: org.apache.qpid.AMQException: ch=0 id=0 ExecutionException(errorCode=NOT_FOUND, commandId=12, classCode=4, commandCode=7, fieldIndex=0, description=not-found: Queue not found: d4c94463-dac9-4219-88ef-cb917249a523 (qpid/broker/SessionAdapter.cpp:686), errorInfo={}) [error code 404: not found]
at org.apache.qpid.client.AMQSession.toJMSException(AMQSession.java:3494)
at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:2039)
at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1)
at org.apache.qpid.client.AMQConnectionDelegate_0_10.executeRetrySupport(AMQConnectionDelegate_0_10.java:371)
at org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:624)
at org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
at org.apache.qpid.client.AMQSession.createConsumerImpl(AMQSession.java:2047)
at org.apache.qpid.client.AMQSession.createConsumer(AMQSession.java:939)
...
This doesn't make sense since I'm resolving the queue as a receiver and the receiver should create the queue if it doesn't exist. I've tried with "create: always" just to see what would happen and I still get the same error.
If I re-name the queue before making the consumer then everything works fine. Any ideas why I have to re-name the queue after failover? Renaming the queue is fine for these UUID guys but may present a problem for queues whose names aren't supposed to change.
Matt Crinklaw-Vogt
Lockheed Martin, MS2
703-367-1040
In my current test I'm just killing the broker, waiting a few second, and starting it back up again.
During re-initialization, everything comes back fine except for queues of the form:
UUID/None; {
'assert': 'always',
'create': 'receiver',
'delete': 'receiver',
'node': {
'type': 'queue',
'x-declare': {
'auto-delete': 'true'
Where UUID is a UUID for the queue name.
When trying to create a consumer for a queue of the above form I get this error:
javax.jms.JMSException: Error registering consumer: org.apache.qpid.AMQException: ch=0 id=0 ExecutionException(errorCode=NOT_FOUND, commandId=12, classCode=4, commandCode=7, fieldIndex=0, description=not-found: Queue not found: d4c94463-dac9-4219-88ef-cb917249a523 (qpid/broker/SessionAdapter.cpp:686), errorInfo={}) [error code 404: not found]
at org.apache.qpid.client.AMQSession.toJMSException(AMQSession.java:3494)
at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:2039)
at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1)
at org.apache.qpid.client.AMQConnectionDelegate_0_10.executeRetrySupport(AMQConnectionDelegate_0_10.java:371)
at org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:624)
at org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
at org.apache.qpid.client.AMQSession.createConsumerImpl(AMQSession.java:2047)
at org.apache.qpid.client.AMQSession.createConsumer(AMQSession.java:939)
...
This doesn't make sense since I'm resolving the queue as a receiver and the receiver should create the queue if it doesn't exist. I've tried with "create: always" just to see what would happen and I still get the same error.
If I re-name the queue before making the consumer then everything works fine. Any ideas why I have to re-name the queue after failover? Renaming the queue is fine for these UUID guys but may present a problem for queues whose names aren't supposed to change.
Matt Crinklaw-Vogt
Lockheed Martin, MS2
703-367-1040