You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "HellKnight (JIRA)" <ji...@apache.org> on 2013/12/04 07:23:35 UTC

[jira] [Comment Edited] (AMQNET-338) TcpTransport.cs - Close() taking 30 seconds

    [ 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)