[
https://issues.apache.org/jira/browse/PROTON-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094565#comment-14094565
]
clebert suconic commented on PROTON-645:
----------------------------------------
Of course it could be the case that pop asynchronous is just broken. There are
0 tests doing it asynchronously right now.
> Implement session flow control independently of transport.capacity
> ------------------------------------------------------------------
>
> Key: PROTON-645
> URL: https://issues.apache.org/jira/browse/PROTON-645
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
> Reporter: clebert suconic
>
> When integrating with any asynchronous IO we are obligated to implement flow
> control based on the capacity of the Transport.
> Things get especially harder because when you pop bytes in a asynchronous
> method for after completion:
> e.g. on Netty:
> channel.writeAndFlush(bytes).addListener(new ChannelFutureListener()
> {
> @Override
> public void operationComplete(ChannelFuture future) throws Exception
> {
> transport.pop(bufferSize);
> /// perform process, and dispatch!
> performDispatchEtc();
> if (transport.capacity() > 0)
> {
> channel.read();
> }
> }
> });
> this makes things specially harder as we are eventually losing events or
> bytes. We could make things work with some hacks (like having recursive loops
> on the methods for writing and reading)...
> Making Proton-J to work with asynchronous pop is definitely a black art.
> Instead of working around with recursive workarounds we should provide an
> easier path. such as plugging SessionFlowController where we could activate /
> deactivate producers on a server, or use Semaphores on a client where a
> client could block until things are properly released.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
