users@grizzly.java.net

Re: Cancelling a response in Grizzly 2

From: Oleksiy Stashok <oleksiy.stashok_at_oracle.com>
Date: Thu, 03 Nov 2011 17:02:46 +0100

Hi David,

can you pls. create a test case for us?
Looks like this issue is easy to reproduce, isn't it?

Thanks.

WBR,
Alexey.

On 11/03/2011 04:32 PM, Gay David (Annecy) wrote:
>
> Hi all,
>
> I've got a strange stack trace and I need a Grizzly wizard to help me
> understand if I'm correct or not.
>
> _The context :_
>
> * I use Grizzly 2.1.5
>
> * I made my own HttpHandler for uploading files that :
>
> - suspend the response
>
> - gives the response processing to a thread pool
>
> * Each thread, read the request bytes and write the result somewhere...
>
> (I know, I do not use right now the async capability of Grizzly ;-)
>
> _The problem :_
>
> If, an error occurs while writing the bytes, I cancel the response :
> response.cancel()
>
> The problem is that I got this stack trace while resuming :
>
> 2011-11-03 11:37:40,311 GMT+0100 ERROR [UploadRequest-4]
> (HttpHandler.doHandle:165): service exception
>
> java.lang.IllegalStateException: Unexpected DataChunk type: String
>
> at
> org.glassfish.grizzly.http.server.Request.parseSessionId(Request.java:2215)
>
> at
> org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:162)
>
> at
> org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:161)
>
> at
> org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
>
> at
> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:286)
>
> at
> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:223)
>
> at
> org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:155)
>
> at
> org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:134)
>
> at
> org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:78)
>
> at
> org.glassfish.grizzly.filterchain.FilterChainContext$1.run(FilterChainContext.java:199)
>
> at
> org.glassfish.grizzly.filterchain.FilterChainContext.resume(FilterChainContext.java:223)
>
> at org.glassfish.grizzly.http.server.Response.cancel(Response.java:1756)
>
> at
> com.axway.test.core.http.impl.upload.ResourceUploadImpl.cancelResponseSafely(ResourceUploadImpl.java:237)
>
> at
> com.axway.test.core.http.impl.upload.ResourceUploadImpl.writeBytes(ResourceUploadImpl.java:185)
>
> at
> com.axway.test.core.http.impl.upload.UploadExecutor.run(UploadExecutor.java:51)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>
> at java.lang.Thread.run(Unknown Source)
>
> I understand why the method parseSessionId() fail. I don't think it
> the core problem here.
>
> (It's because in my HttpHandler I do :
> req.getRequest().getRequestURIRef().setDecodedURI( someHack() ) :-)
>
> What I don't understand is why the method doHandle() is call here when
> cancelling a request ?
>
> If I understand correctly, I already pass in my own HttpHandler :
> doHandle() -> service() ... ?
>
> Am I wrong ? I maybe don't understand what the method cancel() is for ?
>
> Do I need in every case to resume the response and set an error message ?
>
> Thanks for any tips.
>
> Regards.
>
> David
>