You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2019/03/01 12:15:48 UTC

[Bug 63191] RemoteEndpoint.Async#sendText(String, SendHandler) never calls the callback

https://bz.apache.org/bugzilla/show_bug.cgi?id=63191

Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO

--- Comment #2 from Mark Thomas <ma...@apache.org> ---
I've been looking at the full thread dump
(https://github.com/cometd/cometd/files/2779329/threads.zip) which which the
two threads mentioned above have been extracted.

Thread #206 is blocked by thread #203. That looks normal. Tomcat uses per
socket locks to ensure two threads don't try to access the same socket at the
same time.

So why is thread #203 blocked? It has made a call into
org.cometd.websocket.server.WebSocketEndPoint.onMessage() that has not
returned. It is waiting for a call to CompletableFuture.get() to return.

I've looked through the thread dump and I can't find:
- any reference to either the condition or the lock that thread #203 is waiting
for;
- any code that looks like it might be doing some processing with a view to
calling succeed() or fail() on that Promise.

The Promise.Completable is used here:
https://github.com/cometd/cometd/blob/4.0.x/cometd-java/cometd-java-websocket/cometd-java-websocket-javax-server/src/main/java/org/cometd/websocket/server/WebSocketEndPoint.java#L62

I don't see anywhere where that call to onMessage could result in either
succeed() or fail() not being called on the Promise but that is what the stack
trace suggests is happening and I am not at all familiar with the CometD code
so I might be missing something.


I also note that the original description makes reference to calling
wsSession.getAsyncRemote().sendText(...) and that not returning but I don't see
any evidence of that call in the stack trace either.

At the moment, I'm not sure where the root cause lies but I am not seeing any
evidence that suggests that this is a Tomcat bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org