qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Viktor Horvath (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (QPID-6740) Message not delivered after "empty" exception
Date Wed, 16 Sep 2015 22:39:46 GMT

     [ 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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message