[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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