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 2015/10/22 18:38:03 UTC
[Bug 58520] New: Future returned by
javax.websocket.Session.getAsyncRemote().sendText(...) always returns true
https://bz.apache.org/bugzilla/show_bug.cgi?id=58520
Bug ID: 58520
Summary: Future returned by
javax.websocket.Session.getAsyncRemote().sendText(...)
always returns true
Product: Tomcat 8
Version: 8.0.27
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: WebSocket
Assignee: dev@tomcat.apache.org
Reporter: jeperjaperjieper@gmail.com
In our websocket implementation, we are sending events through websockets every
250ms to the client.
It seems that the Future<Void> returned by
javax.websocket.Session.getAsyncRemote().sendText(...) always returns true.
This makes it impossible to cancel pending outgoing data.
Scenario:
1. Server is up and running
2. Client connects
3. Server starts sending events every 250ms
4. All goes well
5. Client disconnects from the network (for example by unplugging its UTP)
6. Server keeps sending events; the server has no idea that the client is
disconnected (which is OK, on itself)
7. Twenty seconds later, clients reconnects to network
8. Clients receives all events from the last 20 seconds (around 80 events)
Ideally, during step 6, the server notices that there is a previous pending
event, which can be canceled in favor of the current/new event. With that
approach, the client will not receive all past events at step 8.
--
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
[Bug 58520] Future returned by
javax.websocket.Session.getAsyncRemote().sendText(...) always returns true
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=58520
--- Comment #2 from Tweemaal Drie <je...@gmail.com> ---
Hi Mark,
I meant indeed the isDone() operation on the Future.
I agree it is a good thing seen from perspective of the server. However, from
perspective of the client, once the client reconnects, it gets overloaded with
events. The problem is that when processing event N, he has no idea that event
N+1 is still in the pipeline, which means that event N can be discarded.
How would one cope with this situation, in general? We could add a timestamp to
the events, so clients can filter on that, which reduces the processing
overhead.
--
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
[Bug 58520] Future returned by
javax.websocket.Session.getAsyncRemote().sendText(...) always returns true
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=58520
--- Comment #3 from Mark Thomas <ma...@apache.org> ---
Yes, isDone() is always going to be true for the reasons I described
previously.
You can try reducing the write timeout (see the WebSocket How-To in the docs)
but you are still going to have the TCP buffer issue. You could reduce the size
of those via Connector configuration but that might have a negative performance
impact.
Adding an expiry time and filtering based on that on the client is certainly
another valid option.
You'll need to do some testing to figure out which is the best option for your
environment.
--
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
[Bug 58520] Future returned by
javax.websocket.Session.getAsyncRemote().sendText(...) always returns true
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=58520
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Mark Thomas <ma...@apache.org> ---
First of all, a Future<Void> is never going to return true.
Yes, it is impossible to cancel those Futures. Once bytes have been written to
the network, there is no "unwrite these bytes" API so messages cannot be
cancelled once started.
If you use message batching then Tomcat will buffer messages internally.
If you do not use message batching then the network layer will buffer data in
the TCP buffers. If the messages are small 80 of them are not going to fill the
TCP buffers. With long timeouts Tomcat isn't going to see any network issues
until those TCP buffers are filled.
Tomcat has unit tests that check that this behaves correctly. Detecting the
failure requires a *lot* of data to be writtem server side before the problem
is detected.
Generally, the behavoiur you describe is a good thing. You want systems to be
robust against temporary network glitches.
--
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
[Bug 58520] Future returned by
javax.websocket.Session.getAsyncRemote().sendText(...) always returns true
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=58520
Tweemaal Drie <je...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
OS| |All
CC| |jeperjaperjieper@gmail.com
--
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