Hi,
Binod wrote:
> 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.
Got it. Yes, that's a possibility but I doubt we will implement it for
9.1. Some container will works, but not all of them.
>
> 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.
Yes this is how it id done right now in the proposed code.
>
> 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?
Yes. Since QS is fronting PU right now, and PU only apply to the
WebContainer ports.
Thanks
-- Jeanfrancois
>
> - 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>