[
https://issues.apache.org/jira/browse/PROTON-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094563#comment-14094563
]
clebert suconic commented on PROTON-645:
----------------------------------------
*Producer = I'm describing this term here as something producing bytes...
By this I mean.. the server would stop sending anything to the proton
connection when the flow controller is busy. This way we would have things not
being generated instead of flooding the Queues on Connection.
> 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)
