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
>