Hi,
first of all thank you for the feedback!
In GF 3.1.1 some descriptions might have been changed, but we'll
appreciate your suggestions to make them clearer.
Please see inlined comments...
> + Request Timeout.
>
> "Time after which a request times out".
>
> "The number of seconds before a request times out. If the request is not
> processed before the timeout value is reached, the request is ignored.
> The
> default value is 30 seconds."
It's 900 seconds by default in 3.1.1
> Sounds rather straightforward, BUT! What happens at the timeout?? I
> wrote a
> Servlet doGet() that calls Thread.sleep(forever), and added a small
> Filter
> that logs all requests and responses. A request is logged ok. After the
> specified timeout, a 200 response is sent back. AND the original
> request is
> RE-SENT to theServlet. So now there are TWO threads sleeping! Isn't this
> weird?
Depends on servlet code.
For example this is my servlet code:
/ System.out.println("sleeping 120 secs");
try {
Thread.sleep(120000);
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
System.out.println("woke up");
}/
After I set request-timeout to 30 seconds and made a request to servlet
- I see this output in the log (after 30 seconds):
/
[#|2011-10-21T18:42:47.080+0200|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=37;_ThreadName=Thread-2;|*sleeping
120 secs*|#]
[#|2011-10-21T18:43:02.086+0200|WARNING|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=34;_ThreadName=Thread-2;|GRIZZLY0023:
*Interrupting idle Thread: http-thread-pool-8181(5)*.|#]
[#|2011-10-21T18:43:02.087+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=37;_ThreadName=Thread-2;|*java.lang.InterruptedException:
sleep interrupted*
at java.lang.Thread.sleep(Native Method)
at
timeout.RequestTimeoutServlet.processRequest(RequestTimeoutServlet.java:33)
at timeout.RequestTimeoutServlet.doGet(RequestTimeoutServlet.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
..................................................................................................
|#]
[#|2011-10-21T18:43:02.089+0200|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=37;_ThreadName=Thread-2;|*woke
up*|#]
/
so the initial request processing is getting finished, and if browser
will decide to repeat the request - it will be the only one request
being processed.
In order to interrupt the thread, GF calls thread.interrupt(), but if
your task can not be interrupted - that would be a problem.
> (The real problem here is that some of my server tasks can take a long
> time,
> and after the timeout ANOTHER PARALELL task is started! That's really
> bad!)
As we know there is no way to kill thread in Java, so if your code can
not be interrupted by thread.interrupt() - it becomes a problem.
For example this code:
/int a = 0;
while(true) {
a++;
}
/
can not be interrupted by thread.interrupt(). And probably we'll see the
same issue as you do, when running this code.
> + Max Post Size.
>
> "Maximum size of POST actions"
>
> "The maximum size in bytes of POST actions. The default value is 2097152
> bytes."
>
> I have no problems uploading a 11 MB file using a POST (multipart-MIME).
> Huh??
It's bad documentation.
This limit is applicable to
application/x-www-form-urlencoded
>
> + Upload timeout
>
> "Enable closing of connection for a servlet that reads bytes slowly after
> Connection Upload Timeout is reached"
>
> "If this option is selected, the connection for a servlet that reads
> bytes
> slowly is closed after the Connection Upload Timeout limit is reached. If
> this option is disabled, servlet connections do not time out. This
> option is
> disabled by default."
>
> What, exactly, is meant by "slowly" here? Less than X bytes per
> second? Or
> that the entire POST request takes more than 'Connection Upload Timeout'
> milliseconds?
It's max milliseconds we wait when trying to read next chunk of
uploading data.
If you send at least 1 byte each (upload-timeout-millis - 1) - you're fine.
> By the way, I have seen indications that after this timeout (or perhaps
> 'Request timeout'), ANOTHER PARALELL file upload is started. Eeek!
>
> Isn't this weird? And is there a way to prevent GF to re-issue the
> requests?
It has to be client side, who reissues the request.
Thanks.
WBR,
Alexey.