You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2013/01/14 11:47:57 UTC

Re: svn commit: r1425633 - /tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java

On 30/12/2012 22:20, Mark Thomas wrote:
> On 24/12/2012 11:17, markt@apache.org wrote:
>> Author: markt
>> Date: Mon Dec 24 11:17:51 2012
>> New Revision: 1425633
>>
>> URL: http://svn.apache.org/viewvc?rev=1425633&view=rev
>> Log:
>> Allow multiple threads to process an upgraded connection at the same time.
>> This is required to support blocking reads/writes. The Servlet[Input|Output]Streams do not expose an API for a blocking [read|write]. Therefore to block a thread has to wait until [onDataAvailable()|onWritePossible()] is called. The problem is that the waiting thread holds a lock on the socket and there is no way through the Servlet 3.1 API to release that lock. Until the lock is released the thread that will eventually call [onDataAvailable()|onWritePossible()] is blocked. So a form of deadlock occurs. To overcome this without requiring libraries such as WebSocket implementations to access container specific APIs, Tomcat has to allow multiple threads to process a upgraded connection at the same time.
> 
> While this worked on Windows XP, it doesn't work on Linux which - from
> memory of running the Autobahn tests on the Tomcat 7.0.x web socket
> implementation - has a much better (i.e. faster) network implementation.
> 
> The issue is that the Servlet 3.1 non-blocking proposal requires
> multiple container managed threads to be using the socket at the same
> time. I think this is limited to two threads (one reading, one writing)
> but the specification does not explicitly state that so there may be a
> requirement for more. I will be starting a discussion in the EG on this
> point. Regardless, prior to this commit Tomcat enforced a one socket -
> one thread limit and that limit will need to be removed in Tomcat 8.
> 
> Some form of re-factoring will be required but before I embark any
> further down that road I want to take some time to review and fully
> understand the existing code. There are various parts that would benefit
> from some additional commentary and I suspect that a little clean-up
> will be possible as well.

During the refactoring, I found a handful of threading issues. Fixing
those appears to have fixed the Autobahn testsuite for Linux.

I still intend to continue with investigating the refactoring as I am
still not really happy with the above commit.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org