Thanks, Pavel.
Absolutely no instances of "@ServerEndpoint" in my code. I searched to
be triple certain.
Perhaps I can track down the problem by excluding dependencies required
for WebSockets (and possibly generate a compile-time error).
My (Gradle) Jersey/Tomcat dependencies look like this:
dependencies {
compile project(':core')
compile(group:'org.glassfish.jersey.bundles',name:'jaxrs-ri',version:'2.18')
compile(group:'org.glassfish.jersey.media',name:'jersey-media-multipart',version:'2.18')
compile(group:'org.glassfish.jersey.media',name:'jersey-media-sse',version:'2.18')
compile(group:'javax.servlet',name:'javax.servlet-api',version:'3.1.0')
}
dependencies {
deftomcatVersion ='7.0.62'
tomcat"org.apache.tomcat.embed:tomcat-embed-core:${tomcatVersion}",
"org.apache.tomcat.embed:tomcat-embed-logging-juli:${tomcatVersion}"
tomcat("org.apache.tomcat.embed:tomcat-embed-jasper:${tomcatVersion}") {
excludegroup:'org.eclipse.jdt.core.compiler',module:'ecj'
}
}
Is there separate dependency for WebSockets in Jersey? Is it possibly
included in jaxrs-ri, jersey-media-multipart, or jersey-media-sse above?
==========
On 6/28/2015 3:20 PM, Pavel Bucek wrote:
> 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.
>>
>