users@grizzly.java.net

Re: Async processing and 1.8.3 problem

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Thu, 17 Jul 2008 11:41:58 -0400

Salut,

Mark Hig wrote:
> Hi all.
> Hoping you can help.

This is all

I am developing an Asyncronous server based on Brian
> McAllisters example asynchronous server
> (http://kasparov.skife.org/blog/src/java/grizzly-arp-basic.html). Since
> upgrading to 1.8.3 I am getting the following error in the following code:
>
> public boolean doFilter(final AsyncExecutor executor)
> {
> final AsyncTask asyncTask = executor.getAsyncTask();
> final AsyncHandler asyncHandler = executor.getAsyncHandler();
>
> final DefaultProcessorTask processorTask = (DefaultProcessorTask)
> executor.getProcessorTask();
> //final DefaultProcessorTask processorTask = (DefaultProcessorTask)
> executor.getAsyncTask().getProcessorTask();
>
>
> if (CALLBACK_KEY == null)
> {
> throw new GrizzlyServiceException("Grizzly OSRServerAsyncFilter
> cannot run the filter without the callback object being set for Asynchronous
> operation.");
> }
>
> //This handles the callback from the disconnected task
> processorTask.getRequest().setAttribute(CALLBACK_KEY, new Runnable()
> {
> public void run()
> {
> System.out.println("------->Running async task " + this);
> asyncHandler.handle(asyncTask);
> }
> });
>
> //This puts the processorTask(Connection info) into the request
> object for later use.
>
> processorTask.getRequest().setAttribute(PROCESSOR_TASK_KEY,processorTask);
> processorTask.invokeAdapter();
>
> return false;
> }
>
>
>
> java.lang.ClassCastException: com.sun.grizzly.arp.AsyncProcessorTask cannot
> be cast to com.sun.grizzly.http.ProcessorTask
> at
> com.sun.grizzly.arp.DefaultAsyncHandler.handle(DefaultAsyncHandler.java:144)
> at test.osr.OSRAsyncFilter$1.run(OSRAsyncFilter.java:60)


My bad. I've removed support for invoking the handle method twice.
Instead, can you just do:

AsyncProcessorTask.execute();

that will do the same things that AsyncHandler.handle();

I guess I need to re-add the behavior supported before...but I've found
some issues with the previous implementation, and that's why I've
changed the behavior. Looks like I need to re-think...

Apology for the mess.

A+

-- Jeanfrancois


> at test.osr.adapter.IConnectionAdapter.write(IConnectionAdapter.java:160)
> at
> com.fujitsu.poa.bal.osr.sif.StringBufferedResponse.writeToConnection(StringBufferedResponse.java:49)
> at
> com.fujitsu.poa.bal.osr.sif.OSRBALResponse.sendResponseToSource(OSRBALResponse.java:161)
> at
> com.fujitsu.poa.bal.osr.sif.SyncRoutingStrategy.routeService(SyncRoutingStrategy.java:63)
> at
> com.fujitsu.poa.balf.sif.SwitchableDefaultServiceRouter.routeService(SwitchableDefaultServiceRouter.java:58)
> at
> com.fujitsu.poa.bal.osr.sif.SIFContainerNew.routeRequestService(SIFContainerNew.java:149)
> at com.fujitsu.poa.bal.osr.event.RequestEvent.run(RequestEvent.java:62)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
> at java.lang.Thread.run(Thread.java:619)
>
>
> It looks like the AsyncHandler on the callbacl to complete the Grizzly
> processing is now expecting a different object type of DefaultProcessorTask
> raher than the AsyncTask it used to accept.
>
> Any help will be appreciated.
>
> Thanks
>
> Mark.