Sorry, me again -curse being on an iPad, if you try the msg.recv bit before 
your while True loop block I.e. do it once during initialisation, the the work 
should (probably) be enough during the loop

Sent from my iPad

On 16 Apr 2014, at 14:45, "Justin Ross (JIRA)" <[email protected]> wrote:

> Justin Ross created PROTON-564:
> ----------------------------------
> 
>             Summary: Messenger.work doesn't receive messages
>                 Key: PROTON-564
>                 URL: https://issues.apache.org/jira/browse/PROTON-564
>             Project: Qpid Proton
>          Issue Type: Bug
>    Affects Versions: 0.6, 0.7
>         Environment: Fedora 19, Python 2.7.5
>            Reporter: Justin Ross
> 
> 
> Sink:
> 
> {noformat}
> from proton import Messenger, Message
> 
> msgr = Messenger()
> msgr.start()
> 
> try:
>    msgr.subscribe("amqp://~0.0.0.0:50000")
> 
>    msg = Message()
> 
>    while True:
>        print "Tick; incoming={}".format(msgr.incoming)
> 
>        msgr.work()
>        # msgr.recv() XXX
> Caused by: java.net.BindException: Address already in use
>    at java.net.PlainSocketImpl.socketBind(Native Method)
>        for i in range(msgr.incoming):
>            msgr.get(msg)
>            print(msg)
> finally:
>    msgr.stop()
> {noformat}
> 
> Source:
> 
> {noformat}
> from proton import Messenger, Message
> 
> msgr = Messenger()
> msgr.start()
> 
> try:
>    msg = Message()
>    msg.address = "amqp://0.0.0.0:50000/test"
> 
>    for i in range(10):
>        print "Tick {}".format(i)
> 
>        msg.body = "Message {}".format(i)
> 
>        msgr.put(msg)
>        msgr.send()
> finally:
>    msgr.stop()
> {noformat}
> 
> On 0.6, it blocks on one of the work calls with incoming always 0.  On 0.7, 
> it keeps looping through work calls with incoming always 0.  The source sends 
> nothing.
> 
> Note the XXX bit in the sink.  If you uncomment that.  The sink consumes the 
> messages.
> 
> The python API documentation says the following:
> 
> {noformat}
> Sends or receives any outstanding messages queued for a Messenger. This will 
> block for the indicated timeout. This method may also do I/O work other than 
> sending and receiving messages. For example, closing connections after 
> messenger.stop() has been called.
> {noformat}
> 
> Based on that, I expect that I should not need to call recv.
> 
> 
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.2#6252)

Reply via email to