Hi Oleksiy Stashok:
Yes. Do you like to bundle all affected files into a zip and upload as an attachment?
Ming Qin
Cell Phone 858-353-2839
--- On Mon, 1/11/10, Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM> wrote:
From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Subject: Re: how to implement closing socket object related to SocketChannel after a period of time is expired
To: dev_at_grizzly.dev.java.net
Date: Monday, January 11, 2010, 7:41 AM
Hi Ming Qin,
can I ask you to attach the patch, so everyone can take a look and review it?
Thank you very much!
WBR,Alexey.
On Jan 11, 2010, at 0:24 , ming qin wrote:
Hi Oleksiy Stashok:
Following your suggestion, I did an initial implementation of connection read operation idleness on TCPNIOTransportation level with a simple thread of scheduling task ( checking connection read operation idleness everything 1 second ) . It worked, but I don't like my current implementation -one thread handling multiple connections' idleness.
So I am moving to implementation this feature on AbstractTransport level and hoping to have a pool of threads to check out idleness on multiple connections.
In AbstractTransport, workerThreadPool nad internalThreadPool illustrate an approach to have a thread pool to take care multiple tasks. I am kind of moving toward that direction.....
Ming Qin
Cell Phone 858-353-2839
--- On Tue, 1/5/10, Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM> wrote:
From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Subject: Re: how to implement closing socket object related to SocketChannel after a period of time is expired
To: dev_at_grizzly.dev.java.net
Date: Tuesday, January 5, 2010, 8:22 AM
>> in 2.0 we don't have expiration mechanism embedded. There is a sample how expiration could be supported by adding additional Filter (com.sun.grizzly.utils.IdleTimeoutFilter) in case, if we use a FilterChain.
>> For standalone case there is nothing you can use just now.
>>
>> IMO, in order to support expiration feature fully, we need to create lastIOTimestamp field on a Connection (AbstractConnection), then intercept Connection's read/write operations and update lastIOTimestamp each time. And corresponding Transport implementation should check all its Connections to detect expired ones. This implementation will be more complex than in Grizzly 1.9.x, but in 1.9.x we updated expiration timestamp only on "read" operation, so channel will expire, even if it was actively used for writing.
>
>
> I tired to implement this feature on ProcessorRunnable class since it has access to Connection , IOEvent and Attributes.
> Grizzly 2.0 Connection has utilized attribute to store paired entities (name , value). Connection can have a set of attributes (AcceptedTimeStamp, LastReadTimeStamp, LastWriteStamp etc).
We can implement general monitoring for Connection. Connection may have associated probe (which may be empty by default) and emit events on that probe like (bytesRead(...), bytesWrite(), connect())... Transport might register it's probe on each connection and intercept Connection events. This way Transport will be able to track lastRead, lastWrite etc.
> One thing I haven’t figured out is the polling mechanics which should periodically check Connection’s attributes then emit outgoing events so individual connection can receive those outgoing events to process next action( closing connection, writing message to remote peer, keeping connected and ignored etc).
IMO it could be implemented on Transport level (AbstractTransport)
>> IOEvent.IDLE is also a good idea! When Transport detects expired channel it could send IOEvent.IDLE event, and Processor might decide if it wants to close connection or do something else.
>>
>> I would agree on t this.
> From the view of SEDA-http://www.eecs.harvard.edu/~mdw/proj/seda/ for Grizzly 2.0 implementation, my interpretations on Connection represents a stage which is managed by a controller such as Grizzly 2.0’s Transport. IOEvent stands for events for Connection stages. By having IOEvent.IDLE, Grizzly 2.0 will be much more easily subject to customized-protocol control, which eventually leads fast adoption of the framework .
>
Agree.
WBR,
Alexey.
>
>
>>
>> charlie ...
>>
>> ming qin wrote:
>>>
>>> Hi:
>>> For Grizzly 2.0, how to implement closing socket object related to SocketChannel after a period of time is expired , but one endpoint of socket doesn’t receive any data from the other endpoint of socket?
>>>
>>>
>>> Here is a scenario:
>>>
>>> Server: service Ready
>>> Client: greeting service
>>> Server: confirming service back
>>> Client: ( no data being send over ……) waiting……
>>> Server: (After 5 seconds, server closes the socket, since waiting time period is expired) closing socket ……
>>>
>>>
>>> Mina has this implementation on this scenario, I was wondering how to implement same feature on Grizzly 2.0. It seems to me that Processor is the right place to start …….
>>>
>>>
>>> Ming Qin
>>> Cell Phone 858-353-2839
>>
>> --------------------------------------------------------------------- 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