tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 42198] New: - Insufficient synchronization for CometEvent.close
Date Mon, 23 Apr 2007 15:31:37 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=42198>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42198

           Summary: Insufficient synchronization for CometEvent.close
           Product: Tomcat 6
           Version: 6.0.11
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: critical
          Priority: P2
         Component: Catalina
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: matthias.reich@siemens.com


I am currently porting our eventing framework for web based clients to Tomcat 6,
as we would like to make use of the new CometProcessor interface.

I detected that the concurrent access of event processor thread and response
provider thread seems to be unsufficiently synchronized.

I built a small test webapp which tries to simulate the communication behaviour
of our framework and did some tests.
(see attachment comettest.war)
You can easily use the test webapp by simply deploying it to the webapps folder
of Tomcat,
then start one more more browsers (IE and FireFox shown a little different
behaviour),
and request the index page of the webapp.

I did my tests first with tomcat 6.0.10,
then with http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_11,
revision 530531, and finally with the trunk, revision 531159.
For the APR connector I used tcnative-1.dll in version 1.1.8.

Without enhanced synchronization, the XMLHttpRequests are often hanging after
reaching readyState 3 (often with Firefox, sometimes with IE).
Furthermore, CometEventImpl.close sometimes fails, and with the NIO connector I
saw e.g. this Exception:

java.lang.NullPointerException
	at
org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket(InternalNioOutputBuffer.java:436)
	at
org.apache.coyote.http11.InternalNioOutputBuffer.flushBuffer(InternalNioOutputBuffer.java:761)
	at
org.apache.coyote.http11.InternalNioOutputBuffer.endRequest(InternalNioOutputBuffer.java:398)
	at org.apache.coyote.http11.Http11NioProcessor.action(Http11NioProcessor.java:1087)
	at org.apache.coyote.Response.action(Response.java:183)
	at org.apache.coyote.Response.finish(Response.java:305)
	at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:276)
	at org.apache.catalina.connector.Response.finishResponse(Response.java:486)
	at org.apache.catalina.connector.CometEventImpl.close(CometEventImpl.java:85)
	at comettest.CometServlet.closeEvent(CometServlet.java:331)
	at comettest.CometServlet.access$2(CometServlet.java:317)
	at comettest.CometServlet$EventProvider.sendResponse(CometServlet.java:146)
	at comettest.CometServlet$EventProvider.run(CometServlet.java:95)
	at java.lang.Thread.run(Thread.java:595)


With the APR connector sometimes even the VM crashed. (see attached dump)


This is probably related to my observation that, if the concurrent close is
executed immediately after the CoyoteAdapter.service call, there is not END
event signalled.
Also with the NIO connector I saw that I did not get END events for all BEGIN
events.

Thus, my guess was that response objects might have been recycled too early, and
I modified the classes org.apache.catalina.connector.CometEventImpl,
org.apache.catalina.connector.CoyoteAdapter, and
org.apache.catalina.connector.Request to add a synchronization between event
processor thread and response provider thread via the CometEventImpl object.
(see attachment patches-reich.jar)

This synchronization prevents a recycling of request and response before the
close operation is completely finished and ensures that the close operation is
executed at most once.
- If one Thread enters the close method, the state of the object changes from
OPEN to CLOSING. When the close has finished, state goes to CLOSED.
- One sync point is in the CoyoteAdapter.service method when decides whether the
request shall be closed or put into the CometPoller.
  If the CometEventImpl.close method has not been called until then (state is
still OPEN), any later invocation of close is allowed to perform recycling of
request and response object by its own, until a new event is dispatched for the
request.
- The second sync point is at event dispatching to the CoyoteAdapter.event method.
  If the CometEventImpl state is still OPEN, the CoyoteAdapter takes over
responsibilty for recycling again, until the end of event dispatching.
  If CometEventImpl state is CLOSED, it does not make sense to send an END event
into the valve, because CometEventImpl.close has already recycled request and
response object.

I found out that the asynchronous response providers must not call the close
method of the OutputStream directly.
They must only use the CometEvent.close method, as otherwise there are still
problems due to unsynchronized access (I did not retest this with the trunk yet).


An alternative solution would be to leave the job of recycling completely to
CoyoteAdapter.event, but then we must be 100% sure that we get an appropriate
event from the underlying connector.

In my mind, the far better alternative would be to leave all recycling
completely to the garbage collector, i.e. do not reuse any objects at all, to
avoid the problems that arise automatically when we leave the world of
synchronous request processing, but surely this cannot be done in a day.

With my adaptation, my test application runs without problems for quite a while
with both connectors if there are only short resonse times for the poll requests.
I still sometimes (but not that often) got VM crashes with the APR connector at
the same point of execution of my response provider thread.
I am not sure if my synchronization is still not good enough, or if these
crashes happened when I pressed the reload button to reload the test page into
the browser.
(I saw in the repository created by 'ant download' that you are already working
on tcnative 1.1.10, so that problem might already be solved.)

As I ran my tests (server and browsers) on a WinXP/SP2 machine with a single
processor, I cannot tell whether my adaptation also works well on other
operating systems or on multi processor machines. Furthermore, I don't know if
it really fits with your concepts of the CometEvent lifecycle model. Therefore,
I cannot claim that my adaptations are a patch.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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


Mime
View raw message