>> 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
>