https://bz.apache.org/bugzilla/show_bug.cgi?id=63191
--- Comment #5 from Boris Petrov <boris_pet...@live.com> --- I'm not sure I understand. If you do believe my claim that a call to javax.websocket.RemoteEndpoint.Async.sendText never calls the callback, is it possible the bug to be anywhere else other than Tomcat? I mean, this is Tomcat code and I don't think it calls back to CometD or anything else before calling the callback passed, right? If you don't believe me, how can I prove it to you? In the original post here I gave a link to my GitHub comment where I give the output from my println's where I explicitly note how "sendText" is called and how it never calls its callback. You can see the println's I've put here: https://github.com/boris-petrov/cometd-test/blob/eaef0491161dc36d57585599c3dce449b65aee42/cometd-java/cometd-java-websocket/cometd-java-websocket-javax-server/src/main/java/org/cometd/websocket/server/WebSocketEndPoint.java#L101 And the output here: https://github.com/cometd/cometd/issues/820#issuecomment-456693279 On Monday I will post the stacktrace of when exactly "_wsSession.getAsyncRemote().sendText" is called. I'm not sure it will help but I will give it. What else can I do? If this is a deadlock as I'm suggesting, it's not that I can give you a simple reproduction. Also, you keep talking about the long stacktrace. It's the *effect* of the bug, not the cause - it has blocked on a Promise that CometD is waiting on which has not been resolved because down the line "sendText" hasn't called its callback in "org/cometd/websocket/server/WebSocketEndPoint.java#L101". Again, please tell me what to do to make you begin to think that there might be an issue in Tomcat or disprove me. I'm fine with both scenarios. I just want the bug fixed. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
