[
https://issues.apache.org/jira/browse/QPID-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viktor Horvath updated QPID-6740:
---------------------------------
Description:
If this is not a bug, the documentation might need an update, as I'm not aware
of what I did wrong.
Here is a test case, you will need two ipython consoles.
{code:title=console 1}
from qpid.messaging import Connection
session = Connection.establish('amqp://127.0.0.1').session()
sender = session.sender(
'mytestqueue; {create: always, node: {durable: True, type: queue}}')
cleaner = session.receiver('mytestqueue')
cleaner.fetch(timeout=0) # will raise a qpid.messaging.exceptions.Empty
{code}
(The receiver is named _cleaner_ because it is only supposed to "free" the
queue from any old messages.)
{code:title=console 2}
from qpid.messaging import Connection
session = Connection.establish('amqp://127.0.0.1').session()
receiver = session.receiver('mytestqueue')
receiver.fetch()
{code}
Back to the first console:
{code:title=console 1}
sender.send({'msg': 'test'})
{code}
*This message does not arrive at the second console. The receiver.fetch() still
blocks.*
I have the following observations about this situation:
# One workaround is to call cleaner.close(), the blocking receiver will
immediately return the message.
# Another workaround is to specify a time-out in the receiver.fetch() call
(test it with timeout=60). The message will be returned, though only at the end
of the time-out!
# Sending a second message will result in immediate delivery of the first
message.
# Once the situation is unblocked, you have to start anew in order to
experience the blocking situation again. Don't forget to call
session.acknowledge() before ending the console 2, or use a fresh queue.
# The problem only manifests itself when receiver.fetch() starts before the
message is sent.
was:
If this is not a bug, the documentation might need an update, as I'm not aware
of what I did wrong :-)
Here is a test case, you will need two ipython consoles.
{code:title=console 1}
from qpid.messaging import Connection
session = Connection.establish('amqp://127.0.0.1').session()
sender = session.sender(
'mytestqueue; {create: always, node: {durable: True, type: queue}}')
cleaner = session.receiver('mytestqueue')
cleaner.fetch(timeout=0) # will raise a qpid.messaging.exceptions.Empty
{code}
(The receiver is named _cleaner_ because it is only supposed to "free" the
queue from any old messages.)
{code:title=console 2}
from qpid.messaging import Connection
session = Connection.establish('amqp://127.0.0.1').session()
receiver = session.receiver('mytestqueue')
receiver.fetch()
{code}
Back to the first console:
{code:title=console 1}
sender.send({'msg': 'test'})
{code}
*This message does not arrive at the second console. The receiver.fetch() still
blocks.*
I have the following observations about this situation:
# One workaround is to call cleaner.close(), the blocking receiver will
immediately return the message.
# Another workaround is to specify a time-out in the receiver.fetch() call
(test it with timeout=60). The message will be returned, though only at the end
of the time-out!
# Sending a second message will result in immediate delivery of the first
message.
# Once the situation is unblocked, you have to start anew in order to
experience the blocking situation again. Don't forget to call
session.acknowledge() before ending the console 2, or use a fresh queue.
# The problem only manifests itself when receiver.fetch() starts before the
message is sent.
> Message not delivered after "empty" exception
> ---------------------------------------------
>
> Key: QPID-6740
> URL: https://issues.apache.org/jira/browse/QPID-6740
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker, Python Client
> Affects Versions: 0.32
> Environment: CentOS 7.1
> qpid (C++) 0.32, qpid-python 0.32
> Reporter: Viktor Horvath
>
> If this is not a bug, the documentation might need an update, as I'm not
> aware of what I did wrong.
> Here is a test case, you will need two ipython consoles.
> {code:title=console 1}
> from qpid.messaging import Connection
> session = Connection.establish('amqp://127.0.0.1').session()
> sender = session.sender(
> 'mytestqueue; {create: always, node: {durable: True, type: queue}}')
> cleaner = session.receiver('mytestqueue')
> cleaner.fetch(timeout=0) # will raise a qpid.messaging.exceptions.Empty
> {code}
> (The receiver is named _cleaner_ because it is only supposed to "free" the
> queue from any old messages.)
> {code:title=console 2}
> from qpid.messaging import Connection
> session = Connection.establish('amqp://127.0.0.1').session()
> receiver = session.receiver('mytestqueue')
> receiver.fetch()
> {code}
> Back to the first console:
> {code:title=console 1}
> sender.send({'msg': 'test'})
> {code}
> *This message does not arrive at the second console. The receiver.fetch()
> still blocks.*
> I have the following observations about this situation:
> # One workaround is to call cleaner.close(), the blocking receiver will
> immediately return the message.
> # Another workaround is to specify a time-out in the receiver.fetch() call
> (test it with timeout=60). The message will be returned, though only at the
> end of the time-out!
> # Sending a second message will result in immediate delivery of the first
> message.
> # Once the situation is unblocked, you have to start anew in order to
> experience the blocking situation again. Don't forget to call
> session.acknowledge() before ending the console 2, or use a fresh queue.
> # The problem only manifests itself when receiver.fetch() starts before the
> message is sent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
