I've spent several days battling against Glassfish, VirtualBox and Linux guest OS network configurations in order to get our rich client working against Glassfish behind a NAT firewall.
We are running Glassfish version: Sun Java System Application Server 9.1_02 (build b06-p02)
The domain is set up using --portbase=2000, so it is using the following ports:
2037, 2038, 2039, 2048, 2080, 2081, 2086
The environment consists of a Windows XP host OS running VirtualBox.
The Guest OS is Linux (RedHat 5.2), configured for NAT networking. It represents the server machine and runs Glassfish plus a database.
For development purposes, the following ports are forwarded from host back to guest:
21,22,23,1521,8097,9009,9090,9085
2037,2038,2039,2048,2076,2080,2081,2086
(in a production scenario the intention would be to expose only the 20xx ports)
This set-up is intended to provide two things:
(a) A -pre-configured environment for developers, so each can have their own database and Glassfish Server that may be refreshed occasionally from a "master" copy (simply by copying the appropriate .vdi disk images)
(b) A realistic simulation of a typical deployment on the WAN. Glassfish would be behind a firewall on a private network, and only certain ports will be available. The client cannot expect to be able to connect at will using something chosen at random.
The server has IP address 10.0.2.15, which is "hidden" from the client by NAT. The server can connect "out" as will, but the client can only connect "in" on the forwarded ports.
The initial problem was that when the client launched (either via web-start, or diectly from Eclipse), the IIOP set up by the server seemed to be "advertising" connection addresses using the private server address.
The client is being started using:
<property name='org.omg.CORBA.ORBInitialHost' value='localdev01'/>
<property name='org.omg.CORBA.ORBInitialPort' value='2037'/>
Consequently I got this stack trace when connecting:
18-Dec-2008 12:40:59 com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl <init>
WARNING: "IOP00410201: (COMM_FAILURE) Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: 10.0.2.15; port: 2037"
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No
at com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2690)
at com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2711)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:261)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:274)
at com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:130)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:192)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:181)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:325)
at org.omg.CORBA.portable.ObjectImpl._is_a(Unknown Source)
at org.omg.CosNaming.NamingContextHelper.narrow(Unknown Source)
at com.sun.enterprise.naming.SerialContext.narrowProvider(SerialContext.java:131)
at com.sun.enterprise.naming.SerialContext.getCachedProvider(SerialContext.java:247)
at com.sun.enterprise.naming.SerialContext.getRemoteProvider(SerialContext.java:205)
at com.sun.enterprise.naming.SerialContext.getProvider(SerialContext.java:160)
at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:398)
at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:445)
at javax.naming.InitialContext.lookup(Unknown Source)
...
Subsequently (in this post:
http://forums.java.net/jive/thread.jspa?messageID=217837 )
I discovered that the workaround is to change the address that IIOP listens on, from "0.0.0.0" to the hostname of the server.
"Outside" i.e. in the hosts file of the Windows machine (C:\windows\system32\drivers\etc\hosts) I added an entry for that name, mapping it to 127.0.0.1.
127.0.0.1 localdev01.mycompanydomain.com localdev01
I'm now up against a dead-end - the rich client launches and makes its initial lookup() connection successfully, but next tries to set up a JMS listener.
For some reason it thinks that it can use a random port for this and I get:
18-Dec-2008 13:03:32 com.sun.messaging.jms.ra.ResourceAdapter start
INFO: MQJMSRA_RA1101: SJSMQ JMS Resource Adapter starting...
network: Connecting socket://localdev01.mycompanydomain.com:2076 with proxy=DIRECT
network: Connecting socket://localdev01.mycompanydomain.com:64944 with proxy=DIRECT
18-Dec-2008 13:03:33 com.sun.messaging.jmq.jmsclient.ExceptionHandler throwConnectionException
WARNING: [C4003]: Error occurred on connection creation [localdev01.mycompanydomain.com:64944]. - cause: java.net.ConnectException: Connection refused: connect
... [ the above 4 lines repeated 8 times ] ...
18-Dec-2008 13:04:21 com.sun.messaging.jms.ra.ResourceAdapter start
SEVERE: MQJMSRA_RA4001: start:Aborting:JMSException on createConnection=[C4003]: Error occurred on connection creation [localdev01.mycompanydomain.com:64944]. - cause: java.net.ConnectException: Connection refused: connect
com.sun.messaging.jms.JMSException: [C4003]: Error occurred on connection creation [localdev01.mycompanydomain.com:64944]. - cause: java.net.ConnectException: Connection refused: connect
at com.sun.messaging.jmq.jmsclient.ExceptionHandler.throwConnectionException(ExceptionHandler.java:274)
at com.sun.messaging.jmq.jmsclient.ExceptionHandler.handleConnectException(ExceptionHandler.java:220)
at com.sun.messaging.jmq.jmsclient.protocol.tcp.TCPConnectionHandler.<init>(TCPConnectionHandler.java:151)
at com.sun.messaging.jmq.jmsclient.protocol.tcp.TCPStreamHandler.openConnection(TCPStreamHandler.java:135)
at com.sun.messaging.jmq.jmsclient.ConnectionInitiator.createConnection(ConnectionInitiator.java:778)
at com.sun.messaging.jmq.jmsclient.ConnectionInitiator.createConnectionNew(ConnectionInitiator.java:254)
at com.sun.messaging.jmq.jmsclient.ConnectionInitiator.createConnection(ConnectionInitiator.java:208)
at com.sun.messaging.jmq.jmsclient.ConnectionInitiator.createConnection(ConnectionInitiator.java:158)
at com.sun.messaging.jmq.jmsclient.ProtocolHandler.init(ProtocolHandler.java:807)
at com.sun.messaging.jmq.jmsclient.ProtocolHandler.<init>(ProtocolHandler.java:1509)
at com.sun.messaging.jmq.jmsclient.ConnectionImpl.openConnection(ConnectionImpl.java:2280)
at com.sun.messaging.jmq.jmsclient.ConnectionImpl.init(ConnectionImpl.java:1012)
at com.sun.messaging.jmq.jmsclient.ConnectionImpl.<init>(ConnectionImpl.java:414)
at com.sun.messaging.jmq.jmsclient.UnifiedConnectionImpl.<init>(UnifiedConnectionImpl.java:60)
at com.sun.messaging.jmq.jmsclient.XAConnectionImpl.<init>(XAConnectionImpl.java:58)
at com.sun.messaging.XAConnectionFactory.createXAConnection(XAConnectionFactory.java:91)
at com.sun.messaging.XAConnectionFactory.createXAConnection(XAConnectionFactory.java:69)
at com.sun.messaging.jms.ra.ResourceAdapter.start(ResourceAdapter.java:491)
at com.sun.enterprise.connectors.ActiveInboundResourceAdapter$1.run(ActiveInboundResourceAdapter.java:135)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.enterprise.connectors.ActiveInboundResourceAdapter.<init>(ActiveInboundResourceAdapter.java:131)
at com.sun.enterprise.connectors.system.ActiveJmsResourceAdapter.<init>(ActiveJmsResourceAdapter.java:248)
at com.sun.enterprise.connectors.ActiveRAFactory.createActiveResourceAdapter(ActiveRAFactory.java:107)
at com.sun.enterprise.connectors.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:300)
at com.sun.enterprise.connectors.ConnectorRuntime.createActiveResourceAdapter(ConnectorRuntime.java:207)
at com.sun.enterprise.naming.factory.AdministeredObjectFactory.getObjectInstance(AdministeredObjectFactory.java:102)
at javax.naming.spi.NamingManager.getObjectInstance(Unknown Source)
at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:403)
at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:445)
at javax.naming.InitialContext.lookup(Unknown Source)
...
The port 64944 is only an example, it changes at random, right now it's trying 14071
There must surely be some way to make JMS understand when it's running in a more restrictive environment? What we're trying to achieve here is surely not impossible?
I've no hair left, any clues would be much appreciated.
Thanks
Ed
[Message sent by forum member 'edrandall' (edrandall)]
http://forums.java.net/jive/thread.jspa?messageID=322368