SSE Streams Not Staying Open

[Erik]

I am trying to implement SSE in WildFly 26 for our web application.  Unfortunately it is being done on a corporate network so I can't attach source.  I have it working with http, so I know my code is good.  However, our product is using https with a username/password login that returns a session ID cookie (authentication is implemented using Shiro).  When I test in this environment, the SSE stream seems to close as soon as it returns from the @GET MediaType.SERVER_SENT_EVENTS registration endpoint.

In the registration endpoint, I register the caller's SseEventSink with my SseBroadcaster and then create an OutboundSseEvent to let the client know that registration is successful.  After logging the call, I send the confirmation OutboundSseEvent directly to the caller's SseEventSink before exiting the method.

I use curl to test with so I first run:

curl --insecure -c curl-cookies.txt -X POST -H 'Content-Type: application/x-www-form-urlencoded' --data 'username=test&password=test' https://localhost:8443/app/session/login

I then run:

curl -N -v --insecure -b curl-cookies.txt -X GET -H "Accept:text/event-stream" https://localhost:8443/app/sse

Curl prints out header information including:

HTTP/1.1 200 OK

Connection: keep-alive

Transfer-Encoding: chunked

Content-Type: text/event-stream

I then see a printout of my registration confirmation event followed immediately by:

* Connection #0 to host localhost left intact

and then I am given my command prompt back.

I take this to mean that curl believes my stream has closed and exits.  When I tested my prototype SSE war (in the same WildFly instance) using just a plain http endpoint, curl waited forever and printed out every broadcast event I throw at it -- it was great!

Since I am confident my SSE Java code works properly (thanks to the http experiment I did) I have been doing a lot of Googling about what might be different with SSE over https and what WildFly configuration changes I might need to make.  So far, that search has been in vain.  I am no closer to finding a solution to my problem than I was last week.

I can't copy/paste my standalone.xml file but I think this is the relevant part of the undertow configuration, in case that helps:

<server name="default-server">

  <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>

  <https-listener name="https-pki" socket-binding="https-pki" no-request-timeout="-1" ssl-context="crowbarSSC" enable-http2="true"/>

  <https-listener name="https" socket-binding="https" ssl-context="applicationSSC" enable-http2="true"/>

  <host name="default-host" alias="localhost">

    <location name="/" handler="welcome-content"/>

    <http-invoker http-authentication-factory="application-http-authentication"/>

  </host>

</server>

<servlet-container name="default">

  <jsp-config/>

  <websockets/>

</servlet-container>

<handlers>

  <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>

</handlers>

<application-security-domains>

  <application-security-domain name="other" security-domain="ApplicationDomain"/>

</application-security-domains>

Any thoughts on what I might have done wrong or might need to do that I haven't done  yet would be greatly appreciated.

Thanks,

Erik

[Erik]

Our logs are spit out into multiple files and I just noticed I have been missing the following warning all this time:

WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task) RESTEASY002186: Failed to set servlet request into asynchronous mode, server sent events may not work

It seems likely that that whatever is causing this warning does indeed break SSE for me.  I'm not finding any more info about RESTEASY002186 on the web.  Any ideas what might be causing this to occur?

[James Perkins]

Does it only fail if you enable SSL?

One option for getting more information would be to enable debug logging for RESTEasy. With CLI it would be:
/subsystem=logging/logger=org.jboss.resteasy:add(level=DEBUG)

[Erik]

Correct.  SSE works as expected when I access an http endpoint and no RESTEASY warning gets logged.  After setting the CLI debug logging for RestEasy, I see:

DEBUG RESTEASY002315: PathInfo: /sse

DEBUG RESTEASY010520: Beans found for class <My SseResources class> : [Managed Bean [class <My SseResources class>] with qualifiers [@Any @Default]]

WARN RESTEASY002186: Failed to set servlet request into asynchronous mode, server sent events may not work

DEBUG MessageBodyWriter: org.jboss.resteasy.core.providerfactory.SortedKey

DEBUG MessageBodyWriter: org.jboss.resteasy.plugins.providers.jackson.ResteasyJackson2Provider

DEBUG Provider : org.jboss.resteasy.plugins.providers.jackson.ResteasyJackson2Provider, Method : writeTo

That all looks reasonable to me (except the WARN of course) unless the 2 references to <My SseResources class> in the second DEBUG statement need to be different classes to work properly.  But I don't think that can be an issue because if it was, it should break with the http endpoint as well...

[narendar golla]

Hi team, we are also facing same issue when we are migrating to wildly 10.1.25.

The same application is working fine in our old servers. Any findings please let us know. Thanks in advance

[James Perkins]

There is no WildFly 10.1.25.