Jeanfrancois Arcand wrote:
> Salut,
>
> Jerome Dochez wrote:
>> this may just be an wild idea.
>>
>> could we use this mechanism to retrofit the QuickStartup ?
>
> Yes, if we listen on a single port, then when a request comes, we can
> derive the transport/protocol, and then start the appropriate
> endpoints (Container) based on the protocol and then deliver the request.
Excellent, Binod, could you spend some time looking into this and come
up with an estimate on how much time would be needed ? What I am really
looking into is a cleaner way to register (and subsequently unregister
once the server is fully started) the QS code.
>
> That would
>> avoid QuickStartup registering the socket listener...
>> In particular would that allow us to deactivate QuickStartup once the
>> appserver is fully started ?
>
> Yes, this is something we can do. The major difference with QS is the
> requests must be received on a single port.
really ? For now, could QS use the mechanism you put in place, still
starting several ports with the same number of protocol listeners ? Each
port listener would be used by QS to start the appropriate container.
The idea is really to use the mechanism without necessarily unifying our
ports (yet).
>
> Thanks
>
> -- Jeanfrancois
>
>
>
>
>>
>> Jerome
>>
>> Jeanfrancois Arcand wrote:
>>> Hi,
>>>
>>> I've recently committed support in Grizzly[1] a port unification
>>> mechanism that allow the discovery of the TCP request protocol and
>>> transport. When enabled, a single port can listen to any TCP
>>> requests (clean text or TLS/SSL) and dispatch the request to the
>>> targeted Container (HTTP, SOA, etc.). Technically, it means we can
>>> open a single TCP port and support multiple protocols (http, https,
>>> IIOP, SOAP/TCP, etc.)
>>>
>>> By default, I've added support for HTTP protocol (clean text and
>>> SSL), which means we can support the following use case. If the
>>> wrong transport is used, Grizzly will automatically redirect to the
>>> proper transport|protocol:
>>>
>>> admin-listener listening on port 4848 and secure-enabled = false
>>>
>>> Client request Server port
>>>
>>> http://...:4848 --> http://....:4848
>>> https://...:4848 --> http://....:4848
>>>
>>> admin-listener listening on port 4848 and secure-enabled = true
>>>
>>> http://...:4848 --> https://....:4848
>>> https://...:4848 --> https://....:4848
>>>
>>> The HTTP protocol handler can also support the following use case
>>> where the wrong port is invoked:
>>>
>>> admin-listener listening on port 4848 and secure-enabled = false
>>>
>>> https://...:4849 --> http://....:4848
>>> http://...:4849 --> http://....:4848
>>>
>>> admin-listener listening on port 4848 and secure-enabled = true
>>>
>>> https://...:4849 --> https://....:4848
>>> http://...:4849 --> https://....:4848
>>>
>>> Another protocol we currently have an implementation is the SOAP/TCP
>>> (for WSIT support).
>>>
>>> Now for 9.1, I would like to enable the mechanism for port 4848 (to
>>> fix [2]). Since we also need to support SOAP/TCP from WSIT, should
>>> we enable it as well for all http port?
>>>
>>> We need to keep the functionality configurable because it introduce
>>> a tiny performance regression (needs to discover the
>>> protocol|transport). Also no domain.xml changes are required, as the
>>> mechanism is supported via a http-listener property.
>>>
>>> Thanks
>>>
>>> -- Jeanfrancois
>>>
>>> [1]
>>> https://glassfish.dev.java.net/source/browse/glassfish/appserv-http-engine/src/java/com/sun/enterprise/web/portunif/
>>>
>>> [2] https://glassfish.dev.java.net/issues/show_bug.cgi?id=741
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>