> Can anyone advise? We're currently trying to workaround (by not calling "close"!).
What do you mean by this? The recommendation for Servlets is to never call flush before returning from your dispatch. That allows the Servlet Container itself to threadlessly handle flush and not have to keep a thread open to the Servlet waiting for the connection to flush completely. The only semi-valid case for using Close on the streams from a Request or Response is an extreme error condition. And even so, using close is not the correct way to do that, as it doesn't address the buffers properly. In fact, there's no feature in the Servlet spec to close a bad connection, it's left up to the Servlet Container to do that currently - https://github.com/eclipse-ee4j/servlet-api/issues/98 Jetty has a non-spec feature where you can call HttpServletRespons.sendError(-1) <https://github.com/eclipse/jetty.project/blob/jetty-10.0.7/jetty-server/src/main/java/org/eclipse/jetty/server/Response.java#L478-L487> to trigger a low level harsh abort of the connection/channel, and allow the buffers and everything else to cleanup properly. If you want the connection to close after the response, it's the Servlet's responsibility to add `response.setHeader("Connection", "close")` before the response is committed. This allows the Servlet Container to continue the flush (hopefully its threadless because you returned from dispatch without a flush call), and when the final flush is complete begin the closure of the connection (which is different in HTTP/1.1 vs HTTP/2 vs HTTP/3) Otherwise you never want to close, as that's HTTP/1.0 *only* behavior and is absolutely horrible for your users, your apache frontend, your OS resources, your JVM resources, etc. When HTTP/1.1 came out, it was persistent by default. Even the old school `Connection: keep-alive` was deprecated and has no meaning when using HTTP/1.1 (the 'keep-alive' token is intentionally undefined in HTTP/1.1). With HTTP/2+ things get even more subtle, as starting with HTTP/2 the `Connection: close` header now has no meaning (the 'close' token is intentionally undefined in HTTP/2), there's other ways to abort a connection in HTTP/2 (and HTTP/3). In short, If you are using .flush() or .close() on any Servlet stream/reader/writer, stop doing that, you are doing far more harm than good. Joakim Erdfelt / joa...@webtide.com On Fri, Oct 22, 2021 at 11:56 AM Gordon Jahn <gj...@objectgravity.com> wrote: > Hi folks, > > We're running an app using embedded Jetty 9.4.43 and have had two hangs in > 36 hours after all being well for, well, weeks. > > We're wondering if it's a browser change that's caused it (this is fronted > by Apache and the Apache logs show client bump from Chrome 94 to 95) but > our thread dump (using jstack) shows 193 threads blocked at > org.eclipse.jetty.server.HttpOutput.close(HttpOutput.java:639). We suspect > it's stopped responding to requests because the thread pool is out of > available connections. > > The stack dump from HttpOutput.close() is as follows: > > "qtp2104336222-27891" #27891 prio=5 os_prio=0 tid=0x00007f7d780b4800 > nid=0x3ba waiting on condition [0x00007f7d4f235000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x0000000581b953d0> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at > org.eclipse.jetty.util.SharedBlockingCallback$Blocker.block(SharedBlockingCallback.java:241) > at org.eclipse.jetty.server.HttpOutput.close(HttpOutput.java:639) > > We're trying to work around, but aren't sure what's happening. Had a > quick look at the 9.4.44 release notes and can see this change > https://github.com/eclipse/jetty.project/issues/6562 but not sure it's > necessarily going to address this. > > Can anyone advise? We're currently trying to workaround (by not calling > "close"!). > > Thanks in advance, > Gordon Jahn > _______________________________________________ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users >
_______________________________________________ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
