I've continued working on this without success. Here's what I've done:
JBoss and JBossMQ is running on my computer at work. The client works fine. I then put the client on my home computer (both computers are connected to the internet with DSL, and both have simple Barricade firewalls). It doesn't work at home. I opened up all the ports I could find in the JBoss config files, including 1099, 4444, 8090, and 8091. I did this for both computers. It still doesn't work. Here is the line of code and the exception:
TopicConnectionFactory topicConnectionFactory = (TopicConnectionFactory) jndiContext.lookup("ConnectionFactory");
javax.naming.CommunicationException: Receive timed out. Root exception is java.
net.SocketTimeoutException: Receive timed out
at java.net.PlainDatagramSocketImpl.receive(Native Method)
Again, this client works perfectly 100% of the time when I run it on the same computer as the server. I'm sure this is related to the firewall / NAT. Unfortunately I can't disable this at work to prove it.
If anyone has any ideas on getting this to work I'd greatly appreciate it.
Yes, it is possible. That is what you have to do:
1) Punch two whole in your firewall for an unused port
2) Set the RmiPort in the JNDI server (service.xml file int the conf directory) by using the first whole
2) Specify the ServerBindPort in the UILServerILService (jbossmq-service.xml in the deploy directory) with the second whole)
3) Change the "ConnectionFactoryJNDIRef" for the UILServerILService to "ConnectionFactory" and change the same attribute for the OILServerILService to another name.
Start JBoss and your application and it should work.
Have fun - Andy
I tried your suggestions. Actually I didn't change the ports because the current ports (1099, 4444, 8090, 8091) were all already open. Furthermore I put both computers in the DMZ. I get exactly the same result.
To verify, on the client side, I'm using this:
-Djava.naming.provider.url=<server ip address>
Is this correct?
Then you don't have a problem with your firewall. So you should fix the lookup first.
But this why I'm confused (and stuck)! It works fine if the two apps are running on the same machine. If they're on different machines on different networks it doesn't work. Any ideas how I can troubleshoot this?
I have had similar issues. I will tell you what I have discovered for what it is worth
(disclaimer - I may be talking tripe, but at least I am sharing information unlike the ivory towered JBOSS development group who seem unwilling to address and document remote network and firewall deployment issues)
We have a client which we need to establish a JMS connection from their site to our servers (2 firewalls)
to get this working (and it is by no means complete) I had to open the jnp (Java naming protocol) port - 1099
update the jndi.properties file on the client to set the
java.naming.provider.url to point to the remote JNDI server. I also had to set the jboss.properties file on the server java.rmi.server.hostname value to point to the server. And added a RmiPort attribute to the jboss.jcml file (under the mbean element for org.jboss.naming.NameServer. This value seams to be sent to the client (I have ordered a RMI book after this experience to learn all!)
At which point JNDI connectivity is established. We also changed the OIL jms service port to somthing we wanted to use. However it also seams that the server will return the JMS servers IP address, so if your network has a NAT this returned IP address will be the local network IP not the correct global IP address (This is our problem). I do not currently know how to fix this issue yet
Hope this helps
Stop you FUD because when you know the solution the provide us with your insights otherwise be nice to all of us in order to get your info. You can start bitching around when you contributed some work to JBoss.
FIRST: I assumed that you know to make JNDI happening (set the client's "jndi.properties" correctly). The point with RmiPort is explained.
SECOND: if you had read my anwser you would know that you have to use "UIL" service instead of "OIL" and set the "ServerBindPort" which has to be opened on the firewall.
THIRD: the firewall has to forward the call on a certain port to the right port on the JBoss server.
FOURTH: check your "Hosts" file so that you do not screw up the reverse lookup of the name/IP address.
If you still have problesm provide us with:
- client's "jndi.properties" file
- JNDI settings in "jboss.jcml"
- JBossMQ settings in "jboss.jcml"
- client's code
Have fun - Andy
There is no doubt, this type of deployment/configuration is NOT documented. If JBossMQ wants to be taken seriously, it needs better documentation and configuration samples. Otherwise people will not use it, which defeats the entire purpose of developing it in the first place. Think of all the hard work that went into JBossMQ that will be wasted because people can't deploy it!
Meanwhile SwiftMQ is very cheap ($800), has good support (they answered my sales enquiry in just a couple hours), and has documentation and samples.
Of course they answered your sales enquiry quickly at $800 a throw.
I've had problems with jbossmq, I've always asked about them and they have always been sorted out by somebody on these forums.
If you want to be taken seriously maybe you could contribute some documentation or samples?
> FOURTH: check your "Hosts" file so that you do not
> screw up the reverse lookup of the name/IP address.
This one is critical. In my experience, it is very often at this point it fails. The giveaway is that the remote computer, after the initial lookup, tries to connect to ports on itself.
The reason for this, as far as I understand, is that the naming service tries to find its own ip-address for inclusion in the reply to the client.
If the name of the server host is mapped to localhost or 127.0.0.1 on the server (in the hosts file), then it sends 127.0.0.1 to the client. 127.0.0.1 of course means something else there.
I know this is what the previous poster mentioned, I just thought I'd elaborate a bit.
This information may be slightly off-topic, or perhaps not. I saw mention of "NAT".
When a client is establishing an OIL connection, it uses Inet.getLocalHost() (seen somewhere in the OIL code) to retrieve the local IP address which it then ships across the wire to the server. The server then attempts to use this address when doing PING back to the client. The PING fails (because there is no route to the IP address sent to the client -- the client may be seen at an entirely different IP address on the server due to NAT, and the address sent by the client may not be routed on the server). While manipulation of the hosts file on the client may solve the problem, such a solution falls short of perfection on a multi-homed client. With a multi-homed host, you may have competition for who gets to control the "local" IP address.
Generally, I believe, one should not be shipping IP addresses across the wire. The server should grab the IP address of the client from the incoming connection socket. Doing it that way ensures that the server has an address for the client in the server's local NAT domain. In theory then, the server should be able to connect back to that address (firewall may intervene and prevent it). So, OIL does not function well in the face of NAT.
However, hope is not lost. Using OIL2 instead of OIL solves the problem. To use OIL2, ensure that your version is built from source newer than 23-July-2002 and use "OIL2ConnectionFactory" as your ConnectionFactory name instead of "ConnectionFactory".
Ummm.. I meant to say InetAddress.getLocalHost() in the previous post.
then what's the solution for JMS and firewall?
Is there a problem with reading ?
Please read my lips:
DON'T EVER USE OIL WHEN BEHIND A FIREWALL !! ALWAYS USE UIL (JBoss 2.4.x) OR OIL2 WHEN AVAILABLE.
Have fun - Andy