Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Testing client crashes

 
Ricardo Estafan
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello all,

this is not supposed to be a discussion on what to do with client crashes.
I have implemented a LockManager and in it i remove dead clients on certain occassions. Her is a piece of my code that shows how i do this :



I use eclipse to build debug etc. When i start multiple clients and kil one they have the same Thread, which means the thread is still alive. So i cannot test the removal of dead clients. Can someone help me with this one?!!

Thanks!!
 
Hanna Habashy
Ranch Hand
Posts: 532
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi Ricardo:
You need to start each client in different VM. For example, from the command prompet you can launch the server. Then, open a new command prompet window for each client, launch the client then test.
I used this technique to test my server and locking.
 
Ricardo Estafan
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does anyone know hot to accomplish this in Eclipse? I tried to start Eclipse two times, this isnn't possible. Or else how can i debug when i start the application from the command line?

Thanks!!
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 11888
203
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ricardo,

I assume you are using RMI (since if you were using sockets, you would be creating the threads yourself, and this issue wouldn't even arise).

However you cannot use the thread number within RMI as a client identifier. According to the Sun RMI Specification:


A method dispatched by the RMI runtime to a remote object implementation may or may not execute in a separate thread. The RMI runtime makes no guarantees with respect to mapping remote object invocations to threads. Since remote method invocation on the same remote object may execute concurrently, a remote object implementation needs to make sure its implementation is thread-safe.


The behaviour you described is allowable under the specification, even if each of your clients was working on a separate computer (so 3 computers / 3 JVMs).

It is also quite possible that with only one client connected, it's call to lock() could be handled by one thread, it's call to update() could be handled by a different thread, and it's call to unlock() could be handled by a third thread!

This is why we generally recommend using a connection factory on your server if you want to handle client death scenarios. It is one of the simpler ways to handle this.

Regards, Andrew
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic