• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: how to pass exceptions from one thread to another?

 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone,
I'm referring here to this thread.
Like I have described in this thread I have in my RoomServer Class a second thread running which notifies regularly my WeakHashMap:

Due to prior discussion in another thread and in the one mentioned above (thanks Phil) I have changed my general Exception-clause to InterruptedException-clause. But now I have a problem how to deal the RuntimeExceptions.
Like Phil mentioned, if a RuntimeException occurs, only the thread in which this exception occured, will be destroyed. The main thread, started from my Server GUI, will still be running.
So I want to alert the User that something in my refreshThread went wrong.
How can now my main Thread get an exception from my refreshThread to be able to show an appropriate message to the User?
Thanks in advance
Ulrich
[ January 12, 2004: Message edited by: Ulrich Heeger ]
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How can now my main Thread get an exception from my refreshThread to be able to show an appropriate message to the User?
A standard way of doing it is to pass a reference from the controlling code to the thread in question. When an exception is thrown, you simply catch it in the thread and notify the control code by calling some method using the reference.
With that said, I am not very excited aboout your idea of the "refresh" thread, or about its implementation. It looks like your refresh thread will waste a [/i]lot[/i] of CPU cycles because of its tight and busy loop. But even if you fixed it, I am questioning the need for it. Is the purpose to clean after the dead clients? Seems like a lot of trouble (coupled with the WeakHashMap), and a very customized way of doing distributed GC.
I noticed that as new developers come in to get certified, they set new trends and fashions in the developer's assignment. I got some 98% score in my certification result, and I didn't have any way of handling the dead locks/client. But then somebody must have said that you will surely fail without it, and that fear is there ever since.
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Eugene,
thanks for your reply.
A standard way of doing it is to pass a reference from the controlling code to the thread in question. When an exception is thrown, you simply catch it in the thread and notify the control code by calling some method using the reference.

Sounds

With that said, I am not very excited aboout your idea of the "refresh" thread, or about its implementation. It looks like your refresh thread will waste a [/i]lot[/i] of CPU cycles because of its tight and busy loop. But even if you fixed it, I am questioning the need for it. Is the purpose to clean after the dead clients? Seems like a lot of trouble (coupled with the WeakHashMap), and a very customized way of doing distributed GC.

Yes, my refresh thread shall notify a client which is waiting to death to get the lock of the WeakHashMap owned by a dead client. But maybe you're right and I'm making to much trouble for something what is beyond the scope.

that fear is there ever since

You're right, further I'm working through the assignement, further I'm afraid not to take in consideration certain things
Regards
Ulrich
 
Bharat Ruparel
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Ulrich,
I agree with Eugene. I didn't get anywhere close to his score but 92% is not bad either. I DID NOT take care of the dead-client issue, i.e., I did not implement the "Unreferenced" interface. I got full points on network, data-server, and locking. My two cents, just mention in your choices.txt file that you are aware of the issue but chose not to implement it since it is out of scope for this assignment.
Regards.
Bharat
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bharat,
thanks for your help.
I can remember that you have also implemented a WeakHashMap with Data.this-reference, but without this supplement thread with which I try to complicate my whole application;.)?
Greetings
Ulrich
 
Bharat Ruparel
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Ulrich,
You wrote:

I can remember that you have also implemented a WeakHashMap with Data.this-reference, but without this supplement thread with which I try to complicate my whole application;.)?

That is correct. I did not implement the supplemental thread that you are mentioning above.
Regards.
Bharat
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Eugene,
Eugene:
It looks like your refresh thread will waste a [/i]lot[/i] of CPU cycles because of its tight and busy loop.

The code posted by Ulrich above is a little misleading. If you follow the first link he mentions, you'll see that there is a sleep(50000) in the refresh() method.
BTW Ulrich, this is *really* misleading. If you keep that solution, I think you'd better move the sleep() to the main loop of the run() method.
And if you keep the feature of client crashes detection through a WeakHashMap, the issue of the lack of notification may be solved in a more efficient way (Andrew's solution). I compared it with a solution based on the use of WeakReferences in a regular HashMap here.
Eugene:
I noticed that as new developers come in to get certified, they set new trends and fashions in the developer's assignment. I got some 98% score in my certification result, and I didn't have any way of handling the dead locks/client. But then somebody must have said that you will surely fail without it, and that fear is there ever since.

You're right, but... Anyway, here is what I think about that (posted recently) :
Instructions:
---
This document deliberately leaves some issues unspecified, and some problems unraised. Your ability to think through these issues, in the face of realistically imperfect specifications, and come to a tenable solution is something upon which you are being graded.
---
Phil:
So it's obvious that SUN expects a little more than all "MUST-BE". It's OK to document those issues, but implementing *a few* of them cannot hurt IMO. And BTW, what means the "coming with" above ?
Now if *you* decide to *solve* a few of those issues ("solving" meaning pointing them out *and* implementing a solution), you'll have to make a *personal choice* about which to solve among all possible ones (the other ones simply being mentioned in choices.txt). That's why I think that telling here something like : "Forget that issue, I didn't take it into account and I got a high score" is not a valid argument.
Anyway, we'll be graded by human beings. With a "MUST-BE-ONLY" development, it's possible that your grader thinks "Great ! The shortest assignment I ever saw, I'll save time with that guy !" and that you get a high score thanks to that. The same grader on another mood (or another grader), could "Mmh... This guy really did the minimum in all areas" and ... (I let you guess ).

So you may decide to handle crashed clients elegantly, or not. It's just *one* possible "nice feature" amongst so many others. But *IF YOU DO*, it must *WORK PERFECTLY*. In other words, using a WeakHashMap for locks, with the aim to handle crashed clients, but *without* solving the lack-of-notification issue is worse than simply forgetting the whole problem.
Now Ulrich, your way of doing is correct. But you just perform a probably useless notifyAll() every 50 seconds, while it's possible (Andrew's solution) to make just a useful (only when needed) notifyAll() with a much smaller delay (1 second for instance).
Best regards,
Phil.
[ January 12, 2004: Message edited by: Philippe Maquet ]
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Phil, hi Eugene, hi Bharat,
thanks for your help. Now I don't know what to do
You three have convinced me on your own, oh, always these decisions
Phil, you wrote:

BTW Ulrich, this is *really* misleading. If you keep that solution, I think you'd better move the sleep() to the main loop of the run() method.

You're right, if I keep this thread I should move the sleep().
Eugene, you wrote:

A standard way of doing it is to pass a reference from the controlling code to the thread in question. When an exception is thrown, you simply catch it in the thread and notify the control code by calling some method using the reference.

Can you or somebody else perhaps give me a short code example?
Thanks in advance
Ulrich
[ January 13, 2004: Message edited by: Ulrich Heeger ]
[ January 13, 2004: Message edited by: Ulrich Heeger ]
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone,
I have found an interesting article concerning exception handling for multithreading.
Greetings
Ulrich
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic