Hi John,
I tried the Context.getAttributeHolderByScope(), a ConnectorHandler was put
into the AttributeHolder. There is one problem, that is the ConnectorHandler
retrieved from the AttributeHolder will be null. Maybe the root cause of
this is the ProtocolChain execution is not correctly controlled. Because in
my case I only want it to be executed one time but 3 or 4 times instead :-(.
Would you pls. check this in the attached? Thanks a lot!
Regards,
-Yi Bing
2008/6/16 JianXing Yi <jianxing.yi_at_gmail.com>:
> Hi John,
>
> Many thanks. I'll try this.
>
> Regards,
> -Yi Bing
>
> 2008/6/13 John ROM <snake-john_at_gmx.de>:
>
> Hi JianXing Yi,
>> I can only answer question 3 :
>>
>> in regards to sate, in my opinion grizzly framework doesn't change the
>> semantics of the original java nio selector . Which is great because you
>> programm to a known model.
>>
>> So statewise your state is in the selectionKey which is given to you by
>> the grizzly Context Object in a Filter.
>>
>> So when you do for example server-client writes you just write with the
>> help of the selectionKey. As long as your selectionKey does not get canceled
>> you have a open connection to your client. If you need to keep state then
>> you could attach your state to the selectionKey.
>>
>> You can look at "How-to attach an ID to a Connection?"
>>
>> https://grizzly.dev.java.net/servlets/ReadMsg?listName=users&msgNo=936
>>
>> to see an example on how to attach something to a connection.
>>
>>
>> But for your 5 times request-response interaction example you do not need
>> to attach anything to the selectionKey.
>>
>> You could use a Protocol session ID to keep track of state on the server.
>>
>> On the first connection of a client to the server I would just create a
>> session ID which the server sends back to the client.
>> and the client then always uses in its subsequent requests.
>>
>> You can create a ProtocolParserFilter to parse this session Id out of the
>> request.
>>
>> Does this answer question 3?
>>
>> Many Greetings
>> John
>>
>>
>>
>> > Betreff: Re: How to implement the client's message flow based on async
>> > read/write?
>> >
>> >
>> >
>> > Hello John,
>> > Great thanks for your help! European soccer champinship also attract
>> > lot of us :-) Enjoy! It's really a good news for your samples, the
>> > sooner the better :-) In my case, I invoke the ProtocolFilter in
>> > CallbackHandler.onConnect() to send the request to the server and it
>> > works, or in another word, the
>> > CallbackHandler.onConnect() kicks off the protocol interaction.
>> > Because I really want the ProtocolFilter to manage its own
>> > state/operation itselft without interaction with the CallbackHandler.
>> > But there are still problems, those are about 1. Context operation
>> > type switching or SelectionKey interests switching Could you pls. give
>> > a brief explanation of these switching, maybe something about
>> > Context.setCurrentOpType(), KeyRegistrationState, or anything else?
>> > 2. Asynchronously reading/writing in ProtocolFilters In my case, I use
>> > an asynchronous reading operaiton to receive the server's simple
>> > response. Unfortunately, this leads to about 50% cpu polling :-(.
>> > 3. State management in ProtocolFilter
>> > In my case, I try to test a stateful protocol interaction by extending
>> > the interaction process to this: the request-response interaction will
>> > be repeated 5 times and then the client initiates to close the
>> > connection. Could you pls. give a brief explanation about how to
>> > implement state management in ProtocolFilter?
>> >
>> > 2008/6/12 John ROM <snake-john_at_gmx.de>:
>> >
>> > ProtocolParser,Filter are mainly for reading.
>> > Of course you can always call your TCPConnectorHandler from a filter.
>> >
>> > you could look at
>> >
>> > "Obtaining the selectorHandler for a given ConnectorHandler"
>> >
>> > https://grizzly.dev.java.net/servlets/ReadMsg?listName=users&msgNo=678
>> >
>> > for advice on setting up a chain in a client for reading.
>> >
>> > many Greetings.
>> > p.s:
>> > I am working on a complete example for client/server communication
>> > with a client protocolParser and will try to publish it under the
>> > samples directory.
>> > I should have it done at the end of the month after the european
>> > soccer championship...
>>
>> --
>> GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
>> Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>>
>