1

I'm encountering java.util.concurrent.TimeoutException while sending data via WebSocket (Tomcat8 JSR-356). Refer the trace given below

java.io.IOException: java.util.concurrent.TimeoutException
    at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendPartialString(WsRemoteEndpointImplBase.java:258)
    at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendString(WsRemoteEndpointImplBase.java:193)
    at org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(WsRemoteEndpointBasic.java:37)

I want to know if there are any circumstances under which we get this exception, apart from network latency related issues

Note : I'm facing this exception randomly. Tomcat version is 8.0.20

UnahD
  • 867
  • 2
  • 10
  • 25
  • Is this happening after some time? I've not used Tomcat websocket, but websockets do **close** automatically when there is an idle connection between server/client for a certain time. – Han Nov 30 '17 at 08:39
  • Yes @Han! This is happening in few minutes after the session has been established. But I don't think it is because of the idle session. I constantly exchange data between the client and the server, which in turn doesn't let the WebSocket session to be idle. – UnahD Dec 01 '17 at 04:46
  • This is a `java.util.concurrent.TimeoutException`, not a `SocketTimeoutException`. It is caused by some kind of concurrency timeout problem within the `java.util.concurrent` package. It doesn't have anything to do with the network whatsoever. – user207421 Dec 01 '17 at 05:28
  • @EJP Inside `sendPartialString()` method, the data to be transferred is written to the output buffer and then the `CountDownLatch.await()` method is called to make the current thread wait for 20 seconds (which is the default timeout value). Once the the data is written to the output buffer, `CountDownLatch.countDown()` is called and the current thread resumes its operation. Otherwise, once the latch lapses the timeout value, TimeoutException is thrown explicitly by `throw new TimeoutException()` – UnahD Dec 04 '17 at 05:27
  • So I think this is not actually the concurrency timeout problem. The main issue is it's taking a long time to write data to the output buffer. But I don't the know the reason. Any guesses or @EJP? If you still doubt that this is the concurrency issue, kindly let me know how – UnahD Dec 04 '17 at 05:54

1 Answers1

1

I had the same issue and it was caused by sending data in chunks (Chunked transfer encoding or chunk streaming)

In my case was HTTP Post and the fix was sending content-length in headers.

But it may be the case that the receiver is not prepared to read data in chunks and thus times out waiting for EOF of data.

Andre Brito
  • 146
  • 8