Skip to main content

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

  • From: Mark Thomas <markt@...>
  • To: jsr340-experts@...
  • Subject: [servlet-spec users] [jsr340-experts] Re: NIO specification clarification
  • Date: Thu, 11 Apr 2013 20:15:48 -0400
  • List-id: <jsr340-experts.servlet-spec.java.net>

On 11/04/2013 03:19, Rajiv Mordani wrote:

On 4/10/13 6:25 PM, Mark Thomas wrote:

The problem I have is that WebSocket requires some writes to be blocking and some non-blocking. With the above limitation I don't see a way to do this. If a container thread does something that triggers a blocking write that can't complete immediately I need a second container thread to call onWritePossible() to enable the first thread to continue.

Mark I do not understand the use case fully. If a write is blocking then why would you invoke the onWritePossible? Also how do you plan to do this using Servlet 3.1 API? If you start using non-blocking IO then you cannot use the traditional blocking write.

- Rajiv
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).

Mark



[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
 
 
Close
loading
Please Confirm
Close