Hi,
Binod wrote:
> Not really. This doesnt really help delaying the startup a particular
> container.
>
I think a similar functionality can be achieved by first determining the
protocol|transport, and then delegate the request to the Grizzly
ProtocolHandler. The ProtocolHandler can then decide to start the
Container if the container wasn't already started. The only difference
with QuickStartup is the targeted container doesn't need to handle any
NIO/Socket accept() operations, but only the read/write
(OP_READ|OP_WRITE) socket operations.
> 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.
This is currently doable with Grizzly v1. Tango and Alaska use a very
small listener based on v1. The "problem" with Grizzly v1 is mainly it
strong dependencies with the HTTP protocol. You can use Grizzly v1 for
other protocols, but you always get an HTTP bonus implementation :-)
Thanks
-- Jeanfrancois
>
> - 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>