Thanks Harsha to go public :-)
Harsha Godugu wrote:
>>> Thanks a lot Ken. Actually, if I take off the scenario that I need to
>>> write during parsing bytes,
>>> my code /work becomes much simpler. I do not need to pass the
>>> connection/channel arg
>>> to the parser methods as it is now in the MessageBase.java. Thanks
>>> Charlie for your idea to on
>>> the separation of parsing to processing. But, even then, how do I let
>>> the ORB worker know that,
>>> its time to write to the channel. I understand that, any channel is
>>> always ready to write, unless
>>> otherwise we set the Op bit of the selector to just OP_READ alone.
>>>
>>>
>
>> You will need to have a protocol-level representation of the channel (our
>> current SocketOrChannelConnectionImpl) to handle this. Basically what
>> you need is
>> writeLock. The problem is that any thread may at any time decide to
>> write to any connection (at least as far as the transport is concerned),
>> so the transport cannot help us to avoid problems. Every time an ORB
>> worker thread wants to write, it needs to:
>>
>> 1. Acquire the write lock
>> 2. write to the connection (which delegates to the Grizzly write
>> method, which handles temp. selectors, SSL, etc. as needed)
>> 3. release the write lock
>>
>> That way we don't have two different threads simultaneously writing to
>> the same connection.
>
>
> The problem right now is, access to the channel on the client side and
> the server side, and making it to
> go through the selector. That means, upon parsing of bytes, if there is
> a need to write to the channel,
> let us assume that, we delegate writing to the ORB worker thread. Now,
> carefully analyse how we implement
> with Grizzly's present code. In order to do this writing, first the
> worker thread needs to get informed by the
> TCPSelectorHandler that, the underlying channel (that the worker thread
> somehow got access to?)
> is READY to write. How do we do this?
>
>
>>> Note that the connections cache get/release mechanism is NOT
>>> sufficient. The outbound
>>> connection cache will try to give different get requests for the same
>>> endpoint different connections,
>>> but it can't always do that. When two get calls that have not yet
>>> been released both get the
>>> same connection, write lock is essential to avoid problems like write
>>> calls that are interleaved
>>> within the same GIOP message.
>>>
>>> The inbound connection cache is basically the same: we could have
>>> multiple worker
>>> threads all competing to write a response to the same accepted
>>> connection in the inbound
>>> cache. That's why we have essentially the same mechanism on both
>>> sides today.
>>>
>>
>>
>>>>> On the other hand, I'm using the same tcpSelectorHandler both on client
>>>>> and server side by overriding the
>>>>> grizzly's TcpSelectorHandler at many places. I want to know all your
>>>>> thoughts on this too.
>>>>> Basically, I wanted to use only one type of connector on both client
>>>>> and serverside.
>>>>>
>>>
>>>
>>> I'm always in favor of using only one of something whenever possible.
>>> But I'm not sure
>>> of all of the Grizzly details here. It seems like the server pipeline
>>> can fairly easily be
>>> plugged into the TCPConnectorHandlers, as Jean-Francois pointed out
>>> earlier.
>>> Is that not enough? Are there other issues here?
>>
>>
>
> The issue is about access to the underlying channel. On serverside it's
> different it's just a nio channel.
> On client side it's TcpConnector.
>
> Take the following scenario:
>
> On serverside:
> upon accept, Grizzly does gets the socketchannel from the
> TcpSelectorHandler. ( whose selector
> is registered with OP_ACCEPT events for the serversocket /acceptor. Upon
> accept, what it gets is an NIO socket
> channel. This SHOULD be changed to TcpConnector in Grizzly.
>
> On client side:
> onConnect() we get socketchannel and set it inside
> tcpConnector.
>
> I hope this helps with clarity.
Hum....I still don't understand what you means here. You can derive the
SocketChannel from a SelectionKey by doing key.channel(). So inside your
callbackHandler you can always get the Channel and store it.
Can you elaborate more?
Thanks
-- Jeanfrancois
>
> thanks..
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>