Skip to main content

[servlet-spec users] [jsr340-experts] Re: NIO specification clarification

  • From: Rémy Maucherat <rmaucher@...>
  • To: jsr340-experts@...
  • Subject: [servlet-spec users] [jsr340-experts] Re: NIO specification clarification
  • Date: Fri, 12 Apr 2013 10:43:15 +0200
  • List-id: <jsr340-experts.servlet-spec.java.net>

On 04/12/2013 02:15 AM, Mark Thomas wrote:
The WebSocket use case requires switching back and forth between blocking and non-blocking writes. (The API defines some writes as non-blocking and others as blocking and they can be called in any order).

I am building on top of the Servlet 3.1 HTTP upgrade so I am using the ServletOutputStream in non-blocking mode so I can handle the non-blocking writes. For the blocking writes I have to make the non-blocking write appear to be blocking. For this I am using a Latch so the thread that initiates the write isn't released until the write completes. If it is a large write the container may need to call onWritePossible() several times before the write completes and the Latch can count down and the initiating thread released. This only works if multiple container threads can access the WriteListener.

Remy's explanation of why we have this restriction makes sense. The general case is a lot trickier than the WebSocket case above (and even in the WebSocket case I had to be pretty careful with the multiple threads). I am heading rapidly towards the conclusion that the WebSocket API can't be implemented in a container neutral manner (which I think is a real shame).
Not sure I understand why.

With the way it is built, I would say websockets has to use a single big queue for both its "async" and "blocking" RemoteEndpoint(s), so the onWritePossible will basically trigger the actual sending of the queue content.

I don't see why you would need multiple concurrent onWritePossible notifications to do that [which I have no idea how it could happen anyway on a single socket]. Did I miss something ?

Rémy



[servlet-spec users] [jsr340-experts] NIO specification clarification

Mark Thomas 04/10/2013

[servlet-spec users] [jsr340-experts] Re: NIO specification clarification

Rémy Maucherat 04/10/2013

[servlet-spec users] [jsr340-experts] Re: NIO specification clarification

Rajiv Mordani 04/10/2013

[servlet-spec users] [jsr340-experts] Re: NIO specification clarification

Mark Thomas 04/11/2013

[servlet-spec users] [jsr340-experts] Re: NIO specification clarification

Rajiv Mordani 04/11/2013

[servlet-spec users] [jsr340-experts] Re: NIO specification clarification

Mark Thomas 04/12/2013

[servlet-spec users] [jsr340-experts] Re: Re: NIO specification clarification

Rajiv Mordani 04/12/2013

[servlet-spec users] [jsr340-experts] Re: Re: NIO specification clarification

Mark Thomas 04/12/2013

[servlet-spec users] [jsr340-experts] Re: NIO specification clarification

Rémy Maucherat 04/12/2013

[servlet-spec users] [jsr340-experts] Re: NIO specification clarification

Mark Thomas 04/12/2013

[servlet-spec users] [jsr340-experts] Re: Re: NIO specification clarification

Rémy Maucherat 04/12/2013

[servlet-spec users] [jsr340-experts] Re: Re: NIO specification clarification

Mark Thomas 04/29/2013

[servlet-spec users] [jsr340-experts] Re: Re: Re: NIO specification clarification

Rémy Maucherat 04/29/2013

[servlet-spec users] [jsr340-experts] Re: Re: Re: Re: NIO specification clarification

Mark Thomas 04/30/2013

[servlet-spec users] [jsr340-experts] Re: Re: Re: Re: NIO specification clarification

Rémy Maucherat 04/30/2013

[servlet-spec users] [jsr340-experts] Re: Re: Re: Re: NIO specification clarification

Mark Thomas 04/30/2013

[servlet-spec users] [jsr340-experts] Re: Re: NIO specification clarification

Rémy Maucherat 04/11/2013

[servlet-spec users] [jsr340-experts] Re: Re: Re: NIO specification clarification

Rajiv Mordani 04/11/2013

[servlet-spec users] [jsr340-experts] Re: Re: Re: NIO specification clarification

Mark Thomas 04/12/2013
 
 
Close
loading
Please Confirm
Close