Mark Hig wrote:
> We have a light weight Enterprise Service Bus. I am replacing the connection
> management component with Grizzly. Grizzly will accept a message from a
> client and I have a Asynchronous adpater class in Grizzly that puts the
> request, response and the processTask that are created in Grizzly into a
> wrapper class. This wrapper class (event) then sits on a queue for later
> processing. The wrapper class may get put onto other queues as it progresses
> along its processing lifecycle through the ESB. When the wrapper class
> (event) is created it is registered with a timeout monitor. The timeout
> monitor will tell the event to timeout after a period of time. When the
> event times out it should close itself down and tidy up, freeing any
> resources e.g. connections, selector keys etc without writing any messages
> back to the client.
>
> Effectively we have a reference to an open connection sitting on a Selector
> within Grizzly (via the processorTask) and we need to be able to close that
> connection and free its resources (slector keys etc) at any point in the
> messages processing (event/wrapper class) life cycle.
Just call the following method and the connection will be resumed/closed:
// Finish the response
processorTask.postResponse();
// Clean up the objects
processorTask.postProcess();
Internally, Grizzly will make sure the connection is closed and the
associated recycled (for re-use).
Now based on the above description, have you take a look at Grizzly
Asynchronous Request Processing extension[1]? In that case, you can
easily handle your use case by writing an AsyncFilter[2]. Take a look at
this example from on of our users based [3]
A+
-- Jeanfrancois
[1]
http://weblogs.java.net/blog/jfarcand/archive/2006/02/grizzly_part_ii.html
[2]
https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/http/AsyncFilter.html
[3]
http://kasparov.skife.org/blog/src/java/grizzly-arp-basic.html
>
> Hope this clarifies.
>
>