Re: Is it all right to reduce the timeout as a walkaround for AMQNET-338?

[Jim Gomes <jg...@apache.org>]

The 30 second time-out was meant to give the reader thread a reasonable
time to finish what it is doing and shut itself down gracefully. Once it
times out, then it is forcefully shutdown as  a last resort. Normally, the
graceful shutdown should occur very rapidly. If you are just letting the
garbage collector clean things up on program termination, then your app
probably isn't doing any meaningful work so it should be fine to
 forcefully shut it down after a shorter timeout.


On Tue, Dec 3, 2013 at 10:28 PM, 汤・吉诃德 <he...@foxmail.com> wrote:

> Hi Jim, I want to use the temporary walkaround mentioned by the issue
> reporter, to reduce the timeout in the following code from 30 seconds to 2
> seconds:
>
> if(null != readThread)
> {
> 	if(Thread.CurrentThread != readThread && readThread.IsAlive)
> 	{
> 		if(!readThread.Join((int) MAX_THREAD_WAIT.TotalMilliseconds))
> 		{
> 			readThread.Abort();
> 		}
> 	}
>
> 	readThread = null;
> }
>
> However, I am worried about my walkaround : Could there be any harm if I
> reduce the timeout ? By default, the code wait as long as 30 seconds for
> readThread to join. What is the purpose of such a behaviour ?What could
> keep readThread alive for 30 seconds while closing connection ? Is it OK to
> wait for a shorter timespan?
>

Re: 回复： Is it all right to reduce the timeout as a walkaround for AMQNET-338?

[Jim Gomes <jg...@apache.org>]

It's hard to say what the worst-case would be, since it's application
specific. I think an orderly shutdown would be to disconnect all producers
and consumers first, and then close the connection.


On Thu, Dec 5, 2013 at 4:19 AM, 汤・吉诃德 <he...@foxmail.com> wrote:

> Hi Jim, thanks for your quick and detailed reply.  Actually , I want to
> call connection.Close() when the user close the client program (such as
> click the close button of program window), not wait for GC to clean up the
> connection object. Is it still OK to reduce the timeout ? What is the worst
> case scenario of forcefully abort readerThread after a shorter timeout ?
>
>
> ------------------ 原始邮件 ------------------
> *发件人:* "Jim Gomes";<jg...@apache.org>;
> *发送时间:* 2013年12月5日(星期四) 中午11:03
> *收件人:* "汤・吉诃德"<he...@foxmail.com>; "ActiveMQ Dev"<
> dev@activemq.apache.org>;
> *主题:* Re: Is it all right to reduce the timeout as a walkaround for
> AMQNET-338?
>
> The 30 second time-out was meant to give the reader thread a reasonable
> time to finish what it is doing and shut itself down gracefully. Once it
> times out, then it is forcefully shutdown as  a last resort. Normally, the
> graceful shutdown should occur very rapidly. If you are just letting the
> garbage collector clean things up on program termination, then your app
> probably isn't doing any meaningful work so it should be fine to
>  forcefully shut it down after a shorter timeout.
>
>
> On Tue, Dec 3, 2013 at 10:28 PM, 汤・吉诃德 <he...@foxmail.com> wrote:
>
>> Hi Jim, I want to use the temporary walkaround mentioned by the issue
>> reporter, to reduce the timeout in the following code from 30 seconds to 2
>> seconds:
>>
>> if(null != readThread)
>> {
>> 	if(Thread.CurrentThread != readThread && readThread.IsAlive)
>> 	{
>> 		if(!readThread.Join((int) MAX_THREAD_WAIT.TotalMilliseconds))
>> 		{
>> 			readThread.Abort();
>> 		}
>> 	}
>>
>> 	readThread = null;
>> }
>>
>> However, I am worried about my walkaround : Could there be any harm if I
>> reduce the timeout ? By default, the code wait as long as 30 seconds for
>> readThread to join. What is the purpose of such a behaviour ?What could
>> keep readThread alive for 30 seconds while closing connection ? Is it OK to
>> wait for a shorter timespan?
>>
>
>