You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Trustin Lee <tr...@gmail.com> on 2007/04/05 05:19:41 UTC
Re: Async bind/unbind
Hi Greg,
On 3/30/07, Greg Duffy <gd...@gmail.com> wrote:
> As I've mentioned before, I'm currently working on a new MINA Datagram
> transport, which I will hopefully contribute for one of the
> 2.0.0milestones. My method right now is to allow the user to
> instantiate a
> DatagramProcessor configured with a number of processor threads and a
> ThreadFactory. Then, you can create DatagramAcceptor/Connector with the
> DatagramProcessor passed in via the constructor. A parameterless constructor
> is also provided, which just uses a private DatagramProcessor instance. This
> way, the user can share selectors and worker threads as they choose. It's
> working pretty well so far.
Very cool! I am really looking forward to it.
> On to my question. Should we provide asynchronous bind and unbind operation?
> Sometimes I don't care to wait around for the bind or unbind to occur in the
> processor thread, so provide a Bind/UnbindFuture result like other MINA
> operations seems like a good idea.
>
> What do you think? Is there a reason not to do this, and, if not, could it
> be a change for the 2.0.0 API?
I just didn't do that because binding and unbinding don't occur
frequently. I didn't want to sweat for unused feature. It would be
great to know if there's any use case for asynchronous bind/unbind
operation.
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Async bind/unbind
Posted by Trustin Lee <tr...@gmail.com>.
On 4/5/07, Greg Duffy <gd...@gmail.com> wrote:
> Great! Yes, I will take this on, and I will also see about getting the
> change into SocketAcceptor. I'll let you know if I need any help.
Cool! :D
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Async bind/unbind
Posted by Greg Duffy <gd...@gmail.com>.
Great! Yes, I will take this on, and I will also see about getting the
change into SocketAcceptor. I'll let you know if I need any help.
Thanks
-Greg
On 4/5/07, Trustin Lee <tr...@gmail.com> wrote:
>
> On 4/5/07, Greg Duffy <gd...@gmail.com> wrote:
> > Here's one possible use case: I have just one processor thread and no
> thread
> > pool. I want to unbind from within an IoHandler method (messageReceived,
> > sessionIdle, etc), but currently we wait for the unbind to finish.
> Doesn't
> > this automatically create a deadlock? I.e., waiting for an unbind in the
> > thread that services the unbind request.
> >
> > I could create a separate Executor and submit tasks that do the actual
> > unbind, but if we provide Bind/UnbindFuture, it simply turns into
> > IoAcceptor.unbind() vs. IoAcceptor.unbind().join() ...
> >
> > I guess it's the same for binding a new IoAcceptor from the processor
> > thread. A lot of applications use ephemeral ports, and that is where
> this
> > issue will come up.
> >
> > Let me know what you think, or if I don't understand something about
> this :)
>
> Aha! Sounds reasonable to me. Are you going to work on the change?
> It would be great!
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
Re: Async bind/unbind
Posted by Trustin Lee <tr...@gmail.com>.
On 4/5/07, Greg Duffy <gd...@gmail.com> wrote:
> Here's one possible use case: I have just one processor thread and no thread
> pool. I want to unbind from within an IoHandler method (messageReceived,
> sessionIdle, etc), but currently we wait for the unbind to finish. Doesn't
> this automatically create a deadlock? I.e., waiting for an unbind in the
> thread that services the unbind request.
>
> I could create a separate Executor and submit tasks that do the actual
> unbind, but if we provide Bind/UnbindFuture, it simply turns into
> IoAcceptor.unbind() vs. IoAcceptor.unbind().join() ...
>
> I guess it's the same for binding a new IoAcceptor from the processor
> thread. A lot of applications use ephemeral ports, and that is where this
> issue will come up.
>
> Let me know what you think, or if I don't understand something about this :)
Aha! Sounds reasonable to me. Are you going to work on the change?
It would be great!
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Async bind/unbind
Posted by Greg Duffy <gd...@gmail.com>.
Here's one possible use case: I have just one processor thread and no thread
pool. I want to unbind from within an IoHandler method (messageReceived,
sessionIdle, etc), but currently we wait for the unbind to finish. Doesn't
this automatically create a deadlock? I.e., waiting for an unbind in the
thread that services the unbind request.
I could create a separate Executor and submit tasks that do the actual
unbind, but if we provide Bind/UnbindFuture, it simply turns into
IoAcceptor.unbind() vs. IoAcceptor.unbind().join() ...
I guess it's the same for binding a new IoAcceptor from the processor
thread. A lot of applications use ephemeral ports, and that is where this
issue will come up.
Let me know what you think, or if I don't understand something about this :)
-Greg
On 4/4/07, Trustin Lee <tr...@gmail.com> wrote:
>
> Hi Greg,
>
> On 3/30/07, Greg Duffy <gd...@gmail.com> wrote:
> > As I've mentioned before, I'm currently working on a new MINA Datagram
> > transport, which I will hopefully contribute for one of the
> > 2.0.0milestones. My method right now is to allow the user to
> > instantiate a
> > DatagramProcessor configured with a number of processor threads and a
> > ThreadFactory. Then, you can create DatagramAcceptor/Connector with the
> > DatagramProcessor passed in via the constructor. A parameterless
> constructor
> > is also provided, which just uses a private DatagramProcessor instance.
> This
> > way, the user can share selectors and worker threads as they choose.
> It's
> > working pretty well so far.
>
> Very cool! I am really looking forward to it.
>
> > On to my question. Should we provide asynchronous bind and unbind
> operation?
> > Sometimes I don't care to wait around for the bind or unbind to occur in
> the
> > processor thread, so provide a Bind/UnbindFuture result like other MINA
> > operations seems like a good idea.
> >
> > What do you think? Is there a reason not to do this, and, if not, could
> it
> > be a change for the 2.0.0 API?
>
> I just didn't do that because binding and unbinding don't occur
> frequently. I didn't want to sweat for unused feature. It would be
> great to know if there's any use case for asynchronous bind/unbind
> operation.
>
> Cheers,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>