Re: support for asyncrhonous messaging on a per-connection basis

2007-12-27 Thread Trustin Lee
Hi Scott,

On Dec 26, 2007 3:48 AM,  [EMAIL PROTECTED] wrote:
 If a single client session sends multiple requests before a response for the 
 first request is sent by the server, it appears that client requests are 
 processed sequentially/serially.  It appears that the processing of the 
 second request does commence until the first response is returned (i.e., 
 until messageReceived() returns).  I was wondering if there's a 
 mina-specific way to do the processing of multiple requests from a single 
 session in parallel.

If you are using 2.0.0-M1-SNAPSHOT, then you can use
UnorderedThreadPoolExecutor to achieve what you want.  If you are
using 1.x, then you will have to modify ExecutorFilter.java.  It
shouldn't be that difficult. :)

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6


Re: support for asyncrhonous messaging on a per-connection basis

2007-12-23 Thread Trustin Lee
Hi Scott,

On Dec 22, 2007 8:05 AM, scottmiller [EMAIL PROTECTED] wrote:

 I saw this in another posting:

 And, if your client sends messages asynchronously (i.e. sends requests
 before all previous responses are received.), any incoming messages
 will be buffered in the internal queue until your messageReceived()
 method returns.  The queue is maintained on a per-session basis, so
 any other sessions won't be affected when one session's
 messageReceived() runs long.

 Are there plans in an upcoming MINA release to support asynchronous
 messaging on a per-connection basis?  Any known workarounds?

A session is a connection in MINA TCP transport.  So... I think what
you want is already there.

HTH,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6


Re: support for asyncrhonous messaging on a per-connection basis

2007-12-22 Thread Qi

Hi there,

I believe that every time a connection is built, there's a session being
created with it. So per-connection based protocol is really just a special
case of per-session protocol.
If you don't expect the server to send you any response, you may do
something like
code
WriteFuture wf = session.write(Message msg);
wf.join();
CloseFuture cf = session.close();
cf.join();
/code
to close the session and connection after you finish sending you message.
Alternatively, 
You can add a IoFutureListener, which will be notified once a IoFuture's
status is changed, to close the session.

If you do expect the server to send some response message, you can do the
same thing in the IoHandler you give to your IoConnector. In which case, you
would have to use IoFutureListener in order to avoid deadlock.

Cheers,
Qi


scottmiller wrote:
 
 I saw this in another posting:
 
 And, if your client sends messages asynchronously (i.e. sends requests
 before all previous responses are received.), any incoming messages
 will be buffered in the internal queue until your messageReceived()
 method returns.  The queue is maintained on a per-session basis, so
 any other sessions won't be affected when one session's
 messageReceived() runs long.
 
 Are there plans in an upcoming MINA release to support asynchronous
 messaging on a per-connection basis?  Any known workarounds?
 
 

-- 
View this message in context: 
http://www.nabble.com/support-for-asyncrhonous-messaging-on-a-per-connection-basis-tp14463996s16868p14475983.html
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.



support for asyncrhonous messaging on a per-connection basis

2007-12-21 Thread scottmiller

I saw this in another posting:

And, if your client sends messages asynchronously (i.e. sends requests
before all previous responses are received.), any incoming messages
will be buffered in the internal queue until your messageReceived()
method returns.  The queue is maintained on a per-session basis, so
any other sessions won't be affected when one session's
messageReceived() runs long.

Are there plans in an upcoming MINA release to support asynchronous
messaging on a per-connection basis?  Any known workarounds?

-- 
View this message in context: 
http://www.nabble.com/support-for-asyncrhonous-messaging-on-a-per-connection-basis-tp14463996s16868p14463996.html
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.