Hi,
I use the PortUnification mechanism (in Grizzly 1.0) for implementing
the http proxy functionality in sailfin (
https://sailfin.dev.java.net).
Its a very nice feature that allows plugging in new protocols or add new
capabilities to existing ones.
The requirements i had was to intercept every http request, and forward
it to another server (based on some condition). Basically, we are just
augmenting the way in which a http request can be handle and getting
away from the notion that a request to a (http) server should always
served by it. Here are some of the observations i made on the way and
possible improvements that can be done in the PortUnificationPipeline
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
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.
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.
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.
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
>