Hi Oleksiy Stashok
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) .
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).
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 .
Thanks.
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 ReadyClient: greeting serviceServer: confirming service backClient: ( 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