[
https://issues.apache.org/jira/browse/QPID-6840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15004241#comment-15004241
]
Rob Godfrey commented on QPID-6840:
-----------------------------------
{quote}
{{WebSocketProvider}} does not interleave. Do WebSockets not suffer from the
same issue as NonBlockingConnections?
{quote}
Not in a way that we are made aware of - for us the writing of data to the
websocket appears as a synchronous call. Obviously underneath Jetty is having
to do something with the network writes, but this is not exposed.
{quote}
Before we {{doRead()}} we used to call
{{setTransportBlockedForWriting(!doWrite())}}. Now you unconditionally call
{{setTransportBlockedForWriting(false)}} even though it is likely that we do
have stuff to write in our buffers.
{quote}
It's *possible* we'll have something in our buffers, but no more than half the
writeBuffer size. As such it's reasonable to allow more writes such that the
buffer fills up for greater efficiency. In practice writes which doRead should
be small (-ok resposnses), with the exceptions (recover, 0-10 flush) likely to
cause issues in any case (the extra half a buffer we may be carrying in to the
process is unlikely to cause any issues). To be honest I'm not sure what value
the call before the doRead has anyway as messageDelivery is suspended while we
are in doRead
{quote}
And here comes the comment you do not want to hear: doWork() has grown far
longer and more deeply nested than what is healthy for a method. Maybe some
refactoring is in place?
{quote}
Agree, though I'd also like to try to see some of the commonality between this
code and what is in WebSockets be factored out too. I think this will be a
post v6 job.
Other comments I agree on and will action
> [Java Broker] Interleave calls to processPending with attempts to write
> outstanding data
> ----------------------------------------------------------------------------------------
>
> Key: QPID-6840
> URL: https://issues.apache.org/jira/browse/QPID-6840
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Rob Godfrey
> Assignee: Lorenz Quack
> Fix For: qpid-java-6.0
>
>
> Currently NonBlockingConnection.doWork() completes all "pending" work before
> attempting a write, and then processes incoming network reads.
> Instead we should ensure that once we have enough data to fill the send
> buffer, we should perform a network write. If we cannot write out enough
> data to the wire, we should stop processing pending work (which will
> consuming direct memory which cannot be reclaimed until the buffers are
> written).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
