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 <[email protected]> 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 / [email protected]
> 
> On Fri, Jun 22, 2018 at 1:45 PM, Bill Ross <[email protected]> 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 <[email protected]>
>>>  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
>> 
>> [email protected]
>> 
>> 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
> [email protected]
> 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
> [email protected]
> 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

_______________________________________________
jetty-users mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

Reply via email to