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, 汤・吉诃德 <hellkni...@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";<jgo...@apache.org>;
> *发送时间:* 2013年12月5日(星期四) 中午11:03
> *收件人:* "汤・吉诃德"<hellkni...@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, 汤・吉诃德 <hellkni...@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?
>>
>
>
