| Re: [jetty-users] avoiding earlyEOF |
The particular library I included was just for example, if there's a simple way to make it nicely drop-in to Jetty that'd be totally great by us. We embed all our Jettys so making it work nicely with XML based deployments was never a goal to us. > On Jun 22, 2018, at 11:50 AM, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote: > > Jetty start uses Jetty XML. > Jetty XML doesn't support try-with-resources, or try-catch. > Also, Jetty XML expects an Object to be configured and returned. > > Joakim Erdfelt / joakim@xxxxxxxxxxx > > On Fri, Jun 22, 2018 at 1:45 PM, Bill Ross <ross@xxxxxxxxxxxx> wrote: > Is there a simple way to incorporate this in a start.jar from script startup? If not, would it be worth building into jetty? > Thanks, > > Bill > > https://github.com/opentable/otj-pausedetector > > public class MyCoolApp > { > > public static void main(String[] args > ) { > > try (new JvmPauseAlarm(100, 400). > start()) { > runMyCoolApp(); > } > } > } > > > On 6/22/18 10:09 AM, Steven Schlansker wrote: >>> On Jun 22, 2018, at 9:56 AM, Shawn Heisey <eclipse@xxxxxxxxxxxx> >>> wrote: >>> >>> On 6/20/2018 11:23 PM, Robben, Bert wrote: >>> >>>> The problem that we face is that we regularly see IOExceptions >>>> exceptions occurring in the communication between these components. >>>> >>> Let's say that you expect all requests to complete in 10 milliseconds or >>> less. So you set your timeout to 1 second, thinking that's always going >>> to be plenty of time. But then your application fills up its 2GB heap >>> right in the middle of handling one of those requests, and the resulting >>> garbage collection pauses the JVM for two seconds. The entity at the >>> other end of the connection is going to give up and close the connection >>> before the program experiencing the GC pause can respond. Tuning >>> garbage collection to reduce GC pauses is certainly a good idea, but if >>> the timeout were 10 seconds instead of one second, it probably would not >>> have had any problem. >>> >> You can (and should!) explicitly monitor these conditions. The JVM provides interesting >> diagnostics output through JMX to monitor it, or you can directly measure: >> >> >> https://github.com/opentable/otj-pausedetector >> >> >> I run this in *every* application -- unexpected pauses cause all sorts of troubles, >> monitoring it is cheap, and you'll save hours when you have a big warning >> "hey, the JVM went to lunch for 30 seconds here, that might be why all this stuff broke" >> >> >> >> >> ______________________________ >> _________________ >> jetty-users mailing list >> >> jetty-users@xxxxxxxxxxx >> >> To change your delivery options, retrieve your password, or unsubscribe from this list, visit >> >> https://dev.eclipse.org/mailman/listinfo/jetty-users > > > _______________________________________________ > jetty-users mailing list > jetty-users@xxxxxxxxxxx > To change your delivery options, retrieve your password, or unsubscribe from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users > > _______________________________________________ > jetty-users mailing list > jetty-users@xxxxxxxxxxx > To change your delivery options, retrieve your password, or unsubscribe from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail