You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Greg Duffy <gd...@gmail.com> on 2007/02/03 04:44:45 UTC
Datagram implementation question
Hi MINA crew!
I have a couple of questions about the current datagram transport
implementation. I'm using the svn trunk directly (2.0.0-M1-SNAPSHOT).
Is there a reason that DatagramAcceptor and DatagramConnector use a delegate
pattern? Also, is there a reason that they can't have multiple processor
threads like their socket counterparts?
I don't know if there is an architectural difficulty I'm missing, or if
there hasn't been enough dev time/interest to spruce up the datagram
implementation, or maybe something completely different. If it's just the
lack of dev interest or time, I might be able to make a patch for it. I've
done one other MINA patch for the IoSessionRecycler, so I've at least gotten
my feet a little wet in terms of contributing. (and I even know now not to
accidentally hit my Eclipse format shortcut before submitting my patch!)
What do you think? Are there any gotchas that I don't see?
-Greg Duffy
Re: Datagram implementation question
Posted by Trustin Lee <tr...@gmail.com>.
2007-02-16 (금), 08:32 -0600, Greg Duffy 쓰시길:
> On 2/16/07, Trustin Lee <tr...@gmail.com> wrote:
> > And... closing selectors on unbind sounds reasonable to me. Where the
> > problem resides is connector-side. SocketConnector shouldn't close its
> > selector just because there's no pending connection attempt. Anyone can
> > request connection attempt at any time and creating a selector takes a lot
> > of time. Moreover, creating a selector every time a worker thread is
> > created made the code more complex than maintaining it as a final member
> > field.
> Agreed, but could we fix this along with DIRMINA-316?
Sure.
> > But... you came up with a great solution; the selector pool! How couldn't I
> > think that nice solution? We could probably utilize Jakarta Commons Pool
> > here. What do you think? What would be a potential problem if we use the
> > selector pool?
> A selector pool might be a good solution. But, there's some questions we
> have to ask first.
>
> 1) Should we make it pluggable, as mentioned by Rob below? I think so.
> Sometimes, somebody may even just want to open and close immediately.
Yes, we need to make it pluggable. I think using commons-pool
internally is fine comparing to the cost to create a new selector even
if it uses a simple 'synchronized' block. We will have to wrap it up
with our own SelectorFactory interface though.
> 2) What should be our default implementation? Is Commons Pool still actively
> maintained? Is it well tested and performant? (I don't know, just asking
> those who might know better)
It's well-tested and will perform at least much better than creating a
new selector.
> 3) Pooling is less deterministic than opening a selector for each
> IoConnector/IoAcceptor and closing it in shutdown/unbind. So, can we think
> of test cases to keep it running smoothly? Can we give the user better error
> messages if the pool can't create more selectors? There will be a few more
> variables to tune than normal: pool size and pool death rate vs. the OS file
> descriptor limit, etc.
The selector pool will fail to create a new selector only when you are
out of file descriptor, just like when you don't pool anything at all
because it's a matter of 'maximum number.'
The only solution to this problem is to increase the maximum number of
open files per process per user. Of course, we can log some message
using global ExceptionListener to tell the user to increase the 'ulimit
-n' value.
The pool size should start from 0 without upper limit. We can make it
easily configurable because we are going to make the pool implementation
pluggable.
> 4) Better yet, will anybody actually create/destroy that many
> connectors/acceptors every second? Well, maybe.
It will at least help MINA beginner bump up to the problem too soon. :)
> Anyway, just my thoughts so far. Thanks for the enthusiastic response!
>
> It sounds like you're going on holiday, and I'm in a real time-crunch on my
> current project, so maybe we can revisit this in a week or two. Have a great
> holiday, and get some rest!
I hope you had a great rest, too!
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Datagram implementation question
Posted by Greg Duffy <gd...@gmail.com>.
On 2/16/07, Trustin Lee <tr...@gmail.com> wrote:
>
> Hi Greg,
<SNIP>
>
First, WOW! I really want to see what your datagram implementation looks
> like. I bet it's much better than what I wrote. :)
Well, I wouldn't have thought up the awesome architecture that you came up
with for MINA. So, if I can help out with the plumbing, it's my pleasure! I
understand completely that we focus on the area of the software that we use
the most, especially since MINA is open source, so why shouldn't I be the
one to improve the datagram stuff that I use a lot? :)
And... closing selectors on unbind sounds reasonable to me. Where the
> problem resides is connector-side. SocketConnector shouldn't close its
> selector just because there's no pending connection attempt. Anyone can
> request connection attempt at any time and creating a selector takes a lot
> of time. Moreover, creating a selector every time a worker thread is
> created made the code more complex than maintaining it as a final member
> field.
Agreed, but could we fix this along with DIRMINA-316?
But... you came up with a great solution; the selector pool! How couldn't I
> think that nice solution? We could probably utilize Jakarta Commons Pool
> here. What do you think? What would be a potential problem if we use the
> selector pool?
A selector pool might be a good solution. But, there's some questions we
have to ask first.
1) Should we make it pluggable, as mentioned by Rob below? I think so.
Sometimes, somebody may even just want to open and close immediately.
2) What should be our default implementation? Is Commons Pool still actively
maintained? Is it well tested and performant? (I don't know, just asking
those who might know better)
3) Pooling is less deterministic than opening a selector for each
IoConnector/IoAcceptor and closing it in shutdown/unbind. So, can we think
of test cases to keep it running smoothly? Can we give the user better error
messages if the pool can't create more selectors? There will be a few more
variables to tune than normal: pool size and pool death rate vs. the OS file
descriptor limit, etc.
4) Better yet, will anybody actually create/destroy that many
connectors/acceptors every second? Well, maybe.
Thanks,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
Anyway, just my thoughts so far. Thanks for the enthusiastic response!
It sounds like you're going on holiday, and I'm in a real time-crunch on my
current project, so maybe we can revisit this in a week or two. Have a great
holiday, and get some rest!
-Greg
Re: Datagram implementation question
Posted by Trustin Lee <tr...@gmail.com>.
Hi Greg,
On 2/16/07, Greg Duffy <gd...@gmail.com> wrote:
>
> Hi,
>
> I'm in the process of completely recoding DatagramAcceptor and
> DatagramConnector for MINA (will be done in a week or two, as I'm busy
> with
> other stuff), and I just noticed this old issue:
>
> http://issues.apache.org/jira/browse/DIRMINA-154
>
> As Trustin mentioned in the comments of that issue, Sun fixed a file
> descriptor leak in DatagramSocket/DatagramChannel. However, there is
> another
> unrelated file descriptor leak in DatagramAcceptor. It's the selector. It
> seems that MINA is closing selectors in the IoAcceptors' finalizers. These
> finalizers may not get called before the process runs out of file
> descriptors, especially for short-lived IoAcceptors. The heap is big, but
> file descriptor limits are usually small (approx. 1000-10000 per process
> by
> default, depending on OS).
>
> In my app, which binds and unbinds to many ephemeral ports for each
> transaction, I run out of file descriptors in about 5 minutes under load.
> When closing the selector immediately, it hasn't run out for over 24
> hours.
>
> So, I think we should close selectors immediately after unbinding
> (cancellation) and/or maybe even pool selectors. So, maybe we could
> implement the immediate closure as a bug fix now and do some performance
> testing to decide on selector pooling. I can open and close about 1100
> selectors per second on my machine. Is it worth it?
>
> I think this issue affects SocketAcceptor too.
>
> What do you think?
First, WOW! I really want to see what your datagram implementation looks
like. I bet it's much better than what I wrote. :)
And... closing selectors on unbind sounds reasonable to me. Where the
problem resides is connector-side. SocketConnector shouldn't close its
selector just because there's no pending connection attempt. Anyone can
request connection attempt at any time and creating a selector takes a lot
of time. Moreover, creating a selector every time a worker thread is
created made the code more complex than maintaining it as a final member
field.
But... you came up with a great solution; the selector pool! How couldn't I
think that nice solution? We could probably utilize Jakarta Commons Pool
here. What do you think? What would be a potential problem if we use the
selector pool?
Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Datagram implementation question
Posted by Greg Duffy <gd...@gmail.com>.
Hi,
I'm in the process of completely recoding DatagramAcceptor and
DatagramConnector for MINA (will be done in a week or two, as I'm busy with
other stuff), and I just noticed this old issue:
http://issues.apache.org/jira/browse/DIRMINA-154
As Trustin mentioned in the comments of that issue, Sun fixed a file
descriptor leak in DatagramSocket/DatagramChannel. However, there is another
unrelated file descriptor leak in DatagramAcceptor. It's the selector. It
seems that MINA is closing selectors in the IoAcceptors' finalizers. These
finalizers may not get called before the process runs out of file
descriptors, especially for short-lived IoAcceptors. The heap is big, but
file descriptor limits are usually small (approx. 1000-10000 per process by
default, depending on OS).
In my app, which binds and unbinds to many ephemeral ports for each
transaction, I run out of file descriptors in about 5 minutes under load.
When closing the selector immediately, it hasn't run out for over 24 hours.
So, I think we should close selectors immediately after unbinding
(cancellation) and/or maybe even pool selectors. So, maybe we could
implement the immediate closure as a bug fix now and do some performance
testing to decide on selector pooling. I can open and close about 1100
selectors per second on my machine. Is it worth it?
I think this issue affects SocketAcceptor too.
What do you think?
-Greg
On 2/3/07, Trustin Lee <tr...@gmail.com> wrote:
>
> Hi Greg,
>
> On 2/3/07, Greg Duffy <gd...@gmail.com> wrote:
> >
> > Hi MINA crew!
> >
> > I have a couple of questions about the current datagram transport
> > implementation. I'm using the svn trunk directly (2.0.0-M1-SNAPSHOT).
> >
> > Is there a reason that DatagramAcceptor and DatagramConnector use a
> > delegate
> > pattern? Also, is there a reason that they can't have multiple processor
> > threads like their socket counterparts?
>
>
> I used delegate pattern to hide DatagramService (in datagam.supportpackage)
> interface which provides public internal methods (e.g. flushSession). It
> would be better if there's a way that doesn't use a delegate pattern.
>
> As you know, datagram transport doesn't have more popularity than socket
> transport. That's why we didn't implement multiple processor threads yet.
> We've been focusing on socket transport. There's no other reason, and
> datagram transport needs improvement definitely.
>
> I don't know if there is an architectural difficulty I'm missing, or if
> > there hasn't been enough dev time/interest to spruce up the datagram
> > implementation, or maybe something completely different. If it's just
> the
> > lack of dev interest or time, I might be able to make a patch for it.
> I've
> > done one other MINA patch for the IoSessionRecycler, so I've at least
> > gotten
> > my feet a little wet in terms of contributing. (and I even know now not
> to
> > accidentally hit my Eclipse format shortcut before submitting my patch!)
>
>
> Your patch is always welcome! It is always great to have someone who
> deals
> with various transport types. Julien is working on serial / parallel port
> support, and you could lend us your hands to improve our datagram support.
> :)
>
> What do you think? Are there any gotchas that I don't see?
>
>
> You didn't misunderstand anything. I am impressed!
>
> Thanks,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP key fingerprints:
> * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
> * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
>
Re: Datagram implementation question
Posted by Trustin Lee <tr...@gmail.com>.
Hi Greg,
On 2/3/07, Greg Duffy <gd...@gmail.com> wrote:
>
> Hi MINA crew!
>
> I have a couple of questions about the current datagram transport
> implementation. I'm using the svn trunk directly (2.0.0-M1-SNAPSHOT).
>
> Is there a reason that DatagramAcceptor and DatagramConnector use a
> delegate
> pattern? Also, is there a reason that they can't have multiple processor
> threads like their socket counterparts?
I used delegate pattern to hide DatagramService (in datagam.support package)
interface which provides public internal methods (e.g. flushSession). It
would be better if there's a way that doesn't use a delegate pattern.
As you know, datagram transport doesn't have more popularity than socket
transport. That's why we didn't implement multiple processor threads yet.
We've been focusing on socket transport. There's no other reason, and
datagram transport needs improvement definitely.
I don't know if there is an architectural difficulty I'm missing, or if
> there hasn't been enough dev time/interest to spruce up the datagram
> implementation, or maybe something completely different. If it's just the
> lack of dev interest or time, I might be able to make a patch for it. I've
> done one other MINA patch for the IoSessionRecycler, so I've at least
> gotten
> my feet a little wet in terms of contributing. (and I even know now not to
> accidentally hit my Eclipse format shortcut before submitting my patch!)
Your patch is always welcome! It is always great to have someone who deals
with various transport types. Julien is working on serial / parallel port
support, and you could lend us your hands to improve our datagram support.
:)
What do you think? Are there any gotchas that I don't see?
You didn't misunderstand anything. I am impressed!
Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6