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