On 22/05/2013 10:55, Rémy Maucherat wrote:
> On 05/22/2013 11:20 AM, Mark Thomas wrote:
>> At the moment, my current solution of allowing a maximum of one read
>> thread (i.e. in response to the socket signalling it has data to read)
>> and one write thread (i.e. in response to the socket signalling it is
>> ready to receive data) per request rather than a maximum of one thread
>> per request looks like the best option.
>
> Ok, that's reasonable. The whole use case (mixing async and blocking)
> doesn't make sense for regular Servlets. But relaxed concurrency would
> be acceptable after a connection is upgraded, since there is no access
> to the non synced Servlet API objects (which turns out to be a very good
> design choice). Ultimately, it is desirable, once upgraded, to be able
> to do any sort of IO, so allowing one write + one read concurrency could
> be a good solution then.
It seems to be so far. There were a few sync issues I needed to fix but
nothing major.
> I would like to keep the strict one container thread rule for Servlets
> though, since none of the Servlet container objects are synced.
I'm fine with that. As it happens, that is exactly what I do at the moment.
This looks like it could be the way forward but there is no immediate
rush to get this into an MR. We can afford to wait a little while for
others to provide feedback.
Mark