..
> Given below is the stack trace of our application ..
*
>..that connects to a
> server. This application creates multiple threads. Each thread
[quoted text clipped - 5 lines]
>
> http://www.boutell.com/javaclass/talk/Client.java
..
public class Client extends Applet implements Runnable
* To be specific, that is not an application,
but an applet. Applets can suffer extra
problems due to the VM's interaction with/
control by the browser.
I suggest you launch the applet using ..
a) web start or
b) another browser
..and see if that sorts the problem.
Andrew T.
rajatag - 19 Feb 2007 13:52 GMT
> public class Client extends Applet implements Runnable
>
[quoted text clipped - 9 lines]
>
> Andrew T.
We're running this as a console application, the only code used from
the other side is the transmission of messages for sockets (i.e. the
input / output thread concept).
Thanks!
Rajat
> After sometime, the threads start to lockup and no data is sent to the
> server. It would be great if anyone can figure out something from the
> stack trace below. In the stack trace below, only one out of 19 total
> clients was active.
The stack trace seems to have come from the server process, and it doesn't
really say a lot without the server code. If the problem is all in the client
then a client stack trace would be more informative.
Anyway, looking at the client code, I have a couple of comments, I don't know
whether they relate to your problem.
In your client code, when you have called flushOutputStrings() and before you
call wait(). you should flush() outputStream or the data probably won't be sent
off to the server. (You may have similar problems in the server too. If so
then that's a great way to make a client/server application deadlock itself --
client and server both think that they've sent data off to the other, so they
both wait for a response, but no data has actually been sent so nothing more
ever happens...) BTW: your code doesn't use buffering around the
SocketStreams -- that will actually reduce the chance of a problem caused by
the lack of flush()es, but will also make your application run slowly and put a
bigger load on the network than it should.
I could be wrong, but there seem to be a few places where you are updating the
GUI from one of your background threads -- you are not supposed to do that:
Swing code (with a very few exceptions) must only run on the EDT.
Your code relies on outputStings being a Vector, and thus having synchronised
methods. I can't see anything that you are doing that is wrong (but I may
easily have missed something), but it does make it harder to see /whether/ the
code is correct if the synchronisation is sometimes explicit, and sometimes
implicit. What makes it even harder to follow is that only /some/ of Vector's
methods are actually safe -- the ones it inherits from AbstractList typically
are not (e.g. addElement(Object) is safe, but add(Object) is not).
It's not usually a good idea to catch and ignore exceptions (even ones that
don't matter or "can't happen"). That's /especially/ true when you are trying
to find out why the program doesn't work !
Lastly: never use Thread.stop() -- it's deprecated for very good reason (see
the JavaDoc).
-- chris
P.S.
inputThread = new Thread(this);
outputThread = new Thread(this);
inputThread.start();
outputThread.start();
Weird !
rajatag - 20 Feb 2007 00:48 GMT
On Feb 19, 9:38 pm, "Chris Uppal" <chris.up...@metagnostic.REMOVE-
THIS.org> wrote:
> > After sometime, the threads start to lockup and no data is sent to the
> > server. It would be great if anyone can figure out something from the
[quoted text clipped - 4 lines]
> really say a lot without the server code. If the problem is all in the client
> then a client stack trace would be more informative.
This is the client stack trace. It is a console based client.
> Anyway, looking at the client code, I have a couple of comments, I don't know
> whether they relate to your problem.
[quoted text clipped - 9 lines]
> the lack of flush()es, but will also make your application run slowly and put a
> bigger load on the network than it should.
I have tried flushing but it still gave the same problem.
> I could be wrong, but there seem to be a few places where you are updating the
> GUI from one of your background threads -- you are not supposed to do that:
> Swing code (with a very few exceptions) must only run on the EDT.
GUI code from the original source has been removed.
> Your code relies on outputStings being a Vector, and thus having synchronised
> methods. I can't see anything that you are doing that is wrong (but I may
[quoted text clipped - 3 lines]
> methods are actually safe -- the ones it inherits from AbstractList typically
> are not (e.g. addElement(Object) is safe, but add(Object) is not).
This works fine in another application so we're sure its not the
portion creating a problem.
Basically it seems that it's a timer issue because when there is
continuous activity on the client, it never hangs. But as soon as
there is reduced activity it starts hanging up ... Do you think a
timer can block the socket when we add to outputStrings Vector from
within the timer?