|
Home > Archive > Apache Directory Project > June 2005 > blocking/polling events?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
blocking/polling events?
|
|
| Barry Kaplan 2005-06-13, 5:45 pm |
| 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-oTlvBSL8hjVBDgjK7y7TUQ@public.gmane.org
| |
| Trustin Lee 2005-06-15, 2:45 am |
| Hi Barry,
I applogize for the late reply.
2005/6/14, Barry Kaplan groups1-oTlvBSL8hjVBDgjK7y7TUQ@public.gmane.org:
>
> 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/
| |
| Barry Kaplan 2005-06-15, 8:45 pm |
| 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-oTlvBSL8hjVBDgjK7y7TUQ@public.gmane.org
| |
| Trustin Lee 2005-06-15, 8:45 pm |
| 2005/6/16, Barry Kaplan <groups1-oTlvBSL8hjVBDgjK7y7TUQ@public.gmane.org>:
>
>
> 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
>
> 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/
|
|
|
|
|