[
https://issues.apache.org/jira/browse/QPID-7178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Loberg updated QPID-7178:
------------------------------
Attachment: AMQP Sequence.png
AMQP Sequence.txt
I have analyzed a tcpdump output of the sequence. A text version with relevant
(anonymized) AMQP data is attached along with a sequence diagram generated from
the text version.
The JMS client is connected before the sequence start and remains connected
afterwards.
One speculation is that our Python client does things in the wrong order by
doing:
1. Connect
2. Create auto-delete queue for responses
3. Send message
4. Create receiver on response queue
5. Wait for messages on response queue
If the JMS client is able to send its response between 3 and 4 it seems like
the broker will delete the queue, even if the Python client that created it
still have its connection open (but is not using the queue).
> Auto-delete queue removed while it has consumers
> ------------------------------------------------
>
> Key: QPID-7178
> URL: https://issues.apache.org/jira/browse/QPID-7178
> Project: Qpid
> Issue Type: Bug
> Components: Java Client, Python Client
> Reporter: Paul Loberg
> Attachments: AMQP Sequence.png, AMQP Sequence.txt
>
>
> We seem to have run into a bug where we create a queue with auto-delete=true
> from Python and then send to it using the JMS client. When the JMS
> MessageProducer is closed the queue is removed even if the Python client is
> still consuming from it.
> We first create the queue from Python (qpid-python 0.32, Python 2.7) and send
> a message to another queue "foo-bar" with the newly created auto-delete queue
> as the reply-to address. The connection and session is kept open until a
> response is received.
> A very cut down version of the Python code is below. The client will call
> create_queue, send_request and then await_response and in await_response we
> then (9 out of 10 times) get:
> {noformat}
> File "client.py", line NN, in await_response
> receiver = self._session.receiver(self._queue_name)
> File "<string>", line 6, in receiver
> File "/usr/lib/python2.7/site-packages/qpid/messaging/endpoints.py", line
> 653, in receiver
> receiver.close()
> File "<string>", line 6, in close
> File "/usr/lib/python2.7/site-packages/qpid/messaging/endpoints.py", line
> 1114, in close
> if not self.session._ewait(lambda: self.closed, timeout=timeout):
> File "/usr/lib/python2.7/site-packages/qpid/messaging/endpoints.py", line
> 597, in _ewait
> self.check_error()
> File "/usr/lib/python2.7/site-packages/qpid/messaging/endpoints.py", line
> 586, in check_error
> raise self.error
> qpid.messaging.exceptions.NotFound: not-found: Queue not found:
> 17980224d7004b88b503a71c0c471bfa
> (/var/tmp/portage/net-misc/qpid-cpp-0.34/work/qpid-cpp-0.34/src/qpid/broker/QueueRegistry.cpp:127)(404)
> {noformat}
> {code}
> from qpidtoollibs import BrokerAgent
> ...
> def create_queue(self):
> queue_name = self._queue_name = uuid.uuid4().get_hex()
> agent = BrokerAgent(self._connection)
> declargs = {"auto-delete": "true"}
> agent.addQueue(queue_name, declargs)
> def send_request(self, content_dict):
> sender = self._session.sender(self._foo_queue_name)
> try:
> message = Message(content=json_content, reply_to=self._queue_name)
> sender.send(message)
> finally:
> sender.close()
> def await_response(self, timeout_secs):
> receiver = self._session.receiver(self._queue_name)
> msg = receiver.fetch(timeout=timeout_secs)
> return msg
> {code}
> On the Java side we connect using JMS (0.8.0) and wait for a message to
> arrive in the "foo-bar" queue. Once it does it will create a MessageProducer
> using the reply-to Destination object (from the incoming
> Message.getJMSReplyTo) and send a response back, but when that
> MessageProducer is closed the auto-delete queue seems to be removed even if
> we have the Python client connected to it.
> A very simplified version of the Java code:
> {code:java}
> class BrokerConnection implements MessageListener {
> Connection connection;
> Session session;
> MessageConsumer messageConsumer;
> public BrokerConnection(ConnectionFactory connectionFactory) {
> connection = connectionFactory.createConnection();
> session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> Destination queue = session.createQueue("foo-bar");
> messageConsumer = session.createConsumer(queue);
> messageConsumer.setMessageListener(this);
> connection.start();
> }
> public void onMessage(Message message) {
> Destination clientQueue = message.getJMSReplyTo();
> try (MessageProducer prod = session.createProducer(clientQueue)) {
> BytesMessage msg = session.createBytesMessage();
> msg.writeBytes(message.unwrap());
> prod.send(msg);
> } // implicit prod.close()
> }
> }
> {code}
> The issue seems to be timing sensitive. It works more often if running on a
> slow machine (i.e. a virtual machine with limited resources) or if a debugger
> is attached to the JVM causing that to slow down.
> From this behavior we suspect a bug in the Java/JMS client code messing with
> the consumer count in the broker.
> Please let us know if we can provide more details to track down this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
