Download [#GLASSFISH-11891] async call to doPost results in 30sec time lag

[GLASSFISH-11891] async call to doPost results in 30sec time lag Created:
13/May/10 Updated: 19/Dec/16 Resolved: 01/Jul/10
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Resolved
glassfish
web_container
v3.0.1
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Environment:
Bug
denisz
Fixed
None
Not Specified
Attachments:
grizzly-http.jar
11,891
1.9.19-beta5
Issuezilla Id:
Status
Whiteboard:
3.1_dev
Priority:
Assignee:
Votes:
Critical
Ryan Lubke
0
Not Specified
Not Specified
Operating System: Linux
Platform: Linux
Description
A 3.0 servlet on Glassfish v3.0 & 3.01 with an async processing for both doGet
and doPost.
Have no problems with doGet but doPost displays a strange behavior:
almost every consecutive call results in 30sec time lag before the server sends
a response. Calling doGet after a suspended doPost results in the same delay as
well. It looks like the container doesn't release the resource...
Here's my simple servlet to illustrate the problem.
package app;
import java.io.*;
import javax.servlet.*;
import javax.servlet.annotation.*;
import javax.servlet.http.*;
@WebServlet(urlPatterns = "/app", asyncSupported = true)
public class AppOne extends HttpServlet {
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse res) throws
ServletException, IOException {
final AsyncContext actx = req.startAsync(req, res);
actx.start(new Runnable() {
public void run() {
try {
HttpServletResponse res = (HttpServletResponse)actx.getResponse();
res.setContentType("text/plain");
PrintWriter out = res.getWriter();
out.println("doGet-async");
out.flush();
} catch (IOException ex) {
System.err.println(ex.getMessage());
} finally {
System.out.println("doGet ASYNC FINISHED");
actx.complete();
}
}
});
}
@Override
protected void doPost(HttpServletRequest req, HttpServletResponse res) throws
ServletException, IOException {
System.out.println("doPost");
final AsyncContext actx = req.startAsync(req, res);
actx.start(new Runnable() {
public void run() {
try {
HttpServletResponse res = (HttpServletResponse)actx.getResponse();
res.setContentType("text/plain");
res.setHeader("Cache-Control", "private");
res.setHeader("Pragma", "no-cache");
PrintWriter out = res.getWriter();
out.println("doPost-async");
out.flush();
} catch (IOException ex) {
System.err.println(ex.getMessage());
} finally
{ System.out.println("doPost ASYNC FINISHED"); actx.complete(); } } }); }
}
The servlet gets called from index.html with a form:
<form method="post" action="/exSimpleAsync/app">
<input type="text" size="20" name="email" value="hello">
<input type="submit" name="login" value="Click me">
</form>
Comments
Comment by Alexis MP [ 13/May/10 ]
cc
Comment by Shing Wai Chan [ 14/May/10 ]
This is working fine in Chrome, but not in Firefox and Safari. Need to further
investigation.
Comment by Shing Wai Chan [ 19/May/10 ]
In doPost, before starting async, if we add the following line:
String email = req.getParameter("email");
then the time lag will be gone.
Further debugging finds that if one read post body, then the time lag will be gone.
Per discussion with Alexey, it looks like deeper Grizzly issue.
If there is payload remainder, which wasn't read before starting async.
processing - Grizzly counts the remainder as next HTTP message.
Comment by oleksiys [ 19/May/10 ]
reassigning to Ryan.
in com.sun.grizzly.http.ProcessorTask.doProcess()
we don't properly process suspended Response, so if there is still some payload in the HTTP
Request,
which we're planning to read asynchronously, in ProcessorTask.doProcess() method it is
assumed this
payload is actually beginning of the next HTTP Request.
We need carefully check what are the steps we're doing when calling Response.suspend/resume.
If
Response is suspended and not resumed in the same thread - we need to skip post process phase
in
the current worker thread and leave it for async thread. The same with Response.resume(), if
it's
called in the same thread as suspend - we can just reset flags, but if it's called in async thread we
need to execute Request post process phase; and after post process phase, if there is next HTTP
Request already buffered - start processing it.
Comment by Ryan Lubke [ 24/May/10 ]
Created an attachment (id=4378)
Possible fix
Comment by Ryan Lubke [ 24/May/10 ]
Hello denisz,
Could you please verify if the attached jar resolves the issue in your environment?
Backup the existing grizzly-http.jar in $
{GF_HOME}
/modules and drop the one attached to the issue in its
place.
Looking forward to hearing back from you.
Comment by denisz [ 24/May/10 ]
Hi Ryan
I gave it a try and the result is still the same for the browsers:
Firefox 3.5.9 and Chromium 6.0.412.0 on Ubuntu 9.10
There were a few glitches with the new jar file.
The first server start resulted in:
Welcome to Felix
================
25/05/2010 11:27:28 AM Main update
INFO: Updated bundle 81 from
/home/deze/glassfishv3/glassfish/modules/grizzly-http.jar
WARNING: Exception while starting bundle com.sun.enterprise.osgi-adapter [14]
org.osgi.framework.BundleException: Activator start error in bundle
com.sun.enterprise.osgi-adapter [14].
After a few install/uninstall that warning was gone but all server starts now
show the following exception:
INFO: [Thread[GlassFish Kernel Main Thread,5,main]] started
SEVERE: Apache Felix Remote Shell [140] Listener.Acceptor::activate()
SEVERE: java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
at java.net.ServerSocket.bind(ServerSocket.java:319)
at java.net.ServerSocket.<init>(ServerSocket.java:185)
at org.apache.felix.shell.remote.Listener$Acceptor.run(Listener.java:131)
at java.lang.Thread.run(Thread.java:619)
The server is still working and the time lag is still the same.
The tip from swchan2 really helps:
String email = req.getParameter("email");
If I do this before starting async then no time lag is observable. I am
currently using this approach in my development and so far it works well.
Regards,
Denis
Comment by Justin Lee [ 24/May/10 ]
If you saw the "port in use" error then it's highly unlikely you tested with the patched code. That
error
means that something is using the port your trying to bind to which usually means that glassfish
is stil
running. In that event, you'd be running on older code and not patched code. Please try that
again and
make sure glassfish starts up properly with no port errors. If the problem persists, we can take
another
look at the grizzly code. Thanks.
Comment by denisz [ 24/May/10 ]
Ok, quitting Netbeans and restarting the machine has helped.
Now I have the updated jar integrated smoothly with no errors.
But the async delay problem is still there in both browsers.
Comment by oleksiys [ 16/Jun/10 ]
cc myself
Comment by Ryan Lubke [ 21/Jun/10 ]
Grizzly 1.9.19-beta5 has been integrated which includes the fix for this issue.
Please verify using tonight's nightly build or the next promoted build (3.1-b06).
Thanks!
Comment by Ryan Lubke [ 21/Jun/10 ]
Update status whiteboard to include which release of Grizzly the issue was resolved in.
Comment by denisz [ 01/Jul/10 ]
Tested with 3.1-b07 and the bug is gone.
Thank you!
Comment by abien [ 18/Nov/11 ]
I have exactly the same issue:
Server: GlassFish Server Open Source Edition 3.1.1 (build 12)
Tested with:
java.net.HttpUrlConnection
java.net.URL#openConnection()
jersey 1.8 client
Safari 5.1.1
Comment by oleksiys [ 21/Nov/11 ]
Can you pls. attach the application we can use to reproduce this?
Generated at Sat Apr 29 16:24:23 UTC 2017 using JIRA 6.2.3#6260sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.