I don't know about the time-out. Dial-up could be a factor.
Just to add a little more background to what I think is happening...
When the app client container (ACC) starts up it contacts the server-side ORB using the IIOP endpoint(s) provided to it. If you launch using the appclient command the endpoint(s) come from the sun-acc.xml file. If you launch using Java Web Start the endpoint(s) come from the server and are assigned in the generated JNLP document that starts the client.
This initial contact is for "bootstrapping" the connection from the client ORB to an ORB on the back-end. Once this initial connection is made the ORB on the client side and the ORB on the server side exchange information about other ORBs in the same cluster as the one contacted initially. (If the server is not in a cluster then the client will not do any ORB fail-over or load balancing to the back-end.)
Also, the server-side ORB provides the client-side ORB with, essentially, network addresses where the remote EJBs and other resources can be reached. I think that this is where the problem with servers behind NAT firewalls comes in. The server-side ORB, in figuring out those addresses, uses the ORB settings in the configuration for the server (stored in domain.xml and settable using the admin GUI). These are defaulted to 0.0.0.0, and for a server behind a NAT firewall 0.0.0.0 gets translated to the servers's private LAN address, which of course are meaningless for the client which lies outside the firewall.
Florian's point is that by setting the ORB-related values in the server's configuration explicitly you can avoid the translation to the local, private address. Instead the ORB will use the value you set in the configuration.
Florian's further suggestion in his post is to create a DNS entry for the router using the router's outside address (a.b.c.d, not 192.168.x.y), set up address mapping in the router/firewall so requests to the GlassFish ports (including the ORB ports) are forwarded to the server, and specify the DNS name (instead of the default 0.0.0.0) in the GlassFish ORB configuration. I would think another way to do this, at least as a test, would be to use the public numeric IP address of the router in the GlassFish ORB settings. That avoids the need to create the DNS entry but obviously makes your configuration dependent on the numeric a.b.c.d address. If that is assigned dynamically (DHCP) then that is not very appealing. But people in this situation could try that as an experiment to see if that avoids the problem, at least until the router's outward IP address is changed.
I hope this helps explain what's going on.
- Tim
[Message sent by forum member 'tjquinn' (tjquinn)]
http://forums.java.net/jive/thread.jspa?messageID=289787