Re: Turn off dgc

> When calling methods in our client wich invoke many RMI calls
> consecutively, every so often our client hangs between one and five
> minutes. According to our logs this happens about once per day per
> user. In our test environment we have found a way to reproduce this
> behaviour. It takes a few tries but eventualy we have a situation
> where our java client has to wait for a minute or longer for our
> server to respond when this type of call usually only takes
> fractions of a second.
>
> So what is happening? We took a look at what packets which were
> being sent between the server and the client, and we found the
> following pattern:
> 1. Just before we make our rmi call, there is a dgc call being made
> between client port 3333 and server port 4444.
> 2. Client sends rmi call from port 3333 to server at port
> 4444. Server responds with an ACK package (no data).
> 3. No communication for about a minute.
> 4. The client sends an rmi admin/dgc call from a different client
> port say 3335 to the same server port 4444. After this call is made,
> the original rmi call is returned from server port 4444 to client
> port 3333.

It would seem very helpful to see thread dumps[*] of the client and
server VMs during this hanging.

> While it is of course obvious to find out what is going on on the
> server side, we would also like to check, even if only for test
> purposes, what effect it would have if we could turn off the dgc.

[and from your first message:]
> I was wondering whether there is any flag or other possibility to
> turn of dgc. In particular I want to avoid the clean up threads
> checking for lease expirations etc.

With the J2SE RMI API or its current implementation, there is no way
to disable DGC activity altogether.  Increasing DGC lease durations
(see the "java.rmi.dgc.leaseValue" system property) would reduce the
DGC lease renewal traffic correspondingly, but I'm not sure that
that's what you're getting at.

My guess about the above list of events is that a remote reference to
remote object -A- is being deserialized or unmarshalled somehow (like
as part of the return value of a prior remote invocation), and a
remote invocation is made to -A- (steps 2-4), which returns a remote
reference to -B-, a different remote object on the same server host.
The DGC dirty call of step 1 is to inform the server that the client
VM now has a live reference to -A-, and the DGC dirty call of step 4
is to inform the server that the client VM now has a live reference to
-B-, which happens synchronously before the remote invocation returns.
The "hang" of step 3 seems to occur during the server-side processing
of the remote invocation, but again, thread dumps would seem very
helpful in determining that for sure.

-- Peter

[*] On Solaris and Linux, you can get a thread dump by sending a QUIT
signal to the VM's process (such as with "kill -QUIT" or by invoking
Control-\ in a shell with the process in the foreground).  On Windows,
you can get a thread dump by pressing Control-BREAK in the window for
the VM's process.

===========================================================================
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