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

George Ludwig <[email protected]>
Newsgroups gmane.comp.java.sun.rmi
Message-ID <[email protected]>
I built an HTTP proxy servlet to enable a local rmi
app to communicate to a computing cluster on the other
side of a Cisco Pix firewall. It works, with one
caveat: if the local client makes a request whose
return type includes a java.rmi.Remote reference, it
takes literally 20 seconds to receive the data back
from the proxy. This is bad enough for a response
object with a single java.rmi.Remote reference. But
some of the requests are Directory-style requests,
that could return hundreds of these references in a
single response.

It's confirmed that it's not a data volume issue (each
of these references takes around 1K). Also, sending
the java.rmi.Remote reference INBOUND to the firewall
as a parameter to a different client request does not
cause any delays.

If I run the proxy under tomcat on my local WinXP
machine, no transmission delays occur.

I suspect the delay has something to do with the Pix
firewall sniffing the outgoing packets (with its
"Adaptive Security" algorithm), but I don't have  any
experience in this area.

Has anyone had a similar experience? Any ideas on what
could be causing the slowdown?

Regards,

George



__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail

===========================================================================
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.