| Re: [jetty-dev] Websocket buffers and async modes |
I’m sorry for jumping in, but this is not 100% true ;) The aggregation does indeed happen for write(byte[]) but not for write(ByteBuffer). I’ve sent an email to the list some time in the past and I was almost sure I had opened a bug on bugs.eclipse, but now I can’t find it. It’s late now, and I’ll search again tomorrow, but basically a write(ByteBuffer) will never aggregate, and hence why my local copy has this patch: https://gist.github.com/davipt/7155109 Please advice how to provide a better feedback on this kind of situation. I’ll search my archives again and reopen a new issue on bugzilla if indeed it never went through :(On Jan 9, 2014, at 23:10, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:On 10 January 2014 08:15, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:First thing that came to mind is that we could just call the frame callback as soon as the frame is put in the FrameFlusher Q. But this does not work as the flusher Q can grow infinitely and there is no backpressure to act as flow control of the producers are making frames faster than we can send them.
So I think the correct semantic is call the callback as a frame is prepared for a write - either individually, as a gather write or potentially as it is written into an aggregate buffer. Let's call this process aggregation - regardless of the actual implementation.
What if it is a large frame, that requires multiple writes to be successful?Indeed tricky one. We probably have to have a bypass for large frames that are too big to be aggregated. We have the same issue in HttpOutput, were we only aggregate small buffers and large ones are passed directly to the new layer. Isn't complexity fun!