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 2006/11/24 07:07:04 UTC
SocketConnector.setWorkerTimeout()
Hi,
The workerTimeout property of SocketConnector prevents its worker thread
from dying too soon that a following connection attempt takes too long time
because of new instantiation of Selector and Thread. The default value is 1
minute, and can be changed by calling setWorkerTimeout() method.
My question here is, does it really need to be configurable? Because we are
having the same issue with SocketIoProcessor, we will also have to add the
property to SocketAcceptor if it should be configurable. We can simply add
it, but I want to know if it is really need to be configurable. Say we just
hard-coded the workerTimeout to 5 seconds. The worst case is that
connection attempts take place every 5 seconds, but it's *big* 5 seconds
which make the instantiation overhead (for Selector and Thread) negligible.
Any feedbacks are welcome, and I will get rid of workerTimeout property if
there's no objection within 3 days.
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: SocketConnector.setWorkerTimeout()
Posted by Trustin Lee <tr...@gmail.com>.
On 11/24/06, Maarten Bosteels <mb...@gmail.com> wrote:
>
> Trustin, are you proposing to change the workerTimeout
> from default 60 seconds + configurable
> to 5 seconds hard-coded ?
Yes. Peter added the property, so I also want to what he thinks about my
idea.
Not that I have an objection right now, just want to make sure that I
> understand your proposal.
You got it correctly. :)
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: SocketConnector.setWorkerTimeout()
Posted by Maarten Bosteels <mb...@gmail.com>.
Trustin, are you proposing to change the workerTimeout
from default 60 seconds + configurable
to 5 seconds hard-coded ?
Not that I have an objection right now, just want to make sure that I
understand your proposal.
On 11/24/06, Trustin Lee <tr...@gmail.com> wrote:
>
> Hi,
>
> The workerTimeout property of SocketConnector prevents its worker thread
> from dying too soon that a following connection attempt takes too long
> time
> because of new instantiation of Selector and Thread. The default value is
> 1
> minute, and can be changed by calling setWorkerTimeout() method.
>
> My question here is, does it really need to be configurable? Because we
> are
> having the same issue with SocketIoProcessor, we will also have to add the
> property to SocketAcceptor if it should be configurable. We can simply
> add
> it, but I want to know if it is really need to be configurable. Say we
> just
> hard-coded the workerTimeout to 5 seconds. The worst case is that
> connection attempts take place every 5 seconds, but it's *big* 5 seconds
> which make the instantiation overhead (for Selector and Thread)
> negligible.
>
> Any feedbacks are welcome, and I will get rid of workerTimeout property if
> there's no objection within 3 days.
>
> 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: [VOTE] SocketConnector.setWorkerTimeout()
Posted by Trustin Lee <tr...@gmail.com>.
Hi,
On 3/14/07, Coding Horse <zh...@hotmail.com> wrote:
> I'm using mina 2.0 trunk and find no shutdown method in SocketConnector
> class. Did you change your mind of adding it or...?
We were considering to use a selector pool instead of explicit
shutdown method recently. It should be fixed somehow though.
> I'm not sure if I understand worker timeout concept correctly. Say we have
> it set as 20 seconds for a mina implementation of a chat client. A chatting
> happens exactly every 30 seconds. In this case every 30 seconds a worker
> thread will be created and die after about 20 seconds. Am I right?
Correct.
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: [VOTE] SocketConnector.setWorkerTimeout()
Posted by Coding Horse <zh...@hotmail.com>.
Hi, Trustin,
I'm using mina 2.0 trunk and find no shutdown method in SocketConnector
class. Did you change your mind of adding it or...?
I'm not sure if I understand worker timeout concept correctly. Say we have
it set as 20 seconds for a mina implementation of a chat client. A chatting
happens exactly every 30 seconds. In this case every 30 seconds a worker
thread will be created and die after about 20 seconds. Am I right?
thanks
Trustin Lee wrote:
>
> On 11/25/06, peter royal <pr...@apache.org> wrote:
>>
>> On Nov 23, 2006, at 10:07 PM, Trustin Lee wrote:
>> > My question here is, does it really need to be configurable?
>> > Because we are
>> > having the same issue with SocketIoProcessor, we will also have to
>> > add the
>> > property to SocketAcceptor if it should be configurable. We can
>> > simply add
>> > it, but I want to know if it is really need to be configurable.
>> > Say we just
>> > hard-coded the workerTimeout to 5 seconds. The worst case is that
>> > connection attempts take place every 5 seconds, but it's *big* 5
>> > seconds
>> > which make the instantiation overhead (for Selector and Thread)
>> > negligible.
>> >
>> > Any feedbacks are welcome, and I will get rid of workerTimeout
>> > property if
>> > there's no objection within 3 days.
>>
>> As long as there is a timeout it needs to be configurable (so it can
>> be set to a large enough value as to not time out at all).
>>
>> The only removal I support is not having the worker threads time-out
>> at all. Rather, doing a graceful shutdown when their owning component
>> tells them to shut down.
>
>
> That makes sense. Then let me provide an explicit shutdown method rather
> than providing timeouts.
>
> 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
>
>
--
View this message in context: http://www.nabble.com/SocketConnector.setWorkerTimeout%28%29-tf2695998.html#a9456584
Sent from the mina dev mailing list archive at Nabble.com.
Re: SocketConnector.setWorkerTimeout()
Posted by Trustin Lee <tr...@gmail.com>.
On 11/25/06, peter royal <pr...@apache.org> wrote:
>
> On Nov 23, 2006, at 10:07 PM, Trustin Lee wrote:
> > My question here is, does it really need to be configurable?
> > Because we are
> > having the same issue with SocketIoProcessor, we will also have to
> > add the
> > property to SocketAcceptor if it should be configurable. We can
> > simply add
> > it, but I want to know if it is really need to be configurable.
> > Say we just
> > hard-coded the workerTimeout to 5 seconds. The worst case is that
> > connection attempts take place every 5 seconds, but it's *big* 5
> > seconds
> > which make the instantiation overhead (for Selector and Thread)
> > negligible.
> >
> > Any feedbacks are welcome, and I will get rid of workerTimeout
> > property if
> > there's no objection within 3 days.
>
> As long as there is a timeout it needs to be configurable (so it can
> be set to a large enough value as to not time out at all).
>
> The only removal I support is not having the worker threads time-out
> at all. Rather, doing a graceful shutdown when their owning component
> tells them to shut down.
That makes sense. Then let me provide an explicit shutdown method rather
than providing timeouts.
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: SocketConnector.setWorkerTimeout()
Posted by peter royal <pr...@apache.org>.
On Nov 23, 2006, at 10:07 PM, Trustin Lee wrote:
> My question here is, does it really need to be configurable?
> Because we are
> having the same issue with SocketIoProcessor, we will also have to
> add the
> property to SocketAcceptor if it should be configurable. We can
> simply add
> it, but I want to know if it is really need to be configurable.
> Say we just
> hard-coded the workerTimeout to 5 seconds. The worst case is that
> connection attempts take place every 5 seconds, but it's *big* 5
> seconds
> which make the instantiation overhead (for Selector and Thread)
> negligible.
>
> Any feedbacks are welcome, and I will get rid of workerTimeout
> property if
> there's no objection within 3 days.
As long as there is a timeout it needs to be configurable (so it can
be set to a large enough value as to not time out at all).
The only removal I support is not having the worker threads time-out
at all. Rather, doing a graceful shutdown when their owning component
tells them to shut down.
-pete
--
proyal@apache.org - http://fotap.org/~osi