[jira] [Closed] (PROTON-2189) proactor C client has abnormally long pauses during message send

["Ken Giusti (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/PROTON-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Giusti closed PROTON-2189.
------------------------------
      Assignee: Ken Giusti
    Resolution: Not A Bug

This is not a bug in proactor, but it is a bug in the client application.

The client uses pn_proactor_set_timeout() to generate a PN_PROACTOR_TIMEOUT event.  During processing of that event the client invokes pn_link_send().

The bug is that the PN_PROACTOR_TIMEOUT is not a connection-scoped event - it is only scoped to the proactor.  In fact the event instance passed to the handler does not contain a reference to any connection (by design).

The client gets around this by storing the connection and link pointers in global variables (only 1 connection and link is created by the client).  It then references these pointers from within the PN_PROACTOR_TIMEOUT handler.  Since the pn_link_send is not called from within the connection's context proactor is not aware that work is pending for the connection once control returns to proactor's event loop (it will eventually get serviced, but not immediately on return to proactor).

The correct approach would be to schedule work on the link's connection by calling pn_connection_wake() from within the PN_PROACTOR_TIMEOUT handler.  This will cause a PN_CONNECTION_WAKE event to be generated with the correct connection context.  pn_link_send() can be called during the PN_CONNECTION_WAKE handler and will schedule the connection to be serviced when control is returned to the proactor event loop.

 

> proactor C client has abnormally long pauses during message send
> ----------------------------------------------------------------
>
>                 Key: PROTON-2189
>                 URL: https://issues.apache.org/jira/browse/PROTON-2189
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: proton-c
>    Affects Versions: proton-c-0.30.0
>         Environment: To compile the clients install qpid-proton-c-devel and simply compile:
> gcc  -O2 -g -Wall -lqpid-proton -lm -o clogger clogger.c
> To reproduce my test, build qdrouterd and run it in the background.
> You need to have a consumer attached.  There is a test receiver client in the qdrouterd build in <build-dir>/tests/test-receiver.  This receiver is designed to handle streaming messages (by default sent to 'test-address')
> Run the consumer in the background then run each clogger (default params are fine).
> You should observe that clogger-reactor runs smoothly (use PN_TRACE_FRM=1 on qdrouterd as well).
> You'll see clogger-reactor send the message header, then nothing for awhile, then send the entire message. 
> Use "-D" for debug output to see how many bytes have been written to pn_link_send()
>            Reporter: Ken Giusti
>            Assignee: Ken Giusti
>            Priority: Major
>         Attachments: 0001-tweak-clogger-to-fix-streaming.patch, clogger-proactor.c, clogger-reactor.c
>
>
> I have a proactor-based C test client that has the ability to slowly send extremely large messages slowly.  This is done by sending 'chunks' of body data with pauses in between.
> This client was designed to test large streaming messages against qdrouterd.
> The behavior of this client is unexpected - I would expect the message data to appear "on the wire" in bursts relatively quickly.  In reality the data is buffered - in some cases over 1 GB is buffered - before it is written (as indicated by the lack @transfer frames dumped by the client AND the qdrouterd).  In some cases it takes up to 30 seconds before the client's data starts being written to the client.
> I've refactored the client to use reactor instead and the data flows as expected.  There is minimal buffering and no abnormally long pauses.
> The clients are attached.
> It is quite likely the proactor client is incorrectly implemented, but I used the qdrouterd I/O loop as the model and cannot see what may be wrong.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org