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.