Re: RMI cleanup

Sorry, I forgot to mention that this will only help on the client side, but
it would still be interesting to see if this has any affect on the server...
i.e. does this in any way stop it from being slowed down. Perhaps there is a
relationship between client-side blocking threads and server side garbage
collection... but I'm just guessing (and at a guess, I doubt there would be
a relationship).

I also don't know how many calls you are meant to make to the remote server
just to do a lookup. Perhaps you might want to try not setting the remote
reference back to null (if it is in fact still usable)?

I guess it might just come down to the fact that you are repeatedly
requesting references to a remote server (and then discarding them), and it
might take a while for the server itself to determine that the references
are not being used (setting the reference to null on the client side won't
affect the server side GC unless there is some serious RMI magic going on
under the hood).

One slight thing that doens't add up... if a host not found error was being
thrown, and this was the client reporting that it can't find the server,
then the server can't have been under any load at all. What am I missing
here? If the error was a remote error (meaning that the server upon excuting
the RMI method hit an additional lookup error), then I guess it explains
things... I then go back to my first point... you are probably just swamping
the server with too many lookup requests.

Have you run some GC profiling tools on the server to see how often is is
sweeping, and how far it gets per sweep? This might give you some more
information too.

2009/4/30 Carl Cook <[email protected]>

> Hi,
>
> I am not sure what RMI is doing (or not doing)... or for what matter the
> Java GC is up to, but your approach will probably benefit by refactoring the
> threading code slightly.
>
> At present, for each client, you have a thread in a busy wait loop.
> Regardless of the number of processors available, this is going to be
> problematic from a scalability aspect.
>
> Have you considered instead of sleeping to wait on a signalled object?
>
> You could, for example, try this:
>
> private object waitObject = new Object();
>
> catch (Exception ex)
> {
>   synchronized(waitObject)
>   {
>      waitObject.wait(1000);
>   }
> }
>
> A good primer is here:
> http://tutorials.jenkov.com/java-concurrency/thread-signaling.html
>
> The java concurrency/threading tutorials are also very good.
>
> As for having thread handling code in an exception handler, this is quite
> interesting as well, and perhaps could be avoided.
>
> It would be interesting to refactor your code and then see if you even run
> into these problems again.
>
> I hope this helps!
>
> --
> Carl
>
>
> 2009/4/30 mvanr <[email protected]>
>
> I recently had a problem where a dual quad-core xeon was brought to its
>> knees
>> and this was traced back to RMI clients experiencing an io exception, and
>> repeatedly retrying the operation every second.  Here's the code:
>>
>> while (true) try
>> {
>>        if (remote == null) try {
>>                remote = (T)Naming.lookup(serviceName);
>>        }
>>        catch (Exception ex) {
>>                throw new RemoteException(ex.getClass().getName() + ": " +
>> ex.getMessage());
>>        }
>>        op.exec(remote);
>>                return;
>> }
>> catch (IOException ex) {
>>        remote = null;
>>        Thread.sleep(1000);
>> }
>>
>> The call to naming lookup was succeeding. The call to op.exec just
>> translates to a call of a method on the remote object, and that was
>> throwing
>> a host not found exception due to a misconfiguration on the server.
>>
>> I would have expected the discarded remote objects to be cleaned up
>> shortly
>> after the exception, but it seems that they are not.  What's worse is that
>> they continue to consume CPU.  Half a dozen of these java programs caused
>> the load on the server to get close to 1000.
>>
>> Does anyone know how best to avoid this?  I would prefer an in-code
>> solution
>> to a command line argument to java, since the latter could always be
>> forgotten.
>>
>> Thanks.
>> --
>> View this message in context:
>> http://www.nabble.com/RMI-cleanup-tp23310928p23310928.html
>> Sent from the Java - RMI mailing list archive at Nabble.com.
>>
>>
>> ===========================================================================
>> To unsubscribe, send email to [email protected] and include in the
>> body
>> of the message "signoff RMI-USERS".  For general help, send email to
>> [email protected] and include in the body of the message "help".
>>
>> For a list of frequently asked RMI questions please refer to:
>> http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html
>>
>> To view past RMI-USERS postings, please see:
>> http://archives.java.sun.com/archives/rmi-users.html
>>
>
>

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff RMI-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

For a list of frequently asked RMI questions please refer to:
http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html

To view past RMI-USERS postings, please see:
http://archives.java.sun.com/archives/rmi-users.html