[
https://issues.apache.org/jira/browse/AMQNET-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13838657#comment-13838657
]
HellKnight edited comment on AMQNET-338 at 12/4/13 6:22 AM:
------------------------------------------------------------
Hi All, I want to use the temporary walkaround mentioned by the 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?
was (Author: hellknight):
Hi All, I want to use the temporary walkaround mentioned by the 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 ?
> TcpTransport.cs - Close() taking 30 seconds
> -------------------------------------------
>
> Key: AMQNET-338
> URL: https://issues.apache.org/jira/browse/AMQNET-338
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ
> Affects Versions: 1.5.1, 1.5.6
> Environment: Windows 7, .NET 2.0, Visual Studio 2008, Unity 3.4
> Reporter: Eddie Fast
>
> We've been noticing a random freeze on exit for 30 seconds. The frequency is
> different per machine, but it happens about 10-30% of the time, sometimes
> more. We've traced it down to TcpTransport.Close(), in this block:
> {noformat}
> if(null != readThread)
> {
> if(Thread.CurrentThread != readThread && readThread.IsAlive)
> {
> if(!readThread.Join((int) MAX_THREAD_WAIT.TotalMilliseconds))
> {
> readThread.Abort();
> }
> }
> readThread = null;
> }
> {noformat}
> We're running this in the Unity game engine, which run C# script in a Mono
> environment.
> I understand that reproducing this on your end would be difficult, but I'm
> reporting this in the hopes that I can gain some insight why this is
> happening.
> - What thread is this code waiting for?
> - What would be some of the causes of the deadlock?
> No messages are being sent or received. It's basically starting up and
> closing down.
> Our temporary workaround is to reduce this wait time from 30 seconds to 5
> seconds, but I'd like to eventually find a cause.
> Thanks
--
This message was sent by Atlassian JIRA
(v6.1#6144)
