Jeanfrancois Arcand wrote:
> Hi,
>
> Binod wrote:
>
>> Jeanfrancois Arcand wrote:
>>
>>> 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.
>>
>>
>> That is okay, if the container is fairly easily separable from the
>> framework.
>
>
> Agreed.
>
>> What about ORB? Has it modified so that ORB startup is separated from
>> grizzly? Is that happening in 9.1?
>
>
> This mechanism is not planned to be used by the ORB in the 9.1 time
> frame. The goal is to enable it for:
>
> + the admin port to redirect a wrong protocol (http instead of https,
> or vice versa) or wrong port (4849 -> 4848)
> + WSIT integration on HTTP(s) ports.
>
>>
>>>
>>>> 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 :-)
>>
>>
>> In the other thread you mentioned that, we will depend on unified
>> port to
>> get the quickstartup working.
>
> If the container is separated from the
>
>> listener, then we could still manage to figure out which container to
>> start
>> based on the port that is being accessed, right?
>
>
> I'm not sure I follow you here. If there is only one port, then we
> don't need to know which container listen on which port. The
> fundamental difference between QS and PU is the way the mapping to a
> container is done.
>
> QS: port --> container
> PU: protocol|transport --> container
>
> PU can be configured to 'mimic' QS behavior by opening several ports
> (4848,3737,8080.3920) and maps the request from those ports to the
> proper container. But PU allow more by supporting the following:
>
> Client Server Port Container
> ---------------------------------------------------------
> IIOP 3737 ORB
> HTTPS 3737 Web
> SOAP/Bin 4848 WSIT
> IIOP 4848 ORB
> HTTP 4848 Web
>
> The major difference between the two mechanisms is with QS, you
> integrate at the JDK NIO level (NIO provider), hence all current
> containers can be supported without major modifications. With PU, all
> containers must be modified to avoid handing OP_ACCEPT (accept()) or
> they need to listen to a local port (127.0.0.1) so PU can redirect the
> request locally. A container that wants to integrate with PU needs to
> implements two interfaces:
> + ProtocolFinder: The low level code that will determine from the raw
> bytes the protocol|transport.
> + ProtocolHandler: the hook between PU and the targeted Container.
> This is where the overlap happens between QS and PU. An implementor of
> ProtocolHandler can decide when to start the Container (e.g. when the
> ProtocolHandler is initialized, on the first request, etc.)
>
> Just to recap, PU main goal is to map the protocol|transport to a
> container in order to reduce the number of opened ports. You can do
> lazy initialization, but that's not the main role of PU.
I thought Jerome's original question was, since grizzly will be used (I
dont know when) as the only NIO/socket framework
in appserver (for ORB, Web, MQ etc), can we use grizzly as the only
socket interceptor and use that only interceptor as
an entrypoint in the ondemand framework instead of my socket interceptor.
For this, grizzly v2, should probably have the notion of a simple
listener that listen on a selector, without perhaps initializing
the thread pool and the protocol handler. Based on the port or the PU
protocol transport, we can decide to start the container.
Jerome, in short, for what you were proposing, container startup should
be independent of its' nio framework startup.
I am not sure, if containers have that capability today or if they are
planning to do something like that.
All Jeanfrancois is telling is that even with PU, we can make QS
continue to work. JF, did I get it right?
- Binod.
>
> Thanks
>
> -- Jeanfrancois
>
>
>
>
>
>>
>> - Binod.
>>
>>>
>>> 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
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>