Asynchronous timeout/sleep/delay/etc.

[yz <ya...@mailnull.com>]

I just started playing around with Mina, and I tried searching the archives
for a discussion about this, but I noticed a glaring lack of any
asynchronous scheduling of callbacks. I.e., we can't schedule a
timeout/sleep/delay within this framework. Is this accurate? Is there some
reason why this relatively straightforward and standard feature is not
available in this framework?

As a workaround, it seems that we must resort to synchronous, blocking
timeout mechanisms (e.g. ScheduledExecutorService). Is the general approach
here to simply save the IoSession (while inside one of the IoHandler
callbacks) and use it (a) from other threads (b) at any time in the future?
If this is the case, meaning the IoSession never changes across the
IoHandler callbacks, then why is IoSession continually passed back into
those callbacks?

IoSession says it's thread-safe (I assume this implies the thread-safety of
the reactor core as well) but the Filters may not be. How do I tell if a
particular filter is thread-safe? In particular, I'm interested in
LoggingFilter and ProtocolCodecFilter with ObjectSerializationCodec, but for
these there's no mention in the docs regarding their thread-safety.

Thanks in advance for your answers.
-- 
View this message in context: http://www.nabble.com/Asynchronous-timeout-sleep-delay-etc.-tf4519900s16868.html#a12893472
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.

Re: Asynchronous timeout/sleep/delay/etc.

[Jeff Genender <jg...@apache.org>]

yz wrote:
> It requires another thread.

It requires a thread that is dedicated to managing scheduling as a
daemon, but it certainly is not blocking anything else.  I believe this
is probably one of the components that is best suited for scheduling a
timeout as it scales incredibly well.  I have written some that handle
1000s of concurrent connections and have no issues at all.

When you send a message, you would create a Future task via the
SchedulerExecutorService in your messageSent(), with an ioSession as a
member of the Future task.  This requires nearly no overhead and has
absolutely no blocking associated with it.  If you receive a response
w/in the allotted time, you cancel the timeout.  If not, your task
fires, and you can close the connection or do other actions.  If you
expect many many connections, you can use a thread pool to handle the
firing of the tasks.

If using a scheduler is not working for you, then you could make use of
the session idler, but then you still are using an internal thread that
is monitoring the idling time (which happens anyways), as a daemon.  You
are not going to get around something that polls something else, its the
nature of the IO beast in just about any programming language.

In any case, I do not see any reason why a ScheduledExecutorService is a
bad thing.

Jeff

> 
> 
> jgenender wrote:
>> How is the ScheduledExecutorService a blocking mechanism?
>>
>> Jeff
>>
>> yz wrote:
>>> I just started playing around with Mina, and I tried searching the
>>> archives
>>> for a discussion about this, but I noticed a glaring lack of any
>>> asynchronous scheduling of callbacks. I.e., we can't schedule a
>>> timeout/sleep/delay within this framework. Is this accurate? Is there
>>> some
>>> reason why this relatively straightforward and standard feature is not
>>> available in this framework?
>>>
>>> As a workaround, it seems that we must resort to synchronous, blocking
>>> timeout mechanisms (e.g. ScheduledExecutorService). Is the general
>>> approach
>>> here to simply save the IoSession (while inside one of the IoHandler
>>> callbacks) and use it (a) from other threads (b) at any time in the
>>> future?
>>> If this is the case, meaning the IoSession never changes across the
>>> IoHandler callbacks, then why is IoSession continually passed back into
>>> those callbacks?
>>>
>>> IoSession says it's thread-safe (I assume this implies the thread-safety
>>> of
>>> the reactor core as well) but the Filters may not be. How do I tell if a
>>> particular filter is thread-safe? In particular, I'm interested in
>>> LoggingFilter and ProtocolCodecFilter with ObjectSerializationCodec, but
>>> for
>>> these there's no mention in the docs regarding their thread-safety.
>>>
>>> Thanks in advance for your answers.
>>
> 

Re: Asynchronous timeout/sleep/delay/etc.

[yz <ya...@mailnull.com>]

It requires another thread.


jgenender wrote:
> 
> How is the ScheduledExecutorService a blocking mechanism?
> 
> Jeff
> 
> yz wrote:
>> I just started playing around with Mina, and I tried searching the
>> archives
>> for a discussion about this, but I noticed a glaring lack of any
>> asynchronous scheduling of callbacks. I.e., we can't schedule a
>> timeout/sleep/delay within this framework. Is this accurate? Is there
>> some
>> reason why this relatively straightforward and standard feature is not
>> available in this framework?
>> 
>> As a workaround, it seems that we must resort to synchronous, blocking
>> timeout mechanisms (e.g. ScheduledExecutorService). Is the general
>> approach
>> here to simply save the IoSession (while inside one of the IoHandler
>> callbacks) and use it (a) from other threads (b) at any time in the
>> future?
>> If this is the case, meaning the IoSession never changes across the
>> IoHandler callbacks, then why is IoSession continually passed back into
>> those callbacks?
>> 
>> IoSession says it's thread-safe (I assume this implies the thread-safety
>> of
>> the reactor core as well) but the Filters may not be. How do I tell if a
>> particular filter is thread-safe? In particular, I'm interested in
>> LoggingFilter and ProtocolCodecFilter with ObjectSerializationCodec, but
>> for
>> these there's no mention in the docs regarding their thread-safety.
>> 
>> Thanks in advance for your answers.
> 
> 

-- 
View this message in context: http://www.nabble.com/Asynchronous-timeout-sleep-delay-etc.-tf4519900s16868.html#a12893885
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.

Re: Asynchronous timeout/sleep/delay/etc.

[Jeff Genender <jg...@apache.org>]

How is the ScheduledExecutorService a blocking mechanism?

Jeff

yz wrote:
> I just started playing around with Mina, and I tried searching the archives
> for a discussion about this, but I noticed a glaring lack of any
> asynchronous scheduling of callbacks. I.e., we can't schedule a
> timeout/sleep/delay within this framework. Is this accurate? Is there some
> reason why this relatively straightforward and standard feature is not
> available in this framework?
> 
> As a workaround, it seems that we must resort to synchronous, blocking
> timeout mechanisms (e.g. ScheduledExecutorService). Is the general approach
> here to simply save the IoSession (while inside one of the IoHandler
> callbacks) and use it (a) from other threads (b) at any time in the future?
> If this is the case, meaning the IoSession never changes across the
> IoHandler callbacks, then why is IoSession continually passed back into
> those callbacks?
> 
> IoSession says it's thread-safe (I assume this implies the thread-safety of
> the reactor core as well) but the Filters may not be. How do I tell if a
> particular filter is thread-safe? In particular, I'm interested in
> LoggingFilter and ProtocolCodecFilter with ObjectSerializationCodec, but for
> these there's no mention in the docs regarding their thread-safety.
> 
> Thanks in advance for your answers.