Killing a thread started with delegate.BeginInvoke()

[Jako Menkveld]

Is this at all possible?

 

[sadhu]

IIRC, those threads are from the ThreadPool, so I think there is no way
to kill/abort them.

 

[Sunny]

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

 

[Jako Menkveld]

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

 

[Alvin Bruney [MVP]]

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]

Alvin

Thanks for the reply, but this leaves me a bit confused.

Where do you specify a connection string when using .NET Remoting? It
sounds like you are referring to database connections?

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

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

 

[Alvin Bruney [MVP]]

yes, sorry i got confused for a bit. But it is still possible to object
pool, use this as a starting point.
http://visualbasic.ittoolbox.com/documents/document.asp?i=1935
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/introremoting.asp
(scroll to middle of the page)

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

Alvin

Thanks for the reply, but this leaves me a bit confused.

Where do you specify a connection string when using .NET Remoting? It
sounds like you are referring to database connections?

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

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


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

 

[Jako Menkveld]

Thanks Alvin, I'll have a read through it to see if it helps.

yes, sorry i got confused for a bit. But it is still possible to object
pool, use this as a starting point.
http://visualbasic.ittoolbox.com/documents/document.asp?i=1935
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/introremoting.asp
(scroll to middle of the page)

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

Alvin

Thanks for the reply, but this leaves me a bit confused.

Where do you specify a connection string when using .NET Remoting? It
sounds like you are referring to database connections?

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


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


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

 

[sadhu]

What happens when you call EndInvoke()?

 

[Jako Menkveld]

I don't actually know, I'll have a look. I would think it waits for the
method to finish, but I might be wrong.