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. 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.
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
>