Re: problem w/ serialization of java.rmi.Remote pointer across HTTP through firewall

Bob,

> Have you tried generating a thread dump of the
> client
> during the pause? Sounds like the hangup could be
> with
> DGC, trying to make a dirty call back to the server.

I haven't done that, however I can tell you that while
the client is waiting, very few packets are being
sent. I.e. it sure looks like the client is doing
fine, but something is causing the packets to come out
as a trickle. I assume it's the firewall, because in a
local config, this problem does not exist. Granted,
the local config is running XP and the prod cluster is
Linux.

> How
> do the hostname/address and socket factory in the
> returned
> stub relate to the ones in the original stub you're
> making
> the call through?

I don't think I understand your question. In this case
where we have problems, no original stub is used on
the local client. It uses a service address that is
described by a String, similar to a URL String. The
local client detects that the call is a "proxy" call
because the service address has a defined proxy URL,
and dispatches the request using an ObjectOutputStream
to that URL, which in this case is a servlet running
in Tomcat. The proxy servlet deserializes the request,
then dispatches it as if the servlet was the
originating, local client (in fact, it uses the same
client object for communication that the local client
uses, only now it is being executed within the local
net of the cluster). After the servlet receives a
response, it write the response object back down the
ObjectOutputStream derived from the
HttpServletResponse. It all works perfectly unless the
response object contains any Remote references...then
it takes forever for the client to receive the
response. And while the local client is waiting for
its response, as far as the servlet is concerned, it's
done and all the data is written, while the local
client receives packets onesey-twosey for an
unreasonable amount of time.

> Do subsequent calls by the client
> through
> the returned Remote reference work correctly,
> without delay?

Yes. However, I have not tried doing a subsequent call
that returns arrays of Remote references as the
response. I assume it would have the same problem.

A typical messaging model is to first make a Directory
call to get an array of services (Remote references)
that can respond to a particular request type. Then we
decide which one to use (usually the first one in the
returned array, since the Directory services will
shuffle these arrays for load balancing purposes), and
send our request to that service.

Normally, all these calls occur within the local net
of the cluster, and there is no problem anywhere. But,
mainly for reasons of being able to run a decent
debugger, we now want to run services locally that
take part as a peer in the distributed computing
infrastructure that's behind the firewall.

And as I said, it all works except that when I do a
Directory query that returns any Remote references, it
takes seemingly forever to get the data back. Once I
have a valid array of remote references, I've been
able to execute hundreds of calls to those references
via the http proxy. But as I said, the results of all
those calls were not Remote references. They were
other objects.

Through testing, I was able to deteremine that only
remote references cause this problem, and the problem
seems to only happen one way, i.e. when the remote
reference originates within the firewall and has to go
to the outside world. When I send the same Remote
reference back out as a paramter to my proxied call,
there is no delay at all.

Once again, any insight would be appreciated. I have a
nasty hack of a solution, but it would be so much
better to just be clean and work correctly.

Regards,

George




Discover Yahoo!
Use Yahoo! to plan a weekend, have fun online and more. Check it out!
http://discover.yahoo.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