Hi Noah,
do you have comet or websockets enabled for the http-listener?
Pls. file an issue, we'll fix it asap.
Thanks.
WBR,
Alexey.
On 03/03/2012 12:18 AM, Noah White wrote:
> Alexey,
>
> Thanks for you response. Based on those descriptions, which were
> quite helpful, I put together a small bit of test code inside a
> Jersey endpoint to simulate a 'long running request':
>
> @Path("/tests")
>
> @Path("/timeout-tests")
> @GET
> @Produces(MediaType.TEXT_PLAIN)
> public Response timeoutTest() {
> Date startDate = new Date();
> try {
> for (int x = 0; x < 250; x++) {
> Thread.sleep(1000);
> }
> }catch(InterruptedException ex) {
> log.error("timeoutTest interrupted", ex);
> }
> Date endDate = new Date();
> return Response.ok(String.valueOf((endDate.getTime() -
> startDate.getTime())).build();
> }
>
> I adjusted the three timeout values so that each was some value below
> 200s, restarted GF (3.1.1), deployed the app, and hit the endpoint. I
> expected to see a timeout of some sort w/stack in the server.log.
> However, I did not see any and the endpoint completed after ~25s.
>
> Thoughts?
>
> -Noah
>
> On Mar 1, 2012, at 12:42 PM, Oleksiy Stashok wrote:
>
>> Hi Noah,
>>
>> see comments inline...
>>
>> On 02/29/2012 06:32 PM, forums_at_java.net wrote:
>>> I tried grep'ing the online documentation but I haven't come across
>>> anything that can tell me what the relationship is between the
>>> following:
>>>
>>> http-listener-1 -> HTTP
>>>
>>> That tab contains the following properties:
>>>
>>> Timeout
>>>
>>> Request Timeout
>>>
>>> Timeout has a comment that says, "Max time a connection can be
>>> deemed as idle
>>> and kept in the keep-alive state"
>> Right, if you're using HTTP/1.1 keep-alive mechanism, this is max
>> time GF will keep connection open and wait for another HTTP request
>> to come on this connection.
>>
>>>
>>> Request Timeout has a comment that says, "Time after which a request
>>> times
>>> out"
>> This timeout, is max time one specific HTTP Request can be processed
>> by GF, for example if your servlet is stuck w/ DB request longer than
>> this timeout value - GF will try to interrupt the processing thread
>> and force the servlet to finish request processing.
>>
>>
>>> Now under http-listener-1 -> General there is a Thread Pool setting
>>> which by
>>> default uses http-thread-pool
>>>
>>> In the http-thread-pool configuration there is an Idle Thread
>>> Timeout value
>>> which has the comment, "The max amount of time that a thread can
>>> remain idle
>>> in the pool. After this time expires, the thread is removed from the
>>> pool."
>> This timeout is related to threads, which are doing nothing for
>> <timeout> time.
>> Thread-pool config has min and max threads count, so GF is able to
>> increase number of threads in a pool on high load and decrease them
>> once load got lower.
>> We determine that thread in a pool can be released, when this thread
>> doesn't do any job for a "timeout" time.
>>
>>
>>>
>>> Also, the http-listener properties are configurable via asadmin in the
>>> server-config.network-config.protocols.protocol.http-listener-1
>>> namespace.
>>> However, it does not look like the http-thread-pool "Idle Thread
>>> Timeout"
>>> value is configurable in
>>> the server.thread-pools.thread-pool.http-thread-pool namespace even
>>> though
>>> the other properties are. Is this a bug or is in for some reason in
>>> another
>>> namespace?
>> I ran this command (GF 3.1.1):
>> asadmin get server-config.thread-pools.thread-pool.http-thread-pool.*
>>
>> and here is the output:
>>
>> server-config.thread-pools.thread-pool.http-thread-pool.classname=com.sun.grizzly.http.StatsThreadPool
>> *server-config.thread-pools.thread-pool.http-thread-pool.idle-thread-timeout-seconds=900*
>> server-config.thread-pools.thread-pool.http-thread-pool.max-queue-size=4096
>> server-config.thread-pools.thread-pool.http-thread-pool.max-thread-pool-size=5
>> server-config.thread-pools.thread-pool.http-thread-pool.min-thread-pool-size=2
>> server-config.thread-pools.thread-pool.http-thread-pool.name=http-thread-pool
>> Command get executed successfully.
>>
>> WBR,
>> Alexey.
>
> You are correct I must have glossed over it in the list and missed it.
> Thanks.
>