Hi Ric,
I'm pretty sure that "Tomcat WebSocket (JSR356) Filter" invocations are
completely unrelated to SSE. Your assumption that Jersey SSE is
completely unrelated to WebSocket is correct.
Do you have any @ServerEndpoint annotated class in your application? If
no, then this might be bug in Tomcat WebSocket Filter implementation,
since the filter should not be registered when not necessary + it should
check for http upgrade header (which is not there when you use SSE).
Hope it helps,
Pavel
On 28/06/15 19:52, Ric Bernat wrote:
> We are using Jersey SSE (Server-Sent Events), and I have been assuming
> that SSE is completely separate from / unrelated to WebSockets technology.
>
> However, in our APM monitoring tool for our Jersey/Tomcat application,
> I see references to "Tomcat WebSocket (JSR356) Filter" calls, and
> these have inordinately high response times: 60+ seconds (as opposed
> to around 200 milliseconds for our normal Jersey web service calls).
>
> Can anybody clarify whether these "Tomcat WebSocket (JSR356) Filter"
> calls are related to (required as part of) our use of Jersey SSE?
>
> Our SSE web services basically look like this:
>
> @GET
> @Produces(SseFeature.SERVER_SENT_EVENTS)
> @Path("/startsse")
> publicEventOutput startSse(@CookieParam("sessionKey") String sessionKey)throwsInterruptedException {
> EventOutput eventOutput = new EventOutput();
> // do some stuff
> return eventOutput;
> }
>
> Thanks in advance.
>