[concurrency-interest] Need to kill a single working thread, rather than killing the applica

Dhanji R. Prasanna dhanji at gmail.com
Mon Dec 18 19:30:23 EST 2006


On 18 Dec 2006 18:17:02 -0000, Chirag Shah <chirag_r_shah at rediffmail.com>
wrote:
>
>
> Hi Dhanji,
>
> Thanks for your reply. I have this code on the client side. But the thread
> on the server side is already in the working status. So from the server
> side, if I do not kill the thread, which is taking long time, I will hit the
> max capacity of threads (ie 600 threads all are working) and the new request
> will be queued until a thread gets free.
>

When I said client I am referring to the client code, i.e. the server
sockets (presumably) which are being run on the TPE, not the actual network
client itself.

Setting a timeout on your server sockets will force them to abort the job
after n seconds in a predictable manner. You can catch
SocketTimeoutException and close the socket properly.
>
>
> Is it better idea to call Thread.stop method. will TPE create new thread,
> if I kill a thread(s). ie I have 600 min thread and if I kill 10 thread,
> will it create 10 thread to reach min capacity?
>

It is a very bad idea to call Thread.stop()--it has even been deprecated
from the API. The client code (i.e. the Runnable) should exit itself by for
example exiting a loop or some such way of returning from run().

Thread operations that mutate the state of the thread outside of the client
code are inherently unsafe. This is why synchronization (thru wait() and
notify() or the higher-level constructs in j.u.c) is preferable to calling
suspend() and resume() for instance.
See this part of the doc for better explanation:

http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html


Dhanji.

> Thanks
> Chirag
>
> On Mon, 18 Dec 2006 Dhanji R.Prasanna wrote :
> >Hi Chirag
> >
> >I would advise having your client abort its io operation rather than an
> >enforced kill timeout from the TPE. Architecturally it is unsound to
> >arbitrarily terminate a client thread (you dont know what state it is in,
> >for instance). The client operation should raise an exception if it is
> >taking too long by for instance setting the timeout on a socket:
> >
> >try {
> >  socket.setSOTimeout(TOO_LONG);
> >  //blocking read from socket stream
> >  //...
> >} finally {
> >  cleanup();
> >}
> >
> >Dhanji.
> >
> >
> >On 15 Dec 2006 23:03:12 -0000, Chirag Shah <chirag_r_shah at rediffmail.com>
> >wrote:
> >>
> >>  Hi,
> >>
> >>I am new to TPE. I have a question.
> >>
> >>I have a Multithreaded Java Application running on SunOS Sparc.
> >>Which open a socket connection, get the request and pass it to the
> >>worker.  The worker will read/write the file and send the data back to
> the
> >>client. Rightnow we have setting of min 300 Thread and max 1000 Thread.
> >>
> >>My basic requirement is, if a thread takes more than couple of sec eg 5
> >>seconds, I want that thread to stop doing the task, ie terminate that
> >>request and start serving other requestm, which is in the queue. b'cos
> that
> >>single task may hung my whole application. I can kill a single request
> >>rather than killing the whole application.
> >>
> >>Would you please give me the best idea?
> >>
> >>Thanks.
> >>
> >>
> >>
> >><
> http://adworks.rediff.com/cgi-bin/AdWorks/sigclick.cgi/www.rediff.com/signature-home.htm/1507191490@Middle5?PARTNER=3
> >
> >>_______________________________________________
> >>Concurrency-interest mailing list
> >>Concurrency-interest at altair.cs.oswego.edu
> >>http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> >>
> >>
> >>
>
>
> <http://adworks.rediff.com/cgi-bin/AdWorks/sigclick.cgi/www.rediff.com/signature-home.htm/1507191490@Middle5?PARTNER=3>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20061219/703fa634/attachment.html 


More information about the Concurrency-interest mailing list