Java RMI

[imported_Ned Flanders]

Hello folks. Annoying problem I am having:

I have a client::server application connected via RMI, the problem is if the client calls a remote method, and the server needs to then call a remote method on the client inside the original method call from the client (I hope that makes sense ) - The client just crashes.

Any idea why?

I'm guessing it is because the client is waiting for a response from the server.
Would creating a thread for the original call allow the client to respond to the server (I have literally just thought of that now)

 

[kamper]

How about a stack trace?

 

[imported_Ned Flanders]

My apologies - I do not know how to get a stack trace as the program just freezes. I have managed to overcome this problem anyway (Seems like a bug in BlueJ as everything is ok with a .jar file), although I have a new problem.

Regarding thread, I was under the impression that when a thread is run() the code beneath it is run straight away and the thread does it's buisness.

ie.

method call{
code
long task (in thread)
code
}

would mean that, no matter how long the task takes (in my case 7 seconds using a Thread.sleep() call), the method would finish as fast as it could?

I hope I am making sense.

Edit: The way I am making a thread is :

 

[imported_Ned Flanders]

bump!

 

[6000SUX]

You should state what your new problem is.

 

[imported_Ned Flanders]

hahaha - I'm an idiot. I'll remember that for next time

Anyway, I fixed my second problem. Next time I have a problem, I won't post here without having a 2 minute think before hand!

Sorry guys.

 

[mundane]

And I believe the preferred way to begin execution of a new Thread instance is to call the start() method, not run(). Maybe attach the code for your method, I'm not quite sure I understand.

 

[imported_Ned Flanders]

Yep, I ended up calling the start method.

Edit: Like I said, it's all fixed now. I'm going to be releasing the source for my program soon on a number of forums. It's just a crappy chat program.

 

[6000SUX]

In general I don't like unnecessarily funky syntax, and here I probably wouldn't use an anonymous inner class that way. I haven't done Java in a couple of years, so refresh my memory: what happens if your thread doesn't cause another object to hold a reference to it, and gets garbage collected? I'm pretty sure that's a recipe for badness.

 

[mundane]

Originally posted by: 6000SUX
In general I don't like unnecessarily funky syntax, and here I probably wouldn't use an anonymous inner class that way. I haven't done Java in a couple of years, so refresh my memory: what happens if your thread doesn't cause another object to hold a reference to it, and gets garbage collected? I'm pretty sure that's a recipe for badness.

I think that by invoking the start() method, it's added to a queue/some other data structure for execution by the JVM. That reference prevents it from being gc'ed. Once the run() method is completed, the memory can be reclaimed.

 

[6000SUX]

Originally posted by: diegoalcatraz

Originally posted by: 6000SUX
In general I don't like unnecessarily funky syntax, and here I probably wouldn't use an anonymous inner class that way. I haven't done Java in a couple of years, so refresh my memory: what happens if your thread doesn't cause another object to hold a reference to it, and gets garbage collected? I'm pretty sure that's a recipe for badness.

I think that by invoking the start() method, it's added to a queue/some other data structure for execution by the JVM. That reference prevents it from being gc'ed. Once the run() method is completed, the memory can be reclaimed.

You're right! Thanks for the info.

 

[imported_Ned Flanders]

I don't want a reference to be kept to it. The thread was to a handle a popup window when a user logged it (ala MSN Messenger) and dispose it after a set number of seconds.