Hi,
we add an internal (unfortunately) discussion about how to invoke the
ProtocolChain (and its associated ProtocolFilter) from a
ConnectorHandler. Below is a snippet of the discussion and how we did
implement it within the Sailfin project.
As usual, we need to work on a tutorial so new user can do it easily.
Thanks
-- Jeanfrancois
Jeanfrancois Arcand wrote:
> Hi,
>
> here is an example of how to invoke a ProtocolChain from a
> ConnectorHandler. This code snipped is used as part of the Sailfin
> project (and TLS):
>
>> 333 private TCPConnectorHandler
>> createHandlerTCP(TargetTuple tt) throws IOException {
>> 334 InetSocketAddress remote = tt.getSocketAddress();
>> 335 final TCPConnectorHandler connectorHandler =
>> (TCPConnectorHandler) controller.acquireConnectorHandler(Protocol.TCP);
>> 336
>> 337 CallbackHandler<Context> callbackHandler = new
>> CallbackHandler<Context>(){
>> 338 public void onConnect(IOEvent<Context> ioEvent) {
>> 339 //try{
>> 340 SelectionKey key =
>> ioEvent.attachment().getSelectionKey();
>> 341 connectorHandler.finishConnect(key);
>> 342 controller.registerKey(key,
>> SelectionKey.OP_READ, Controller.Protocol.TCP);
>> 343 }
>> 344 public void onRead(IOEvent<Context> ioEvent) {
>> 345 try {
>> 346 Context ctx = ioEvent.attachment();
>> 347 SelectionKey key = ctx.getSelectionKey();
>> 348 // disable OP_READ on key before doing
>> anything else
>> 349 key.interestOps(key.interestOps() &
>> (~SelectionKey.OP_READ)); 350
>> ctx.getProtocolChain().execute(ioEvent.attachment());
>> 351 } catch (Throwable e) {
>> 352 // TODO Auto-generated catch block
>> 353 e.printStackTrace();
>> 354 }
>> 355 //throw new IllegalStateException("Should
>> not end up here!");
>> 356 }
>
>
> The line to invoke to invoke the ProtocolChain is:
>
> ctx.getProtocolChain().execute(ioEvent.attachment());
>
> You might already figured it :-)
>
> -- Jeanfrancois
>
>
> Harsha Godugu wrote:
>> Ken Cavanaugh wrote On 08/06/07 16:51,:
>>
>>> Harsha Godugu wrote:
>>>
>>>> Ken Cavanaugh wrote On 08/06/07 14:26,:
>>>>
>>>>
>>>>
>>>>> Harsha Godugu wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Folks,
>>>>>>
>>>>>> I've a scenario in CORBA where I need to use Grizzly's Protocol
>>>>>> parser
>>>>>> filter on the client side too. It appears to me, the concept of
>>>>>> filters
>>>>>> in grizzly JUST applies to server-side listeners and connections.
>>>>>> Can we
>>>>>> use Grizzly controller
>>>>>> and filters on the Client side? If so, an example might be of
>>>>>> great help.
>>>>>>
>>>>>> --Harsha
>>>>>>
>>>>>>
>>>>>>
>>>>> Could you explain the scenario?
>>>>>
>>>> Sure Ken. I thought you must be aware of this scenario.
>>>> I've a protocol parser. The way Grizzly gives the control (program
>>>> execution) for parsing bytes is, to add a protocol parser filter.
>>>> Now,
>>>> I want to use the protocol parser filter that I wrote for Corba to use
>>>> on both client
>>>> and serversides. The scenario is, when client sends a request, we read
>>>> the response using the said protocol filter
>>>> and then send a response. Now, we need to read the response using the
>>>> same protocol parser. I thought I would use the same parser (using
>>>> Grizzly) that I used on the serverside. You might be confused, and
>>>> thinking, what this guy is talking...?
>>>> In Grizzly, the relation of filters to a connector on the client side
>>>> is obscure. For example, if you take a look at
>>>> the testcases (which I consider examples) most of the clientside
>>>> code is
>>>> blocked reading, which I do not want to
>>>> use. The other way, I thought was, to use a callback handler on the
>>>> client side and then use the parser some how. That takes 2 approaches
>>>> when ORB acts as client and server. When it's server, it goes
>>>> through
>>>> the
>>>> PorotocolParser Filter and the other case of client, it uses
>>>> connection
>>>> callback handler.
>>>>
>>>>
>>> Actually, it may be that the connection is non-existent. I think
>>> I see the problem: it may be a problem with the current Grizzly
>>> connector implementation. Basically, the ORB MUST be able
>>> to create a Connector where the read and write events are
>>> handled by the Selector which is created in the TCPSelectorHandler.
>>> (OK, it partially does that, but not the way we need it).
>>> For CORBA, there is essentially no difference between a client and
>>> a server.
>>>
>>> It looks to me like the assumption of a client thread that does
>>> a blocking read waiting for a reply may be baked into
>>> TCPConnectorHandler. For example, TCPConnectorHandler.read
>>> ONLY uses the selector when a read returns 0 bytes.
>>> CORBA MUST have the selector listen AT ALL TIMES on
>>> a Connector, because asynchronous responses may occur at any
>>> time, even concurrently with writing to the connection.
>>>
>>> It looks like we really need to discuss this at the Grizzly meeting,
>>> as it appears that the current TCPConnectorHandler is unusable
>>> for CORBA. We must have the TCPConnectorHandler using the
>>> full ProtocolChain that is used in the acceptor side.
>>
>> Thank you so much Ken for quickly understanding what I was mentioning.
>> That gives me a bit relief.
>>
>> To add further: Grizzly uses filters when there is/are no callback
>> handler (onRead/onWrite/onConnect)
>> added to the underlying connector. The call sequence is, if there an
>> i/o event, it would go to either
>> onRead/onWrite/onConnect methods *OR* to procotol chain.
>> Yes, the TCPConnectorHandler and SelectorHandler needs an up.
>> The Grizzly code should be able to provide an api to do the following:
>>
>> ConnectorHandler connector =
>> TCPConnectorHandler.connect(host, port);
>> mySelectorHandler.register(connector, interestOps);
>> controller.setSelectorHandler(myselectorHandler);
>> //the code for adding filters to the controller
>> .. ... .... //
>> //start my controller in a new thread ?
>> ControllerUtils.startController(controller);
>> what's is expected is, client- upon response from server,
>> starts to
>> READ, in which case, we expect it to start processing the filters in the
>> same fashion as Grizzly does on the server side.
>>
>> thanks,
>> Harsha
>>
>>>>
>>>>
>>>>> The concept should apply to reading
>>>>> any received message. Once we receive and read the message, the
>>>>> CorbaMessageMediator either send the response to the
>>>>> CorbaWaitingRoom to
>>>>> wake up the thread that unmarshals the reply, or sends a request to
>>>>> the CorbaServerRequestDispatcher on another thread. The important
>>>>> thing
>>>>> is reading the message (which is in the Grizzly transport), not
>>>>> handling it
>>>>> (which is protocol and higher level, and is handled in the ORB).
>>>>>
>>>>>
>>>> The problem is around reading the response using Grizzly.
>>>>
>>>>
>>> Yes, I see now what the problem is. A good discussion for
>>> Wednesday.
>>>
>>> Thanks,
>>>
>>> Ken.
>>>
>>>
>>