Thanks so much Joakim!! I’ll pass this on, get that removed and check….
Gordon On Fri, 22 Oct 2021 at 23:06, Joakim Erdfelt <[email protected]> wrote: > > 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 / [email protected] > > > On Fri, Oct 22, 2021 at 11:56 AM Gordon Jahn <[email protected]> > 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 >> [email protected] >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> > _______________________________________________ > jetty-users mailing list > [email protected] > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users >
_______________________________________________ jetty-users mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
