[
https://issues.apache.org/jira/browse/WICKET-5453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13853453#comment-13853453
]
Joakim Erdfelt commented on WICKET-5453:
----------------------------------------
Tis a shame.
Well, know that the original point of the question on stackoverflow had to do
with idle timeout.
The answer there has been updated with some specifics about how idle timeout
works on jetty.
We like the JSR 356 apis, they are a great step towards standardization. +1 for
that.
However, the JSR 356 spec and API are missing various things that are proving
to be difficult for some users.
Some gotchas:
* ServerEndpointConfig.Configurator execution order is undetermined. tomcat /
jetty / tyrus / grizzly all do it differently.
* ServerEndpointConfig.Configurator instantiation is undetermined. jetty uses 1
instance per endpoint, tyrus / grizzly seem to create a new instance per
session ( which complicates / prevents singleton endpoint use in
Configurator.getEndpointInstance() )
* connectToServer() has no connect timeouts
* no rules on combined use of RemoteEndpoint.Basic + RemoteEndpoint.Async
* if implementation queues frames in RemoteEndpoint.Async and a queue full
occurs, it has to fail the .send() calls via the future or sendhandler, not via
a runtime exception (as any extensions will sit between the queue and the send
call). If a single message results in multiple frames in the queue, some
frames might be ok, but a later one might fail, making the entire stream
invalid at this point. This means the only safe thing to do on
RemoteEndpoint.Async.send() calls and a full queue is to fail the message and
then force close the session.
Hopefully these kinds of quirks and undetermined behavior will be addressed in
a future revision of JSR 356.
> Jetty 9.1.0 has its own UpgradeFilter, use it
> ---------------------------------------------
>
> Key: WICKET-5453
> URL: https://issues.apache.org/jira/browse/WICKET-5453
> Project: Wicket
> Issue Type: Bug
> Components: wicket-native-websocket
> Affects Versions: 7.0.0
> Reporter: Joakim Erdfelt
> Assignee: Martin Grigorov
> Priority: Minor
>
> In a recent stackoverflow question ..
> http://stackoverflow.com/questions/20661139/websocket-timeout-with-apache-wicket-and-embedded-jetty
> I noticed a reference to a class called Jetty9WebSocketFilter
> Starting in Jetty 9.1.0, a filter for websocket upgrade ships with Jetty.
> See answer (with example code):
> http://stackoverflow.com/a/20663447/775715
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
