Hello again,
I would like to give you another chance to see the situation where the
processing objects are not recycled.
After all my observations, I had the feeling that the reason for the
non-recycled processing objects must be problems with concurrent access
to queues or maps that hold these objects, and that it should not be TOO
hard to find it - and I found it.
I modified the lines that are marked in the following code fragments
from class Http11AprProtocol to verify it:
public SocketState event(long socket, SocketStatus status) {
Http11AprProcessor result = connections.get(socket);
SocketState state = SocketState.CLOSED;
if (result != null) {
// Call the appropriate event
try {
state = result.event(status);
....
} finally {
if (state != SocketState.LONG) {
>>>> Http11AprProcessor removed =
connections.remove(socket);
>>>> if (removed != result) {
>>>> Http11AprProtocol.log.error ("removed wrong
processor from connections") ;
>>>> }
recycledProcessors.offer(result);
}
}
}
return state;
}
public SocketState process(long socket) {
Http11AprProcessor processor = recycledProcessors.poll();
try {
if (processor == null) {
processor = createProcessor();
}
if (processor instanceof ActionHook) {
((ActionHook)
processor).action(ActionCode.ACTION_START, null);
}
SocketState state = processor.process(socket);
if (state == SocketState.LONG) {
// Associate the connection with the processor. The
next request
// processed by this thread will use either a new or
a recycled
// processor.
>>>> Http11AprProcessor replaced =
connections.put(socket, processor);
>>>> if (replaced != null) {
>>>> Http11AprProtocol.log.error ("there was still
another processor assigned to the socket - it is not recycled!");
>>>> }
proto.endpoint.getCometPoller().add(socket);
} else {
recycledProcessors.offer(processor);
}
...
Now I ran my test application again, keeping the connection alive
between subsequent requests of the browser.
This is what I found in the log file:
WARNUNG: BEGIN(4) POST /comettest/comet/request?action=poll&count=4
28.04.2007 00:20:35 comettest.CometServlet$EventProvider run
WARNUNG: queue size: 1
28.04.2007 00:20:35 comettest.CometServlet$EventProvider sendResponse
WARNUNG: RESPONSE(4)
28.04.2007 00:20:35 comettest.CometServlet$EventProvider run
WARNUNG: queue size: 0
28.04.2007 00:20:35 comettest.CometServlet$EventProvider run
WARNUNG: sleeping 900 millis
28.04.2007 00:20:35 comettest.CometServlet event
WARNUNG: READ(4) POST /comettest/comet/request?action=poll&count=4,
stream closed
28.04.2007 00:20:35 comettest.CometServlet closeEvent
WARNUNG: CLOSE(4) by event processor
28.04.2007 00:20:35 comettest.CometServlet event
WARNUNG: BEGIN(5) POST /comettest/comet/request?action=poll&count=5
28.04.2007 00:20:35
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler
process
SCHWERWIEGEND: there was still another processor assigned to the socket
- it is not recycled!
28.04.2007 00:20:35
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler event
SCHWERWIEGEND: removed wrong processor from connections
This situation does not occur with each request - it seems to depends on
the actual thread scheduling.
The problem is that the socket is added to the poller already within the
Http11AprProcessor.event method.
Due to this the process method can be invoked before the event method
has done it's cleanup.
This time I am a little caucious with advice how to fix the problem, but
I hope I can convince you now that the problem exists ;-)
Matthias
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
