Hi Ming Qin,
can you pls. attach a complete diff file and zipped bundle with
updates source files. So it will be easier for people to review it.
Thank you.
WBR,
Alexey.
On Jan 11, 2010, at 19:51 , ming qin wrote:
> 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
>>
>