I think we can avoid making changes to Grizzly 1.0.
As for DefaultReadTask:
You can set your own ReadTask implementation using System property [1].
This solution requires from you to overwrite default parsing algorithm.
And will look like this:
//=======================================================================
public class MyParsingAlgorithm extends NoParsingAlgorithm {
/**
* Return the full name of the class responsible for handling OP_READ.
*/
@Override
public Class getReadTask(SelectorThread selectorThread){
if ( selectorThread.getMaxReadWorkerThreads() <= 0
&& !selectorThread.getEnableAsyncExecution())
return SailFinCustomReadTask.class;
else
return
com.sun.enterprise.web.connector.grizzly.AsyncReadTask.class;
}
}
//=================================================================
As for ProtocolInfo... If you're making your own implementation of
PortUnificationPipeline - nothing could stop you from extending current
ProtocolInfo implementation and adding several required fields.
This way you will not need any change to the current Grizzly 1.0
implementation.
Hope this helps.
WBR,
Alexey.
[1] com.sun.enterprise.web.connector.grizzly.algorithmClassName
Ramesh Parthasarathy wrote:
> Yes, i could use the system property to configure my pipeline
> implementation, that takes care of changes to the pipeline,
> My changes also affected DefaultReadTask and the ProtocolInfo classes,
> would it be ok to make those changes.
>
> Thanks
> -Ramesh
>
>
> Oleksiy Stashok wrote On 10/03/07 10:06,:
>
>> Brrr....
>> Ramesh, looks like there is a way how you can set custom port
>> unification Pipeline, using System property [1].
>> In this case we can rollback to the variant you proposed, but instead of
>> patching existing code - just write your own PortUnficationPipeline
>> implementation.
>>
>> Think it's the best way, as doesn't require any changes to Grizzly 1.0
>> and max. reuses your existing code.
>>
>> WBR,
>> Alexey.
>>
>> [1] com.sun.enterprise.web.connector.grizzly.pipelineClass
>>
>> Jeanfrancois Arcand wrote:
>>
>>
>>> Hi Binod,
>>>
>>> Binod wrote:
>>>
>>>
>>>> Jeanfrancois Arcand wrote:
>>>>
>>>>
>>>>> Hi Alexey,
>>>>>
>>>>> Oleksiy Stashok wrote:
>>>>>
>>>>>
>>>>>> Hello guys,
>>>>>>
>>>>>> Ramesh, think it makes sense to extend current
>>>>>> PortUnificationPipeline by some SailfinPortUnificationPipeline and
>>>>>> add functionality you need there.
>>>>>> Next question is "how to plug custom port unification pipeline".
>>>>>>
>>>>> >From code I see now, it's not possible in Grizzly 1.0, but making
>>>>>
>>>>>> small change to GrizzlyHttpProtocol class makes this possible.
>>>>>>
>>>>>> Jeanfrancois, I know you're pretty conservative in making changes
>>>>>> to Grizzly 1.0 codebase, but think making port unification pipeline
>>>>>> pluggable is quite safe change, which will make Grizzly more
>>>>>> extendable.
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>> -1.
>>>>>
>>>>> Any changes to 1.0 is not allowed because it can break too many
>>>>> existing product (only bug fixes). The Sailfin team *cannot* make
>>>>> any changes to the 1.0 code base (this is an internal politic as well).
>>>>>
>>>> If the changes are in a backward compatible way, will that be
>>>> acceptable?
>>>>
>>> Sorry, no.
>>>
>>> Grizzly 1.0 is easily extendable and you should stick with the
>>> existing interfaces....or move to 1.6 ;-)
>>>
>>> Thanks
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>
>>>> thanks,
>>>> Binod.
>>>>
>>>>
>>>>> Thanks
>>>>>
>>>>> -- Jeanfrancois
>>>>>
>>>>>
>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> WBR,
>>>>>> Alexey.
>>>>>>
>>>>>> Ramesh Parthasarathy wrote:
>>>>>>
>>>>>>
>>>>>>> Hi JeanFrancois,
>>>>>>> I tried to extend the PU mechanism in Grizzly 1.0 ([1]) and
>>>>>>> implement a
>>>>>>> way by which we can park the request (release the resources and
>>>>>>> keep the
>>>>>>> channel alive). Could you please review the changes, i have
>>>>>>> attached them.
>>>>>>> Briefly, i have just propagated the selectorthread through the
>>>>>>> protocolinfo object so that the callback handler can take the
>>>>>>> decision
>>>>>>> of canceling/registering the key back on the selector thread once the
>>>>>>> response is complete. Also i have refactored the DefaultReadTask
>>>>>>> so that
>>>>>>> the resources can be released appropriately.
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>> -Ramesh
>>>>>>>
>>>>>>>
>>>>>>> Jeanfrancois Arcand wrote On 09/25/07 17:45,:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi Ramesh,
>>>>>>>>
>>>>>>>> thanks for not having private discussions :-)
>>>>>>>>
>>>>>>>> Ramesh wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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).
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ARP can be combined with PU. To enable ARP, you just call
>>>>>>>> SelectorThread.setAsyncExecution(true). Now a possible solution
>>>>>>>> for you would consist of writing your own AsyncHandler to decide
>>>>>>>> if the request needs to be parked or not. To recap, if you need
>>>>>>>> to park requests, you have four solutions:
>>>>>>>>
>>>>>>>> [1] Extends Port Unification mechanism (like you already did) and
>>>>>>>> write your own way of parking the request.
>>>>>>>> [2] Extends Port Unification, programmatically configure ARP (You
>>>>>>>> can take a look at how openESB is doing it) to park only the
>>>>>>>> requests you are interested
>>>>>>>> [3] Extends ARP's AsyncHandler (you can replace the default
>>>>>>>> programmatically using the SelectorThread API)
>>>>>>>> [4] Write your own Pipeline Grizzly 1.0 (similar to the Port
>>>>>>>> Unification Pipeline). Inside that Pipeline, first detect if the
>>>>>>>> request has to be serviced locally or remotely. If locally, just
>>>>>>>> call super.addTask(). If remotely, get an AsyncReadTask and
>>>>>>>> execute it assuming you have written your AsyncHandler).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Yes, you can configure the AsyncHandler, AsyncExecutor and
>>>>>>>> AsyncFilter from the SelectorThread.
>>>>>>>>
>>>>>>>> Hope that help.
>>>>>>>>
>>>>>>>> -- Jeanfrancois
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> -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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> 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
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>
>