Re: Killing a thread started with delegate.BeginInvoke()
From: Alvin Bruney [MVP] (vapor)
Date: 02/10/05
- Next message: Jako Menkveld: "Re: Killing a thread started with delegate.BeginInvoke()"
- Previous message: Jako Menkveld: "Re: CLOSE_WAIT"
- In reply to: Jako Menkveld: "Re: Killing a thread started with delegate.BeginInvoke()"
- Next in thread: Jako Menkveld: "Re: Killing a thread started with delegate.BeginInvoke()"
- Reply: Jako Menkveld: "Re: Killing a thread started with delegate.BeginInvoke()"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 10 Feb 2005 14:07:00 -0400
Why arenm't you keeping remote connections open? Would it not be more
efficient to open the connection only when it is needed? Modify your
connection string to force connection pooling to be on (i think it is off
for remote configurations) if object creating is particularly expensive.
With this design, you wouldn't need to kill threads.
-- Regards, Alvin Bruney [MVP ASP.NET] [Shameless Author plug] The Microsoft Office Web Components Black Book with .NET Now Available @ http://www.lulu.com/owc ---------------------------------------------------------- "Jako Menkveld" <jako.menkveld@envalue.ch> wrote in message news:OTps5$1DFHA.2232@TK2MSFTNGP14.phx.gbl... > Sadhu / Sunny > > Thanks for your replies. > > OK, I'll have a go at explaining this: > > I have a server exposing a remote object (on TCP). Then I have clients > which connects to the server and calls methods on the remote object as > random interval. For performance reasons, I don't break and re-establish > the connection everytime, I keep a reference to the remote object and just > keep calling it's methods whenever I need them. > > This sounds like a simple scenario, but the problem comes in when the > server shuts down (this can happen in my implementation and I need to > cater for this). > > I mentioned in an post to this newsgroup that I have a problem "killing" > the TCP connection when the server shutsdown. This is because the clients > still have their side of the connection and for some reason the OS takes > over control of the listening port. (see my post: How to "kill" a tcp > port, posted 31/01/2005). > > When the client then tries to call a method on the server, it just hangs > without throwing an exception, which means I have to kill the process > using Task Manager. > > To overcome this problem I use an asynchronous delegate to call the method > and wait a specified time for the method to return, if it doesn't, I treat > it as if the server has been shutdown. What I'm left with after that is > the asynchronous delegate's thread which I want to kill. > > I hope this makes it a bit clearer. > > Cheers > Jako > > > "Sunny" <sunny@newsgroup.nospam> wrote in message > news:uYs937rDFHA.628@TK2MSFTNGP15.phx.gbl... >> In article <emx2B2eDFHA.208@TK2MSFTNGP12.phx.gbl>, >> jako.menkveld@envalue.ch says... >>> Is this at all possible? >>> >>> >>> >> >> Not directly. As sadhu said, they are from the thread pool, so they are >> managed by the framework. >> >> But if you provide more information about what you want to achieve, >> maybe someone can come up with workaround. >> >> Sunny > >
- Next message: Jako Menkveld: "Re: Killing a thread started with delegate.BeginInvoke()"
- Previous message: Jako Menkveld: "Re: CLOSE_WAIT"
- In reply to: Jako Menkveld: "Re: Killing a thread started with delegate.BeginInvoke()"
- Next in thread: Jako Menkveld: "Re: Killing a thread started with delegate.BeginInvoke()"
- Reply: Jako Menkveld: "Re: Killing a thread started with delegate.BeginInvoke()"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
