Hi JeanFrancois,
please find responses inline
(ccied dev alias)
Jeanfrancois Arcand wrote:
> Hi Ramesh,
>
> removing mridul, adding Alexey. Can we have this discussion on the dev
> alias? I'm sure a lot of peoples can collaborate :-)
>
> Ramesh wrote:
>> Hi JeanFrancois,
>> I looked at ARP code flow. The DefaultProcessorTask is always
>> initialized (in AsynReadTask) and the AsyncProcessorTask is just a
>> wrapper around the DefaultProcessorTask I guess it would be
>> inefficient to initialize a processor task even before we know if we
>> will actually be processing the request in the local container.
> Yes, but I'm not longer following what you are trying to achieve ;-)
>
>
Our intention has always been to intercept a http request at the
earliest possible oppurtunity.. If we had our implementation of
Asynchandler and AsyncFilter, the only concern was that we will be doing
the interception after some of the artifacts have been created (or
initialized), which actually may not be required if this request was
going to be forwarded and not processed locally.
>> If we intercept the request at the AsyncFilter, would it be not
>> expensive because we would be creating Processor tasks (which in turn
>> intializes request, response...) for every request.
>
> Ouf..and good you care about performance :-) I recommended PU at the
> beginning of the project and that still applies :-) But if you need to
> park connection, you just need to write an AsyncFilter and enable ARP
> (only in that case) from your PU Handler. So you take the ARP way only
> when required.
>
Iam sorry , i did not understand this (still learning ARP :-)). Are you
suggesting we still use PU pipeline along with our implementation of the
ARP classes (asynchandler and asyncfilter). Would this enable the
handler to control the task execution (park/resume).
Also right now ARP can be enabled by setting system properties, is there
a programmatic way (API) for setting the ARP implementation classes on
the selector thread.
-Ramesh
> Hope that help....
>
> Thanks
>
> -- Jeanfrancois
>
>>
>> Thanks
>> -Ramesh
>>
>> Mridul Muralidharan wrote:
>>>
>>> Hi,
>>>
>>> I had plugged it into grizzly as part of the http processing ...
>>> after the request has been read, and before invoking the servlet
>>> container.
>>>
>>> Also, I was using what was exposed through grizzly (actually,
>>> whatever was in daily builds then ... glassfish2 b54 or thereabouts
>>> - grizzly 1.6 I guess).
>>>
>>>
>>> Regards,
>>> Mridul
>>>
>>> Ramesh wrote:
>>>> Hi JeanFrancois,
>>>> The requirements we have from the http proxy/clb in sailfin are
>>>>
>>>> 1. Intercept every Http request at the earliest possible time, this
>>>> would be using Grizzly 1.0, i don't think we are planning to move
>>>> to 1.6 on the server side.
>>>> 2. Parse the request line and headers..
>>>> 3. Support a pluggable invocation model so that interceptors can
>>>> be invoked on the request.
>>>> 4. The HA CLB (being one of the interceptors) takes a routing
>>>> decision based on the headers and request line. It identifies the
>>>> instance that needs to process this request. And the action taken
>>>> could be one of (5) or (6)
>>>> 5. This instance identified could be the local instance (the
>>>> container in the same instance) in which case it has to be treated
>>>> like a normal http request to a glassfish instance... (nothing
>>>> fancy needs to be done here))
>>>> 6. The instance is a remote instance in which case it has to be
>>>> forwarded to a remote instance, this would be using Grizzly 1.6
>>>> client APIs, the client channel has to be parked and a new
>>>> connection opened with the remote instance, the remote instance
>>>> might respond immediately or after some time, so we need to
>>>> asynchronously write data to the client channel whenever we receive
>>>> the response.
>>>> 7. We also have to support SSL from the http client to the front
>>>> end server, from the clb/proxy to any of the target instances
>>>> internally , we would not be using SSL. Basically the ssl off
>>>> loading takes place at the clb and we only propagate the cert and
>>>> auth information through http headers (just like we do currently in
>>>> the native-lb)
>>>> 8. Needless to say , the solution has to be scalable and performant
>>>> :-).
>>>>
>>>> Could you please advice if using ARP is the best way to satisfy
>>>> these requirements, and not PU.
>>>> Especially can (5) and (7), be satisfied. with ARP. Also the
>>>> clb/proxy feature can be configuratively turned off (in
>>>> domain.xml). Would it be possible to turn off ARP in such a case..
>>>>
>>>> Thanks
>>>> -Ramesh
>>>>
>>>> Jeanfrancois Arcand wrote:
>>>>> Hi Ramesh, Mridul
>>>>>
>>>>> Mridul, do you still have the code you did when you extended
>>>>> Grizzly ARP. I know your final version is using Comet, but Ramesh
>>>>> is intersted about ARP and would like to see your code, if possible.
>>>>>
>>>>> Ramesh, checkout the JRuby module under Grizzly which contains a
>>>>> very simple example of an ARP AsyncFilter implementation.
>>>>>
>>>>> BTW I'm in Santa Clara this week for AjaxWorld and I will be in an
>>>>> out.
>>>>>
>>>>> Thanks
>>>>>
>>>>> -- Jeanfrancois
>>>>>
>>>>>
>>>>>
>>>>> Ramesh wrote:
>>>>>> Hi JeanFrancois,
>>>>>>
>>>>>> Could you please point me to the code (Sun Instant Messenger)
>>>>>> that uses ARP.
>>>>>>
>>>>>> Pls note: I have not ccied dev_at_grizzly, because i though the Sun
>>>>>> Messenger code is not open source
>>>>>>
>>>>>> Thanks
>>>>>> -Ramesh
>>>>>>
>>>>>> Jeanfrancois Arcand wrote:
>>>>>>> Hi Ramesh,
>>>>>>>
>>>>>>> Ramesh wrote:
>>>>>>>> Hi Alexey,
>>>>>>>>
>>>>>>>> >Currently you can propogate a custom data using Context
>>>>>>>> attributes. Is it enough?
>>>>>>>>
>>>>>>>> Yes, should be enough in 1.6.1... ,
>>>>>>>>
>>>>>>>> > I didn't think about possibility to dynamically switch the
>>>>>>>> protocol during connection lifecycle. But think it's not a
>>>>>>>> problem to add this feature.
>>>>>>>>
>>>>>>>> It depends on which life-cycle do we choose to associate a
>>>>>>>> handler, it could be for the lifetime of a selectionkey or it
>>>>>>>> could be for the lifetime of a request. Thats why i propose to
>>>>>>>> leave this to the handler itself so that the design is
>>>>>>>> flexible. We could add another attribute in the
>>>>>>>> PUProtocolRequest through which we can propagate whether or not
>>>>>>>> to map the handler back to the key, and this can be set/reset
>>>>>>>> by the handler itself.
>>>>>>>>
>>>>>>>> > Do you have any specific usecase?
>>>>>>>> Yes , if we are implementing a http proxy behavior in the
>>>>>>>> handler, where we are going to forward the received bytes to
>>>>>>>> another server, then after we have sent the entire data, we
>>>>>>>> just have to wait for the response from the server, IMO it is
>>>>>>>> inefficient to just wait and block at the handler until the
>>>>>>>> response is received from the server, we could register a
>>>>>>>> callback to handle the response when it arrives, but if we
>>>>>>>> returned from the handler we have to ensure the channel is kept
>>>>>>>> alive so that the response can be sent back on it.
>>>>>>>
>>>>>>> In that case you should explore Grizzlly ARP (Asynchronous
>>>>>>> Request Processing) [1]. This extension was done exactly to
>>>>>>> support that use case. Port unification is not the place to
>>>>>>> implement such feature IMO, as it role is to:
>>>>>>>
>>>>>>> 1. Find the protocol
>>>>>>> 2. Redirect the request to the proper endpoind.
>>>>>>>
>>>>>>> In you case, you should 'leave' the Handler and enter the
>>>>>>> Grizzly ARP mechanism (like Comet is doing. You can taste it by
>>>>>>> playing with the Sun Instant Messenger tool internally. It use
>>>>>>> ARP/Comet to park requests).
>>>>>>>
>>>>>>> That is why it would be good if we can
>>>>>>>> separate out the readkey registering from the keepalive logic
>>>>>>>> so that we can just keep the channel alive without registering
>>>>>>>> a OP_READ. We should be able to register a OP_READ once the
>>>>>>>> response has been written back completely.
>>>>>>>
>>>>>>> Comet[2] is the solution, not Port Unification IMO.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> -- Jeanfrancois
>>>>>>>
>>>>>>> [1]http://weblogs.java.net/blog/jfarcand/archive/2006/02/grizzly_part_ii.html
>>>>>>>
>>>>>>> [2]http://weblogs.java.net/blog/jfarcand/archive/2006/07/the_grizzly_com.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> -Ramesh
>>>>>>>>
>>>>>>>> Oleksiy Stashok wrote:
>>>>>>>>> Hello Ramesh,
>>>>>>>>>
>>>>>>>>> Ramesh Parthasarathy wrote:
>>>>>>>>>> I will try to write a doc on how i have used PU, but it might
>>>>>>>>>> take some
>>>>>>>>>> time , so here are some initial thoughts
>>>>>>>>>>
>>>>>>>>> It could be very useful! Thanks.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 1. Though the Finder and the Handler are meant for specific
>>>>>>>>>> purposes,
>>>>>>>>>> the ProtocoInfo/PUProtocolRequest (or the Context in Grizzly
>>>>>>>>>> 1.6.1)
>>>>>>>>>> object is the only standard means of sharing data between
>>>>>>>>>> them, it would
>>>>>>>>>> be good if we could propagate custom data from the Finder to
>>>>>>>>>> the Handler
>>>>>>>>>> so that we dont have to redo work we might have already done
>>>>>>>>>> in the
>>>>>>>>>> Finder. This custom object could be propagated through the
>>>>>>>>>> ProtocolInfo
>>>>>>>>>> or any other means.
>>>>>>>>>>
>>>>>>>>> Currently you can propogate a custom data using Context
>>>>>>>>> attributes. Is it enough?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 2. The logic in the PUpipeline/PUFilter that determines
>>>>>>>>>> whether the
>>>>>>>>>> Finder has to be invoked. If i understand correctly for a
>>>>>>>>>> selection Key
>>>>>>>>>> oncer the Finder returns with a protocol, we create a map of
>>>>>>>>>> the key and
>>>>>>>>>> the handler and this holds good until the key is
>>>>>>>>>> valid/channel is alive.
>>>>>>>>>> So, any further data that is read on that channel will result
>>>>>>>>>> in the
>>>>>>>>>> invocation of the same handler. For e.g the data could be
>>>>>>>>>> more data for
>>>>>>>>>> the same http request or it could be a new http request on
>>>>>>>>>> the same
>>>>>>>>>> channel (if keep-alive). I guess it would be good if we
>>>>>>>>>> allowed the
>>>>>>>>>> handler to control the association of the key and the
>>>>>>>>>> handler, so that
>>>>>>>>>> the logic of determining whether the finder is invoked on the
>>>>>>>>>> next chunk
>>>>>>>>>> of data can be controlled by user logic.
>>>>>>>>>>
>>>>>>>>> Hmm. I was looking at port unification as mechanism how newly
>>>>>>>>> accepted connection could be classified and in future it will
>>>>>>>>> be processed by certain (single) ProtocolHandler.
>>>>>>>>> I didn't think about possibility to dynamically switch the
>>>>>>>>> protocol during connection lifecycle. But think it's not a
>>>>>>>>> problem to add this feature.
>>>>>>>>>
>>>>>>>>>> 3. The handler basically has to keep the channel alive
>>>>>>>>>> (return true),
>>>>>>>>>> until it is done using the channel. There may be
>>>>>>>>>> circumstances where the
>>>>>>>>>> handler is finished reading the entire data from the channel,
>>>>>>>>>> but it is
>>>>>>>>>> waiting (for some async event) to write more data into the
>>>>>>>>>> channel. In
>>>>>>>>>> such a case the channel has to kept alive (else the cancelkey
>>>>>>>>>> closed the
>>>>>>>>>> channel) . And if the channel is kept alive the key is
>>>>>>>>>> registered for
>>>>>>>>>> OP_READ ? Is there a way we can keep the channel alive and
>>>>>>>>>> indicate
>>>>>>>>>> somehow to the selector thread we are not expecting any data
>>>>>>>>>> to be read
>>>>>>>>>> as of now... Iam not sure if this is possible in 1.6.1
>>>>>>>>>> (sorry, i havent
>>>>>>>>>> gone through the 1.6.1 code in detail) , but it was certainly
>>>>>>>>>> difficult
>>>>>>>>>> in 1.0.
>>>>>>>>>>
>>>>>>>>> You're right, in 1.6.1 PU works the same way. PUFilter should
>>>>>>>>> be usually added after the ReadFilter, and ReadFilter, by
>>>>>>>>> default, reregisters connection for reading when postProcess
>>>>>>>>> is called.
>>>>>>>>> But again if it's required - we can think about possibility to
>>>>>>>>> avoid reregistering on OP_READ.
>>>>>>>>> Do you have any specific usecase?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thank you!!!
>>>>>>>>>
>>>>>>>>> WBR,
>>>>>>>>> Alexey.
>>>>>>>>>> Please correct me if any of my observation is not correct.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> -Ramesh
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Jeanfrancois Arcand wrote On 09/19/07 18:02,:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Kudo to Alexey, the Grizzly's port unification[1] used by
>>>>>>>>>>> GlassFish v2 (Grizzly 1.0) is now available as a sub module
>>>>>>>>>>> in Project Grizzly.
>>>>>>>>>>>
>>>>>>>>>>> Port unification allow any server base application to
>>>>>>>>>>> support more than one protocol using a single tcp/udp/tls
>>>>>>>>>>> port. As as example, GlassFish v2 by default listen on port
>>>>>>>>>>> 8080 for http, https and Soap over tcp requests.
>>>>>>>>>>>
>>>>>>>>>>> Any volunteer to writes docs or tutorial? :-) :-)
>>>>>>>>>>>
>>>>>>>>>>> Port Unification is currently available with version
>>>>>>>>>>> 1.6-SNAPSHOT and soon with 1.6.1.
>>>>>>>>>>>
>>>>>>>>>>> -- Jeanfrancois
>>>>>>>>>>>
>>>>>>>>>>> http://weblogs.java.net/blog/jfarcand/archive/2006/11/one_port_to_rul.html
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>>>>>>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>>>>>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>>>>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>>>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>>>>
>>>