0

Since I (and many other people on the internet) are unable to configure the client-side TcpChannel timeout when using .NET Remoting (please don't suggest proper fixes, I've literally tried everything, and no WCF suggestions please), I have come up with what seems like a decent workaround to creating a client-side timeout we can configure. If I feed each Remoting call through a separate timer thread, and the call either times out or throws an Exception, then I can kill the thread and assume that the server is down.

However, I ran this by another co-worker, and he was adamant that I could cause a deadlock in the native machine code of .NET by doing this. I've read other instances of this type of technique working on the internet like this post here, so I am unsure if worrying about a deadlock is really something I should have to worry about here. I can see it maybe being a problem if the thread were to abort in the middle of sending or receiving something, but not if we're just waiting on a response.

codewario
  • 19,553
  • 20
  • 90
  • 159
  • When you say 'kill the thread' are you talking about using Thread.Abort? If so, it's true that can cause nasty side effects in some cases. See [this answer](http://stackoverflow.com/questions/1559255/whats-wrong-with-using-thread-abort) for more information. – Dan Bryant Oct 08 '12 at 14:07
  • I was thinking about using Thread.Abort(), but closer inspection of System.Threading.Thread shows the Join method, which blocks the calling thread until the child thread either returns or the timeout is reached. This seems like a much safer approach. – codewario Oct 08 '12 at 14:21
  • Note that Join will not terminate the thread in the event of a timeout; a deadlocked or otherwise misbehaving thread will still be running in the background after Join times out. – Dan Bryant Oct 08 '12 at 18:31
  • Correct me if I'm wrong, but if the thread completes its function, does the thread not terminate? Eventually the timeout DOES happen, I just can't configure it (takes about 45-60 seconds). This causes an exception, which I have handled, does nothing, and eventually the thread function does return. – codewario Oct 08 '12 at 19:02
  • 1
    Yes, if the thread actually completes, it will terminate. It's only if you're trying to terminate because it's locked up that Join will leave it hanging. The thread calling Join will return after the timeout, but the thread you were attempting to Join will be left in its "locked-up" state. – Dan Bryant Oct 08 '12 at 19:05
  • Join will only leave it hanging though if I don't specify a timeout, which I am specifying. The thread itself is "locked up" until the remoting timeout occurs, but the timeout is by no means infinite. – codewario Oct 08 '12 at 19:07

1 Answers1

0

Since Dan didn't post an answer, only commented, I attribute this answer to him. It seems that this method of managing a timeout is fine, as long as you take precautionary steps to ensure the thread execution does not continue in the event of a timeout. I also recommend against using Thread.Abort unless you know what you are doing.

codewario
  • 19,553
  • 20
  • 90
  • 159