users@grizzly.java.net

Re: Grizzly Suspend

From: Oleksiy Stashok <oleksiy.stashok_at_oracle.com>
Date: Mon, 04 Jul 2011 16:06:40 +0200

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
> *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.
>