Nope, Jersey does not implement WebSocket at all, so .. the issue most
likely is not in your application, but in the Tomcat runtime.
I would try to get ServletContext for your application and check which
Servlet/Filters are registered. If there is anything related to
WebSocket + it takes significant time (more than check for "Upgrade"
header), I'd report that to Tomcat as a bug in their implementation.
Regards,
Pavel
On 29/06/15 00:32, Ric Bernat wrote:
> 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.
>>>
>>
>