One thing I hate when I install an application server is the process of determining which and how many TCP ports the application is reserving. On a shared machine, It’s even worse because you need to manually change all the reserved ports to start the application server. Since GlassFish define a lot of ports, I sometime gives up and find another machine. There is still pain because I always have to learn which port support which protocol and under which transport etc. Naaa that sucks. I would like to have a single port to change and run all my requests by that port. The good news is with the help of Grizzly, GlassFish v2 can now define a single port that can be used to serve several protocols and transports(not all yet). Even better, its is easy extend the Grizzly Port Unification mechanism to do whatever you want with the request.
Welcome to the Grizzly Port Unification mechanism!
- ProtocolFinder: This is where you define the logic to determine which protocol is used. From a series of bytes, a ProtocolFinder will try to determine which protocol is used or which transport. As an example, GlassFish by default will install the HttpProtocolFinder and the HttpsProtocolFinder.
- ProtocolHandler: Once the protocol has been determined, its associated ProtocolHandler will be invoked. ProtocolHandler can do whatever they want, like invoking the appropriate internal container (ex: the EJB container), load balance requests and forward them to an external entity, deliver the request to an embedded container (ex: Jetty), etc.
Below is some possible scenarios:
|Client send||ProtocolHandler||Server Endpoint|
|http://…:4848||Deliver to the WebContainer|| http://….:4848|
|https://…:4848||Redirect to the proper transport||http://….:4848|
|http://…/cometd:4848||Forward the request to Jetty Cometd server|| http://jetty.mortbay.org/cometd:8888|
|iiop://…:4848||Deliver the request to the EJB container directly||No IIOP port opened|
I know I know, in some scenario you wouldn’t want to redirect from https to http :-).
As usual, this feature is not “officially” supported in GlassFish’s domain.xml (we have a very strict process in place internally….not sure it is as open as I would like it to be….OK I stop whining as I needed the property for Grizzly standalone support anyway :-)). To add your own ProtocolFinder and ProtocolHandler, you need to manually add two jvm-options, in domain.xml:
<jvm-options>-Dcom.sun.enterprise.web.connector.grizzly.protocolHandlers= com.sun.enterprise.web.portunif.protocols.http.HttpProtocolHandler</jvm-options> <jvm-options>-Dcom.sun.enterprise.web.connector.grizzly.protocolFinders= com.sun.enterprise.web.portunif.protocols.http.HttpsProtocolFinder, com.sun.enterprise.web.portunif.protocols.http.HttpProtocolFinder</jvm-options>
The above configuration will configure Grizzly Port Unification to first look for the http protocol, then for the https transport, and then try again the http protocol.
Eventually, we gonna consolidate all GlassFish ports to a single one by writing the appropriate ProtocolFinder and ProtocolHandler. Looks promising, does it? At least just for me, having one port to modify will saves my time…
The mechanism will most probably be officially enabled in build 25 if all my testing goes well, and this include making sure the performance of Grizzly is not reduced by such mechanism.
_uacct = “UA-3111670-1”;