You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Jetty version(s)
Jetty 11.0.15 (from maven central as i search)
Java version/vendor(use: java -version)
17.0.4
OS type/version
Centos7
Description
In the project using WebSocketServer, there is a daemon thread polling to send messages to all clients (about 20 ms polling), recently found that occasionally polling thread can not send messages, I looked at the stack log of this polling thread. It appears that the message sent to the Client was blocked once, causing the polling thread to block.
I checked the source code and found that there was no expiration time for the sending event, and if for some reason the WebSocket message got stuck in the sendFrame phase, would that cause the polling thread above me to keep blocking?
Also, if this is the reason, can I manually change timeout to one of our business expectations.
You should be using Jetty 12 at this point in time.
Note: you are using blocking send, there is no timeout per send using blocking send techniques, only idle timeout on the connection.
Use async send then you can control per send timeout to fit the needs of your application (of course you'll be implementing in your application how the per send timeout occurs and any actions you will take once your send timeout elapses, such as closing the connection, notifying common components, etc).
Ok, thank you very much. Please consult, is there a corresponding document or case for asynchronous sending? I can't find a case in the official documents.
Or can I just compile FutureCallback in the source code and change it from blocking the send to sending with a timeout?
@dlwss this line in your stacktrace org.eclipse.jetty.websocket.common.JettyWebSocketRemoteEndpoint.sendBytes(JettyWebSocketRemoteEndpoint.java:65) the blocking sendBytes method is being used.
There is another method on JettyWebSocketRemoteEndpoint called void sendBytes(ByteBuffer data, WriteCallback callback) which takes a WriteCallback which will notify you asynchronously about the success or failure of the write.
Jetty version(s)
Jetty 11.0.15 (from maven central as i search)
Java version/vendor
(use: java -version)
17.0.4
OS type/version
Centos7
Description
In the project using WebSocketServer, there is a daemon thread polling to send messages to all clients (about 20 ms polling), recently found that occasionally polling thread can not send messages, I looked at the stack log of this polling thread. It appears that the message sent to the Client was blocked once, causing the polling thread to block.
Stack log as follows:
I checked the source code and found that there was no expiration time for the sending event, and if for some reason the WebSocket message got stuck in the sendFrame phase, would that cause the polling thread above me to keep blocking?
Also, if this is the reason, can I manually change timeout to one of our business expectations.
org.eclipse.jetty.util.FutureCallback
org.eclipse.jetty.websocket.common.JettyWebSocketRemoteEndpoint#sendBlocking
The text was updated successfully, but these errors were encountered: