Re: [jira] [Created] (PROTON-564) Messenger.work doesn't receive messages

2014-04-16 Thread Fraser Adams
I must admit that I thought that recv was always necessary for what you are 
doing, am I not correct that the python version of recv has an option with no 
parameter (the one that use use in your XXX block) where the documentation says 
something like if no Message instance is passed to recv then is just pops the 
message of the internal queue and discards it.

Sent from my iPad

On 16 Apr 2014, at 14:45, Justin Ross (JIRA) j...@apache.org 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:5)
 
msg = Message()
 
while True:
print Tick; incoming={}.format(msgr.incoming)
 
msgr.work()
# msgr.recv() XXX
 
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:5/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)


Re: [jira] [Created] (PROTON-564) Messenger.work doesn't receive messages

2014-04-16 Thread Fraser Adams
Sorry Justin, I was thinking of get in my last mail, though I think when I've 
done consumers using messenger I call recv once during initialisation and then 
call get to retrieve the actual messages.

I've never found the correct workflow to use especially obvious though and I've 
largely made it up as I went along ;-)

Sent from my iPad

On 16 Apr 2014, at 14:45, Justin Ross (JIRA) j...@apache.org 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:5)
 
msg = Message()
 
while True:
print Tick; incoming={}.format(msgr.incoming)
 
msgr.work()
# msgr.recv() XXX
 
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:5/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)


Re: [jira] [Created] (PROTON-564) Messenger.work doesn't receive messages

2014-04-16 Thread Fraser Adams
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) j...@apache.org 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:5)
 
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:5/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)