On 01/07/2020 3:31 pm, Ivo Wever wrote:
Hi,

I have a setup that results in the following wire messages being sent
(recorded using wireshark), where the first column is a timestamp, the
second a direction and third one or more wire frames:

0.00 > Protocol-Header 1-0-0 open begin attach attach
0.68 < Protocol-Header 1-0-0 open begin attach attach flow
0.68 > flow transfer
0.70 < flow disposition
0.70 < transfer
0.70 > flow
8.21 > transfer
8.23 < flow disposition
8.23 < transfer

What I am trying to figure out is why there is a delay between the
transfer that is received at 0.70 and the transfer that is sent at 8.21,
because the 'sender.send(payload)' was called very shortly after 0.70.

After the initial quick back-and-forth, it seems to consistently take
~7.5 seconds before a 'sender.send(payload)' results in an actual
transfer (you can consider the above sequence as extending further with
the same pattern if that). That is also the moment at which an
'on_sendable' is triggered on the handler.

This is using the Ruby version of Qpid Proton 0.30.0. The disposition
messages are all 'accepts', the flow messages all indicate more messages
are welcome. What could be going on here? It's not the sending process
is busy: it's looping over a 200ms sleep while waiting for the response
to arrive (though as it happens it's actually mostly waiting for the
request to be sent, after which the response promptly arrives)

Does anyone have a clue for what may be going on here?

I don't know anything about the ruby binding specifically, but it is an event driven, single threaded api. If you are doing any sleep in a proton callback you are preventing the event thread from performing any work.

(You could try the simple_send.rb example to make sure there isn't something generically strange going on).


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Reply via email to