So Great news !
Thanks for you help.
I would like to made a try on my real server.
But it seems that nothing has been committed in the SVN trunk for a while (03/05/2011).
Does the SVN repo change ?
I don't find the right info on the site.
Thanks again
Regards
David
De : Oleksiy Stashok [mailto:oleksiy.stashok_at_oracle.com]
Envoyé : lundi 4 juillet 2011 16:07
À : users_at_grizzly.java.net
Objet : Re: Grizzly Suspend
Hi David,
thanks a lot for the testcase!
We've fixed it [1] on the trunk. Fix is going to be available in the next 1.9.37 release.
Thanks.
WBR,
Alexey.
[1]
http://java.net/jira/browse/GRIZZLY-1035
On 07/04/2011 02:09 PM, Gay David (Annecy) wrote:
Hi,
I'm back.
First thank you Alexey for your proposition, but it's little bit complex to shared our real server, mostly because the environment to run it is little bit complex to setup.
But, hopefully, I was able to reproduce the problem with a simple test case.
See the attach maven project.
When running it : mvn test I have most of the time theses errors :
4 juil. 2011 13:19:01 com.sun.grizzly.http.ProcessorTask invokeAdapter
GRAVE: GRIZZLY0038: HTTP Processing error.
java.lang.NullPointerException
at com.sun.grizzly.tcp.SuspendResponseUtils.attach(SuspendResponseUtils.java:61)
at com.sun.grizzly.tcp.Response.suspend(Response.java:945)
at com.sun.grizzly.tcp.Response.suspend(Response.java:884)
at com.acme.MyAdapter.service(MyAdapter.java:33)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
And less often this error :
4 juil. 2011 13:11:52 com.sun.grizzly.http.ProcessorTask parseRequest
GRAVE: GRIZZLY0040: Request header is too large.
java.nio.BufferOverflowException
at com.sun.grizzly.tcp.http11.InternalInputBuffer.fill(InternalInputBuffer.java:765)
at com.sun.grizzly.tcp.http11.InternalInputBuffer.parseHeader(InternalInputBuffer.java:615)
at com.sun.grizzly.tcp.http11.InternalInputBuffer.parseHeaders(InternalInputBuffer.java:555)
at com.sun.grizzly.http.ProcessorTask.parseRequest(ProcessorTask.java:875)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:692)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Could you have a look and tell me what I doing wrong.
BTW : In my real server, I was not able to reproduce theses errors. But now I have always that :
2011-07-04 08:48:30,103 GMT+0000 - [UploadRequest-1] WARN (ResourceUploadImpl.writeBytes:194) - Error while reading from the request for upload
java.io.IOException: Invalid chunk header
at com.sun.grizzly.tcp.http11.filters.ChunkedInputFilter.doRead(ChunkedInputFilter.java:173)
at com.sun.grizzly.tcp.http11.InternalInputBuffer.doRead(InternalInputBuffer.java:744)
at com.sun.grizzly.tcp.Request.doRead(Request.java:501)
at com.sun.grizzly.tcp.http11.GrizzlyInputBuffer.realReadBytes(GrizzlyInputBuffer.java:327)
at com.sun.grizzly.util.buf.ByteChunk.substract(ByteChunk.java:431)
at com.sun.grizzly.tcp.http11.GrizzlyInputBuffer.read(GrizzlyInputBuffer.java:349)
at com.sun.grizzly.tcp.http11.GrizzlyInputStream.read(GrizzlyInputStream.java:203)
at com.axway.darwin.server.core.http.impl.upload.ResourceUploadImpl.writeBytes(ResourceUploadImpl.java:185)
at com.axway.darwin.server.core.http.impl.upload.UploadExecutor.run(UploadExecutor.java:51)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
I'm still trying to reproduce this "Invalid chunk header" error with a simple test case, but I hope that the current test will helps me point out what's wrong.
Regards and thanks for your help
David
De : Oleksiy Stashok [mailto:oleksiy.stashok_at_oracle.com]
Envoyé : mardi 28 juin 2011 17:19
À : users_at_grizzly.java.net<mailto:users_at_grizzly.java.net>
Objet : Re: Grizzly Suspend
hi David,
as i told, it would be great if you can share the code (may be privately).
Cause it's really difficult to guess what's wrong :(
Thanks.
WBR,
Alexey.
On 06/28/2011 03:32 PM, Gay David (Annecy) wrote:
Hi all,
I'm back to the code ... :-) I'm still fighting with my issue with Grizzly.
I was able to made some progress and see and fix some bad exception management in my code.
I now have less problem. But still have this one on heavy load :
2011-06-28 15:18:43,320 GMT+0200 - [Grizzly-8090(2)] WARN (AdapterMapper.service:156) - Error while servicing HTTP request
java.lang.NullPointerException
at com.sun.grizzly.tcp.SuspendResponseUtils.attach(SuspendResponseUtils.java:61)
at com.sun.grizzly.tcp.Response.suspend(Response.java:945)
at com.sun.grizzly.tcp.Response.suspend(Response.java:884)
at com.axway.drw.core.http.internal.AdapterMapper.service(AdapterMapper.java:122)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
The line 945_at_Response is this one :
SuspendResponseUtils.attach(selectionKey, ra);
And it fails with a NPE inside SuspendResponseUtils.attach(...) because obviously, the selectionKey attribute of the response object pass in the method service(...) is null !
Could someone that know well the Grizzly internal gives me some hint or clue, of what could be the cause of this situation ?
I'm sure I am doing something wrong, but right now, still unable to reproduce with a simple test case.
Thanks and regards
David
De : Gay David (Annecy)
Envoyé : mercredi 15 juin 2011 17:02
À : 'users_at_grizzly.java.net<mailto:users_at_grizzly.java.net>'
Objet : Grizzly Suspend
Hi all,
I'm using Grizzly 1.9.35 and I have a problem with the suspend/resume feature.
Basically, I delegate to some threads the Grizzly request.
So, in my adapter, in the method service( request, response ) I do :
- response.suspend( ... )
- give the request to my own worker, and when it's finish, call response.resume()
Sometimes, under heavy load, I have a problem, when I ask to suspend the request I have this error :
2011-06-15 16:06:39,340 GMT+0200 - [Grizzly-8090(4)] ERROR (AdapterMapper.service:122) - Error while trying to suspend a request
java.lang.NullPointerException
at com.sun.grizzly.tcp.SuspendResponseUtils.attach(SuspendResponseUtils.java:61)
at com.sun.grizzly.tcp.Response.suspend(Response.java:945)
at com.sun.grizzly.tcp.Response.suspend(Response.java:884)
at com.axway.drw.core.http.internal.AdapterMapper.service(AdapterMapper.java:118)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
I should do something wrong somewhere.
Can someone suggest me what could be the cause of this error ?
Maybe this error suggest that a miss to resume somewhere ?
Could it be a Grizzly problem ?
This is a simplify code of my adapter :
@Override
public void service( Request req, Response res ) throws Exception {
try {
res.suspend( Long.MAX_VALUE, someDataForTheCompletion, new MyCompletionHandler(req,res) );
}
catch ( Exception ex ) {
log.log( SEVERE, "Error while trying to suspend a request", ex );
}
try {
AsynchronousRequest asyncReq = new AsynchronousRequest( req, res );
getMyExecutor().register( asyncReq );
}
catch( RejectedExecutionException ex ) {
res.setStatus( 509 );
res.setMessage( "Too many requests" );
res.resume();
log.log( INFO, "Asynchronous request cannot be treated by the server: too many requests" );
}
}
As you see, if my executor is too busy, it set an http error and resume the response. It means that sometimes, the resume is in the Grizzly thread, sometimes not.
Thanks for any help
Regards, David.