Not really. This doesnt really help delaying the startup a particular
container.
One of the things, which I hope/thought grizzly v2 will solve is to have
the ability to
start a very small listener against starting the whole NIO framework. If
that is
possible and when MQ start using grizzly v2, on-demand framework can use
a listener in the grizzly framework and stop using its own listener.
- Binod.
> this may just be an wild idea.
>
> could we use this mechanism to retrofit the QuickStartup ? That would
> avoid QuickStartup registering the socket listener...
> In particular would that allow us to deactivate QuickStartup once the
> appserver is fully started ?
>
> 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
>