Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Websocket buffers and async modes

Seems that the following bugs fixed that ...

https://bugs.eclipse.org/bugs/show_bug.cgi?id=415314
Jetty should not commit response on output if < Response.setBufferSize() bytes are written
Commit: https://github.com/eclipse/jetty.project/commit/ad8db51ed5c9db5819b9860b05a4760e805607bb

and

https://bugs.eclipse.org/bugs/show_bug.cgi?id=422807
OOM from writing large byte arrays
Commit: https://github.com/eclipse/jetty.project/commit/cb412d8a0d6f87c7cda9b270f7a528ec55189abd



--
Joakim Erdfelt <joakim@xxxxxxxxxxx>
Expert advice, services and support from from the Jetty & CometD experts


On Thu, Jan 9, 2014 at 5:51 PM, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
That patch does not apply to Jetty 9.1.1.v20140108 - seems that most of what you patched has been patched already.

The current HttpOutput.java --

--
Joakim Erdfelt <joakim@xxxxxxxxxxx>
Expert advice, services and support from from the Jetty & CometD experts


On Thu, Jan 9, 2014 at 5:17 PM, Bruno D. Rodrigues <bruno.rodrigues@xxxxxxxxx> wrote:

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!

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 :( 



Back to the top