Hi,
Thanks for the fix, I will give a try on this release.
Regards, David
From: Oleksiy Stashok [mailto:oleksiy.stashok_at_oracle.com]
Sent: mercredi 9 novembre 2011 17:04
To: users_at_grizzly.java.net
Subject: Re: Cancelling a response in Grizzly 2
Hi David,
we've fixed the issue
http://java.net/jira/browse/GRIZZLY-1113
currently releasing 2.1.7-SNAPSHOT and 2.2-SNAPSHOT which will contain the fix.
Thanks.
WBR,
Alexey.
On 11/04/2011 02:02 PM, Gay David (Annecy) wrote:
Hi Alexey,
Yes, I'm able to reproduce the behavior with the simple test case in attachement.
If you run the little maven project, you should see that :
I made one request, so the service method of handler should be call only once.
But if you look at the trace, it's call 2 times :
First time, it' normal :
SERVICE #0 / Grizzly(1)
java.lang.Exception: I Am here :
at com.acme.AsyncHandler.displayWhereAmI(AsyncHandler.java:91)
at com.acme.AsyncHandler.service(AsyncHandler.java:50)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:163)
at org.glassfish.grizzly.http.server.HttpHandlerChain.service(HttpHandlerChain.java:195)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:163)
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.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:829)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:103)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:111)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:131)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:508)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:488)
at java.lang.Thread.run(Thread.java:662)
Second time, the service method is call by my thread pool when I call the method cancel() :
SERVICE #1 / pool-1-thread-1
java.lang.Exception: I Am here :
at com.acme.AsyncHandler.displayWhereAmI(AsyncHandler.java:91)
at com.acme.AsyncHandler.service(AsyncHandler.java:50)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:163)
at org.glassfish.grizzly.http.server.HttpHandlerChain.service(HttpHandlerChain.java:195)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:163)
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.acme.AsyncUpload.cancelSafely(AsyncUpload.java:65)
at com.acme.AsyncUpload.run(AsyncUpload.java:48)
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)
Is it normal ?
Am I misunderstand what the method cancel() is for ?
BTW : if you display the stack trace at line 69 @ AsyncUpload.java you should see that an exception is raised when calling cancel () :
java.lang.IllegalStateException: Not Suspended
at org.glassfish.grizzly.http.server.Response$SuspendedContextImpl.markCancelled(Response.java:1816)
at org.glassfish.grizzly.http.server.Response.cancel(Response.java:1754)
at com.acme.AsyncUpload.cancelSafely(AsyncUpload.java:65)
at com.acme.AsyncUpload.run(AsyncUpload.java:48)
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)
Last info : I'm on Win7 / Java version is :
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
and Grizzly 2.1.5
Thanks for your help
Regards
David
From: Oleksiy Stashok [mailto:oleksiy.stashok_at_oracle.com]
Sent: jeudi 3 novembre 2011 17:03
To: users_at_grizzly.java.net<mailto:users_at_grizzly.java.net>
Subject: Re: Cancelling a response in Grizzly 2
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