Hi Ramesh,
Ramesh wrote:
> 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 ...
PU is not the right component (sorry). ARP was designed exactly for what
you have described (2 years ago, hence quite stable in 1.0).
Also I was under the impression that PU 1.0 was used in Sailfin, not
1.6. Have you switch to 1.6?
>
> 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
Sorry but 1.0 is dead. We are supporting it only for bug fixes (9.1
ur1), and no changes are allowed anyway in that workspace.
Did I said many times to the Sailfin team that they should go with 1.6
all over the place ;-) :-)
Thanks
-- Jeanfrancois
>
> 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
>