Hi Alexey,
Oleksiy Stashok wrote:
> Hello guys,
>
> Ramesh, think it makes sense to extend current PortUnificationPipeline
> by some SailfinPortUnificationPipeline and add functionality you need
> there.
> Next question is "how to plug custom port unification pipeline". From
> code I see now, it's not possible in Grizzly 1.0, but making small
> change to GrizzlyHttpProtocol class makes this possible.
>
> Jeanfrancois, I know you're pretty conservative in making changes to
> Grizzly 1.0 codebase, but think making port unification pipeline
> pluggable is quite safe change, which will make Grizzly more extendable.
>
> What do you think?
-1.
Any changes to 1.0 is not allowed because it can break too many existing
product (only bug fixes). The Sailfin team *cannot* make any changes to
the 1.0 code base (this is an internal politic as well).
Thanks
-- Jeanfrancois
>
> Thanks.
>
> WBR,
> Alexey.
>
> Ramesh Parthasarathy wrote:
>> Hi JeanFrancois,
>> I tried to extend the PU mechanism in Grizzly 1.0 ([1]) and
>> implement a
>> way by which we can park the request (release the resources and keep the
>> channel alive). Could you please review the changes, i have attached
>> them.
>> Briefly, i have just propagated the selectorthread through the
>> protocolinfo object so that the callback handler can take the decision
>> of canceling/registering the key back on the selector thread once the
>> response is complete. Also i have refactored the DefaultReadTask so that
>> the resources can be released appropriately.
>>
>>
>> Thanks
>> -Ramesh
>>
>>
>> Jeanfrancois Arcand wrote On 09/25/07 17:45,:
>>
>>> Hi Ramesh,
>>>
>>> thanks for not having private discussions :-)
>>>
>>> Ramesh wrote:
>>>
>>>
>>>> Hi JeanFrancois,
>>>> please find responses inline
>>>> (ccied dev alias)
>>>>
>>>>
>>>> Jeanfrancois Arcand wrote:
>>>>
>>>>
>>>>> Hi Ramesh,
>>>>>
>>>>> removing mridul, adding Alexey. Can we have this discussion on the
>>>>> dev alias? I'm sure a lot of peoples can collaborate :-)
>>>>>
>>>>> Ramesh wrote:
>>>>>
>>>>>
>>>>>> Hi JeanFrancois,
>>>>>> I looked at ARP code flow. The DefaultProcessorTask is always
>>>>>> initialized (in AsynReadTask) and the AsyncProcessorTask is just a
>>>>>> wrapper around the DefaultProcessorTask I guess it would be
>>>>>> inefficient to initialize a processor task even before we know if
>>>>>> we will actually be processing the request in the local container.
>>>>>>
>>>>> Yes, but I'm not longer following what you are trying to achieve ;-)
>>>>>
>>>>>
>>>>>
>>>> Our intention has always been to intercept a http request at the
>>>> earliest possible oppurtunity.. If we had our implementation of
>>>> Asynchandler and AsyncFilter, the only concern was that we will be
>>>> doing the interception after some of the artifacts have been created
>>>> (or initialized), which actually may not be required if this request
>>>> was going to be forwarded and not processed locally.
>>>>
>>>>
>>>>
>>>>>> If we intercept the request at the AsyncFilter, would it be not
>>>>>> expensive because we would be creating Processor tasks (which in
>>>>>> turn intializes request, response...) for every request.
>>>>>>
>>>>> Ouf..and good you care about performance :-) I recommended PU at
>>>>> the beginning of the project and that still applies :-) But if you
>>>>> need to park connection, you just need to write an AsyncFilter and
>>>>> enable ARP (only in that case) from your PU Handler. So you take
>>>>> the ARP way only when required.
>>>>>
>>>>>
>>>> Iam sorry , i did not understand this (still learning ARP :-)). Are
>>>> you suggesting we still use PU pipeline along with our
>>>> implementation of the ARP classes (asynchandler and asyncfilter).
>>>> Would this enable the handler to control the task execution
>>>> (park/resume).
>>>>
>>> ARP can be combined with PU. To enable ARP, you just call
>>> SelectorThread.setAsyncExecution(true). Now a possible solution for
>>> you would consist of writing your own AsyncHandler to decide if the
>>> request needs to be parked or not. To recap, if you need to park
>>> requests, you have four solutions:
>>>
>>> [1] Extends Port Unification mechanism (like you already did) and
>>> write your own way of parking the request.
>>> [2] Extends Port Unification, programmatically configure ARP (You can
>>> take a look at how openESB is doing it) to park only the requests you
>>> are interested
>>> [3] Extends ARP's AsyncHandler (you can replace the default
>>> programmatically using the SelectorThread API)
>>> [4] Write your own Pipeline Grizzly 1.0 (similar to the Port
>>> Unification Pipeline). Inside that Pipeline, first detect if the
>>> request has to be serviced locally or remotely. If locally, just call
>>> super.addTask(). If remotely, get an AsyncReadTask and execute it
>>> assuming you have written your AsyncHandler).
>>>
>>>
>>>
>>>> Also right now ARP can be enabled by setting system properties, is
>>>> there a programmatic way (API) for setting the ARP implementation
>>>> classes on the selector thread.
>>>>
>>> Yes, you can configure the AsyncHandler, AsyncExecutor and
>>> AsyncFilter from the SelectorThread.
>>>
>>> Hope that help.
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>
>>>
>>>> -Ramesh
>>>>
>>>>
>>>>> Hope that help....
>>>>>
>>>>> Thanks
>>>>>
>>>>> -- Jeanfrancois
>>>>>
>>>>>
>>>>>
>>>>>> Thanks
>>>>>> -Ramesh
>>>>>>
>>>>>> Mridul Muralidharan wrote:
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I had plugged it into grizzly as part of the http processing ...
>>>>>>> after the request has been read, and before invoking the servlet
>>>>>>> container.
>>>>>>>
>>>>>>> Also, I was using what was exposed through grizzly (actually,
>>>>>>> whatever was in daily builds then ... glassfish2 b54 or
>>>>>>> thereabouts - grizzly 1.6 I guess).
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Mridul
>>>>>>>
>>>>>>> Ramesh wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Hi JeanFrancois,
>>>>>>>> The requirements we have from the http proxy/clb in sailfin are
>>>>>>>>
>>>>>>>> 1. Intercept every Http request at the earliest possible time,
>>>>>>>> this would be using Grizzly 1.0, i don't think we are planning
>>>>>>>> to move to 1.6 on the server side.
>>>>>>>> 2. Parse the request line and headers..
>>>>>>>> 3. Support a pluggable invocation model so that interceptors can
>>>>>>>> be invoked on the request.
>>>>>>>> 4. The HA CLB (being one of the interceptors) takes a routing
>>>>>>>> decision based on the headers and request line. It identifies
>>>>>>>> the instance that needs to process this request. And the action
>>>>>>>> taken could be one of (5) or (6)
>>>>>>>> 5. This instance identified could be the local instance (the
>>>>>>>> container in the same instance) in which case it has to be
>>>>>>>> treated like a normal http request to a glassfish instance...
>>>>>>>> (nothing fancy needs to be done here))
>>>>>>>> 6. The instance is a remote instance in which case it has to be
>>>>>>>> forwarded to a remote instance, this would be using Grizzly 1.6
>>>>>>>> client APIs, the client channel has to be parked and a new
>>>>>>>> connection opened with the remote instance, the remote instance
>>>>>>>> might respond immediately or after some time, so we need to
>>>>>>>> asynchronously write data to the client channel whenever we
>>>>>>>> receive the response.
>>>>>>>> 7. We also have to support SSL from the http client to the front
>>>>>>>> end server, from the clb/proxy to any of the target instances
>>>>>>>> internally , we would not be using SSL. Basically the ssl off
>>>>>>>> loading takes place at the clb and we only propagate the cert
>>>>>>>> and auth information through http headers (just like we do
>>>>>>>> currently in the native-lb)
>>>>>>>> 8. Needless to say , the solution has to be scalable and
>>>>>>>> performant :-).
>>>>>>>>
>>>>>>>> Could you please advice if using ARP is the best way to satisfy
>>>>>>>> these requirements, and not PU.
>>>>>>>> Especially can (5) and (7), be satisfied. with ARP. Also the
>>>>>>>> clb/proxy feature can be configuratively turned off (in
>>>>>>>> domain.xml). Would it be possible to turn off ARP in such a case..
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> -Ramesh
>>>>>>>>
>>>>>>>> Jeanfrancois Arcand wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi Ramesh, Mridul
>>>>>>>>>
>>>>>>>>> Mridul, do you still have the code you did when you extended
>>>>>>>>> Grizzly ARP. I know your final version is using Comet, but
>>>>>>>>> Ramesh is intersted about ARP and would like to see your code,
>>>>>>>>> if possible.
>>>>>>>>>
>>>>>>>>> Ramesh, checkout the JRuby module under Grizzly which contains
>>>>>>>>> a very simple example of an ARP AsyncFilter implementation.
>>>>>>>>>
>>>>>>>>> BTW I'm in Santa Clara this week for AjaxWorld and I will be in
>>>>>>>>> an out.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> -- Jeanfrancois
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ramesh wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi JeanFrancois,
>>>>>>>>>>
>>>>>>>>>> Could you please point me to the code (Sun Instant
>>>>>>>>>> Messenger) that uses ARP.
>>>>>>>>>>
>>>>>>>>>> Pls note: I have not ccied dev_at_grizzly, because i though the
>>>>>>>>>> Sun Messenger code is not open source
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> -Ramesh
>>>>>>>>>>
>>>>>>>>>> Jeanfrancois Arcand wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi Ramesh,
>>>>>>>>>>>
>>>>>>>>>>> Ramesh wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Currently you can propogate a custom data using Context
>>>>>>>>>>>>>
>>>>>>>>>>>> attributes. Is it enough?
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, should be enough in 1.6.1... ,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> I didn't think about possibility to dynamically switch the
>>>>>>>>>>>>>
>>>>>>>>>>>> protocol during connection lifecycle. But think it's not a
>>>>>>>>>>>> problem to add this feature.
>>>>>>>>>>>>
>>>>>>>>>>>> It depends on which life-cycle do we choose to associate a
>>>>>>>>>>>> handler, it could be for the lifetime of a selectionkey or
>>>>>>>>>>>> it could be for the lifetime of a request. Thats why i
>>>>>>>>>>>> propose to leave this to the handler itself so that the
>>>>>>>>>>>> design is flexible. We could add another attribute in the
>>>>>>>>>>>> PUProtocolRequest through which we can propagate whether or
>>>>>>>>>>>> not to map the handler back to the key, and this can be
>>>>>>>>>>>> set/reset by the handler itself.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Do you have any specific usecase?
>>>>>>>>>>>>>
>>>>>>>>>>>> Yes , if we are implementing a http proxy behavior in the
>>>>>>>>>>>> handler, where we are going to forward the received bytes to
>>>>>>>>>>>> another server, then after we have sent the entire data, we
>>>>>>>>>>>> just have to wait for the response from the server, IMO it
>>>>>>>>>>>> is inefficient to just wait and block at the handler until
>>>>>>>>>>>> the response is received from the server, we could register
>>>>>>>>>>>> a callback to handle the response when it arrives, but if we
>>>>>>>>>>>> returned from the handler we have to ensure the channel is
>>>>>>>>>>>> kept alive so that the response can be sent back on it.
>>>>>>>>>>>>
>>>>>>>>>>> In that case you should explore Grizzlly ARP (Asynchronous
>>>>>>>>>>> Request Processing) [1]. This extension was done exactly to
>>>>>>>>>>> support that use case. Port unification is not the place to
>>>>>>>>>>> implement such feature IMO, as it role is to:
>>>>>>>>>>>
>>>>>>>>>>> 1. Find the protocol
>>>>>>>>>>> 2. Redirect the request to the proper endpoind.
>>>>>>>>>>>
>>>>>>>>>>> In you case, you should 'leave' the Handler and enter the
>>>>>>>>>>> Grizzly ARP mechanism (like Comet is doing. You can taste it
>>>>>>>>>>> by playing with the Sun Instant Messenger tool internally. It
>>>>>>>>>>> use ARP/Comet to park requests).
>>>>>>>>>>>
>>>>>>>>>>> That is why it would be good if we can
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> separate out the readkey registering from the keepalive
>>>>>>>>>>>> logic so that we can just keep the channel alive without
>>>>>>>>>>>> registering a OP_READ. We should be able to register a
>>>>>>>>>>>> OP_READ once the response has been written back completely.
>>>>>>>>>>>>
>>>>>>>>>>> Comet[2] is the solution, not Port Unification IMO.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>> -- Jeanfrancois
>>>>>>>>>>>
>>>>>>>>>>> [1]http://weblogs.java.net/blog/jfarcand/archive/2006/02/grizzly_part_ii.html
>>>>>>>>>>>
>>>>>>>>>>> [2]http://weblogs.java.net/blog/jfarcand/archive/2006/07/the_grizzly_com.html
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> -Ramesh
>>>>>>>>>>>>
>>>>>>>>>>>> Oleksiy Stashok wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello Ramesh,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ramesh Parthasarathy wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I will try to write a doc on how i have used PU, but it
>>>>>>>>>>>>>> might take some
>>>>>>>>>>>>>> time , so here are some initial thoughts
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> It could be very useful! Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. Though the Finder and the Handler are meant for
>>>>>>>>>>>>>> specific purposes,
>>>>>>>>>>>>>> the ProtocoInfo/PUProtocolRequest (or the Context in
>>>>>>>>>>>>>> Grizzly 1.6.1)
>>>>>>>>>>>>>> object is the only standard means of sharing data between
>>>>>>>>>>>>>> them, it would
>>>>>>>>>>>>>> be good if we could propagate custom data from the Finder
>>>>>>>>>>>>>> to the Handler
>>>>>>>>>>>>>> so that we dont have to redo work we might have already
>>>>>>>>>>>>>> done in the
>>>>>>>>>>>>>> Finder. This custom object could be propagated through the
>>>>>>>>>>>>>> ProtocolInfo
>>>>>>>>>>>>>> or any other means.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Currently you can propogate a custom data using Context
>>>>>>>>>>>>> attributes. Is it enough?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. The logic in the PUpipeline/PUFilter that determines
>>>>>>>>>>>>>> whether the
>>>>>>>>>>>>>> Finder has to be invoked. If i understand correctly for a
>>>>>>>>>>>>>> selection Key
>>>>>>>>>>>>>> oncer the Finder returns with a protocol, we create a map
>>>>>>>>>>>>>> of the key and
>>>>>>>>>>>>>> the handler and this holds good until the key is
>>>>>>>>>>>>>> valid/channel is alive.
>>>>>>>>>>>>>> So, any further data that is read on that channel will
>>>>>>>>>>>>>> result in the
>>>>>>>>>>>>>> invocation of the same handler. For e.g the data could be
>>>>>>>>>>>>>> more data for
>>>>>>>>>>>>>> the same http request or it could be a new http request on
>>>>>>>>>>>>>> the same
>>>>>>>>>>>>>> channel (if keep-alive). I guess it would be good if we
>>>>>>>>>>>>>> allowed the
>>>>>>>>>>>>>> handler to control the association of the key and the
>>>>>>>>>>>>>> handler, so that
>>>>>>>>>>>>>> the logic of determining whether the finder is invoked on
>>>>>>>>>>>>>> the next chunk
>>>>>>>>>>>>>> of data can be controlled by user logic.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Hmm. I was looking at port unification as mechanism how
>>>>>>>>>>>>> newly accepted connection could be classified and in future
>>>>>>>>>>>>> it will be processed by certain (single) ProtocolHandler.
>>>>>>>>>>>>> I didn't think about possibility to dynamically switch the
>>>>>>>>>>>>> protocol during connection lifecycle. But think it's not a
>>>>>>>>>>>>> problem to add this feature.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 3. The handler basically has to keep the channel alive
>>>>>>>>>>>>>> (return true),
>>>>>>>>>>>>>> until it is done using the channel. There may be
>>>>>>>>>>>>>> circumstances where the
>>>>>>>>>>>>>> handler is finished reading the entire data from the
>>>>>>>>>>>>>> channel, but it is
>>>>>>>>>>>>>> waiting (for some async event) to write more data into the
>>>>>>>>>>>>>> channel. In
>>>>>>>>>>>>>> such a case the channel has to kept alive (else the
>>>>>>>>>>>>>> cancelkey closed the
>>>>>>>>>>>>>> channel) . And if the channel is kept alive the key is
>>>>>>>>>>>>>> registered for
>>>>>>>>>>>>>> OP_READ ? Is there a way we can keep the channel alive and
>>>>>>>>>>>>>> indicate
>>>>>>>>>>>>>> somehow to the selector thread we are not expecting any
>>>>>>>>>>>>>> data to be read
>>>>>>>>>>>>>> as of now... Iam not sure if this is possible in 1.6.1
>>>>>>>>>>>>>> (sorry, i havent
>>>>>>>>>>>>>> gone through the 1.6.1 code in detail) , but it was
>>>>>>>>>>>>>> certainly difficult
>>>>>>>>>>>>>> in 1.0.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> You're right, in 1.6.1 PU works the same way. PUFilter
>>>>>>>>>>>>> should be usually added after the ReadFilter, and
>>>>>>>>>>>>> ReadFilter, by default, reregisters connection for reading
>>>>>>>>>>>>> when postProcess is called.
>>>>>>>>>>>>> But again if it's required - we can think about possibility
>>>>>>>>>>>>> to avoid reregistering on OP_READ.
>>>>>>>>>>>>> Do you have any specific usecase?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you!!!
>>>>>>>>>>>>>
>>>>>>>>>>>>> WBR,
>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please correct me if any of my observation is not correct.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> -Ramesh
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jeanfrancois Arcand wrote On 09/19/07 18:02,:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Kudo to Alexey, the Grizzly's port unification[1] used by
>>>>>>>>>>>>>>> GlassFish v2 (Grizzly 1.0) is now available as a sub
>>>>>>>>>>>>>>> module in Project Grizzly.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Port unification allow any server base application to
>>>>>>>>>>>>>>> support more than one protocol using a single tcp/udp/tls
>>>>>>>>>>>>>>> port. As as example, GlassFish v2 by default listen on
>>>>>>>>>>>>>>> port 8080 for http, https and Soap over tcp requests.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any volunteer to writes docs or tutorial? :-) :-)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Port Unification is currently available with version
>>>>>>>>>>>>>>> 1.6-SNAPSHOT and soon with 1.6.1.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -- Jeanfrancois
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://weblogs.java.net/blog/jfarcand/archive/2006/11/one_port_to_rul.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>>> dev-help_at_grizzly.dev.java.net
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>> dev-help_at_grizzly.dev.java.net
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>>>>>>>>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>>>>>>>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>>>>>>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>>>>>>>>
>>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>