Jeanfrancois Arcand wrote:
> 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).
If the changes are in a backward compatible way, will that be acceptable?
thanks,
Binod.
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>