blocking/polling events?

[Barry Kaplan <gr...@memelet.com>]

Quickfix sessions support blocking and polling of message handling. The 
current implementation does this by receiving the messages (in mina 
terms by ProtocolHandler.messageReceived) and storing them in a qeueu. 
It then provides other method (block, poll) that process these messages 
from the queue to implement the desired synchronous behavior.

I would like to do away this extra level of queueing (for more reasons 
than I can list here). I could simply add a latch in the 
ProtocolHandler.messageReceived, but I'm not clear what that would mean 
to mina. Would mina get pissed that that its protocol thread(s) appear 
to be hung?

I don't fully grok the mina code yet, but I see that, for example, 
IoAdapter maintains its own message queue. So I suspect I should not be 
worried about tcp getting backed up, no?

Any suggestions would be much appreciated!

-- 
barry kaplan
groups1@memelet.com

Re: blocking/polling events?

[Trustin Lee <tr...@gmail.com>]

2005/6/16, Barry Kaplan <gr...@memelet.com>: 
> 
> > MINA will work fine even if thread takes long time to process events.
> > But There is a possibility that one thread handle more than two
> > connection, and then other connection can starve because other
> > connection's blocking.
> 
> For this particular scenario, there will be only one thread since the
> entire fix-engine is to work in synchronous mode, all
> connections/sessions included. (I haven't yet been able to determine
> what types of FIX applications require this, but we need to maintain
> backward compatibility.)

 Good, then you can do as you want.

> By default, thread pool filters adjusts its size automatically, and it
> > will increase the size of pool to maximum size (default is
> > 'unlimited', oops) if all threads are busy. So you'll have to be
> > careful.
> 
> What I have not configured any thread pool filters? Specically, no
> protocol pool. Will there be then just one IO thread and one Protocol
> thread?

 If you didn't add any thread pool filters, it will run in single thread 
mode. Everything will run in one thread. So you'll have to add at least one 
thread pool filter if you're not using SimpleServiceRegistry and if you 
don't need extremely high latency.
 Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/

Re: blocking/polling events?

[Barry Kaplan <gr...@memelet.com>]

Trustin Lee wrote:

>  
> MINA will work fine even if thread takes long time to process events.  
> But There is a possibility that one thread handle more than two 
> connection, and then other connection can starve because other 
> connection's blocking.


For this particular scenario, there will be only one thread since the 
entire fix-engine is to work in synchronous mode, all 
connections/sessions included. (I haven't yet been able to determine 
what types of FIX applications require this, but we need to maintain 
backward compatibility.)

>  
> By default, thread pool filters adjusts its size automatically, and it 
> will increase the size of pool to maximum size (default is 
> 'unlimited', oops)  if all threads are busy.  So you'll have to be 
> careful.


What I have not configured any thread pool filters? Specically, no 
protocol pool. Will there be then just one IO thread and one Protocol 
thread?

-- 
barry kaplan
groups1@memelet.com

Re: blocking/polling events?

[Trustin Lee <tr...@gmail.com>]

Hi Barry,
 I applogize for the late reply.
 2005/6/14, Barry Kaplan groups1@memelet.com: 
> 
> I would like to do away this extra level of queueing (for more reasons
> than I can list here). I could simply add a latch in the
> ProtocolHandler.messageReceived, but I'm not clear what that would mean
> to mina. Would mina get pissed that that its protocol thread(s) appear
> to be hung?

 MINA will work fine even if thread takes long time to process events. But 
There is a possibility that one thread handle more than two connection, and 
then other connection can starve because other connection's blocking.
 By default, thread pool filters adjusts its size automatically, and it will 
increase the size of pool to maximum size (default is 'unlimited', oops) if 
all threads are busy. So you'll have to be careful.
 Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/