Scott:
I like your approach. Thanks a lot.
Ming Qin
Cell Phone 858-353-2839
--- On Wed, 1/27/10, Scott Oaks <Scott.Oaks_at_Sun.COM> wrote:
From: Scott Oaks <Scott.Oaks_at_Sun.COM>
Subject: Re: request timeout
To: dev_at_grizzly.dev.java.net
Date: Wednesday, January 27, 2010, 12:00 PM
Well, I'm more interested in tracking down long-running servlets, so I can just put a long sleep into the servlet.
One easy way to test a single request as a slow reader is to run telnet:
telnet yourhost 8080 (or whatever port)
GET /servlet/path HTTP/1.0
Normally, you'd type return twice after that and the servlet would be served normally. If you type return only once, grizzly will be waiting for more data and time out if that it set.
There should be support in fhb (part of the Faban toolkit) for slow-sending clients in the next few days if that helps you as well.
-Scott
On 01/27/10 14:50, ming qin wrote:
> Scott:
> To test request timeout in http protocol with grizzly. how do you simulate a long request session which will last more than timeout seconds ?
>
> My approach is making a extra big http request URL with regular request header and reducing the buffer reader's size and timeout period value. That can ensure multiple calls of Selector.select() are not sufficient to read all date in http request at special timeout period time.
>
>
> Ming Qin
> Cell Phone 858-353-2839
>
> --- On *Tue, 1/26/10, Scott Oaks /<Scott.Oaks_at_Sun.COM>/* wrote:
>
>
> From: Scott Oaks <Scott.Oaks_at_Sun.COM>
> Subject: Re: request timeout
> To: dev_at_grizzly.dev.java.net
> Date: Tuesday, January 26, 2010, 8:42 AM
>
> Ah, thanks -- I filed issue 11490 for that.
>
> -Scott
>
> On 01/26/10 06:03, Oleksiy Stashok wrote:
> > Hi Scott,
> >
> > feature you're looking for is transactions timeout, implemented
> by Jeanfrancois.
> >
> > I've checked the code and I think I know why you can not find
> this value in domain.xml...
> > We misinterpret thread-pool configuration elements in domain.xml,
> we use thread-pool->idle-thread-timeout-seconds to set transaction
> timeout and http->timeout-seconds to set thread's idle-timeout.
> > This is a bug, which should be fixed (can I ask you to file one? :))
> >
> > Anyway, if you want to change transaction timeout in GFv3 - for
> now please change thread-pool->idle-thread-timeout-seconds attribute
> value (default is 900 seconds).
> >
> > WBR,
> > Alexey.
> >
> >
> >
> > On Jan 25, 2010, at 18:44 , Scott Oaks wrote:
> >
> >> I seem to recall that there was something added to grizzly that
> will terminate a request that is taking too long, but I can't find
> any documentation on it -- do I misremember, or are my google skills
> in serious need of work?
> >>
> >> -Scott
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> </mc/compose?to=dev-unsubscribe_at_grizzly.dev.java.net>
> >> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> </mc/compose?to=dev-help_at_grizzly.dev.java.net>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> </mc/compose?to=dev-unsubscribe_at_grizzly.dev.java.net>
> > For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> </mc/compose?to=dev-help_at_grizzly.dev.java.net>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> </mc/compose?to=dev-unsubscribe_at_grizzly.dev.java.net>
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> </mc/compose?to=dev-help_at_grizzly.dev.java.net>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
For additional commands, e-mail: dev-help_at_grizzly.dev.java.net