Hi JeanFrancois,
Do you feel its impossible to accomplish it (the use case below)
using the PU, we have covered some distance in the implementation :-(
using PU ...
In 1.6 i see that Context is available to the handler and the finder,
which allows lot of flexibility at the handler to do what it wants with
the key (register/deregister) and the channel. But a similar construct
is not available in 1.0..., would it be good to have something similar
in 1.0
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
>