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