Skip to main content

Problem with remote connection to GlassFish 3.1.1 on Linux via ORB

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
12 replies [Last post]
mastern
Offline
Joined: 2012-01-11

Hi all,

from a javaws swing client, I want to remotely connect to a server-side Enterprise Java Bean via ORB. The client runs on my laptop while the server-side system (a Java enterprise application) to which I want to connect runs on a GlassFish 3.1.1-b12 on a remote Linux machine.

When trying to connect to the server-side EJB via a JNDI-lookup, the client just gets stuck and never returns (unless I do not kill it manually). There is neither an exception on the client nor on the server (according to the log files). However, it works when I deploy it to the GlassFish installation on my own (Linux) machine and connect to "localhost". Even more strange, the JNDI-lookup also works when I deploy the EAR to a GlassFish installation (same version) on a remote Windows machine. This makes me think that there is nothing wrong with my ORB, IIOP, JNDI or port settings.

In a nutshell, it appears that the client is able to establish the ORB connection to a GlassFish on "localhost" (Linux or Windows) as well as on remote hosts with Windows, but not with Linux. One could justifiably assume that the Linux machine's firewall blocks the connection. Unfortunately, the firewall settings can not cause the problem as it is possible to connect to the system on the very same Linux machine when it is deployed on a GlassFish 2.1.1 (using the same ORB, IIOP, JNDI and port settings, etc.).

Especially the fact that it is working when deployed to a GlassFish on a remote Windows machine confuses me a lot; -- and by now, I ran out of ideas. I would be very happy about any information or suggestion that can help to solve this problem.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ztangm
Offline
Joined: 2010-06-13

I opened java.net/jira/browse/GLASSFISH-18199 regarding this problem.

2 Guest
Offline
Joined: 2012-01-11

mastern wrote:

Hi all,
from a javaws swing client, I want to remotely connect to a server-side
Enterprise Java Bean via ORB. The client runs on my laptop while the
server-side system (a Java enterprise application) to which I want to connect
runs on a GlassFish 3.1.1-b12 on a remote Linux machine.
When trying to connect to the server-side EJB via a JNDI-lookup, the client
just gets stuck and never returns (unless I do not kill it manually). There
is neither an exception on the client nor on the server (according to the log
files). However, it works when I deploy it to the GlassFish installation on
my own (Linux) machine and connect to "localhost". Even more strange, the
JNDI-lookup also works when I deploy the EAR to a GlassFish installation
(same version) on a remote /Windows/ machine. This makes me think that there
is nothing wrong with my ORB, IIOP, JNDI or port settings.
In a nutshell, it appears that the client is able to establish the ORB
connection to a GlassFish on "localhost" (Linux or Windows) as well as on
remote hosts with /Windows/, but not with /Linux/. One could justifiably
assume that the Linux machine's firewall blocks the connection.
Unfortunately, the firewall settings can not cause the problem as it is
possible to connect to the system on the very same Linux machine when it is
deployed on a GlassFish 2.1.1 (using the same ORB, IIOP, JNDI and port
settings, etc.).
Especially the fact that it is working when deployed to a GlassFish on a
remote Windows machine confuses me a lot; -- and by now, I ran out of ideas.
I would be very happy about any information or suggestion that can help to
solve this problem.

I have exactly the same problem!! Some help would be appreciated.

--

[Message sent by forum member 'ztangm']

View Post: http://forums.java.net/node/882266

ztangm
Offline
Joined: 2010-06-13

I have exactly the same problem!! Some help would be appreciated.

tjquinn
Offline
Joined: 2005-03-30

Two thoughts:

1. If you can, please download a recent promoted build of GlassFish 3.1.2 and try it. There was at least one ORB-related issue fixed within the past few weeks that might be relevant, although I'm not sure it was present in 3.1.1. It is worth a try, though.

2. For the test which hangs unless you kill it, please let it run until it fails and reports an error. The first naming look-up from the client (which uses the ORB) will probably time out after 10 minutes or so and at least you should get an error message on the client side.

- Tim

mastern
Offline
Joined: 2012-01-11

Thank you very much for your response, Tim!

Regarding your suggestions, please allow me to provide my latest findings:

1. As kindly suggested, I gave the latest GlassFish 3.1.2-b16 a try. Unfortunately, wihtout success. The client's behaviour is still the same as described above.

2. Actually, I also thought that the client would fail with some error after a while, as I expected some time-out to take effect. However, I already had it running (or rather hanging) for almost an hour without getting any exceptions.

In the meantime, I also dabbled in some debugging of the client code. With great ignorance of the details, I shimmied through all the JDNI-lookup and ORB instantiation stuff with a slight hope to narrow down the cause. However, I eventually got stuck at the method "com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl#is_a(Object, String)" in which the hang-up seems to happen but which I were not able to debug any deeper as I do neither have nor get the source code of the corresponding "glassfish-corba-orb-3.1.0-b30" library. I am not even sure if this information would help to find the problem.

Still, I would be very happy about any suggestions.

tjquinn
Offline
Joined: 2005-03-30

We may need to rely on the ORB experts for more suggestions.

One question: Can you tell whether the client-side code is stalled, waiting? Or it is looping and using up CPU?

If you could capture a thread dump that could be helpful. I realize you have already tracked the stall to the is_a method but if there is a deadlock the thread dump should help reveal it.

Also, if you have the time and energy, you could try this:

1. On your server, run the package-appclient command. It creates a zip file which you can copy to the remote system and then expand there. It will contain all the files necessary to launch any client using the appclient command.

2. Next, get the bits for your client to the remote system so you can run it manually there. On your server system, run

asadmin get-client-stubs -appname name-of-your-app localdir

This will create a subdirectory structure at localdir. Zip this directory and all its children, copy it to the remote system, and unzip it into any directory there. Then you can launch this client using

appclient -jar localDirOnRemoteSystem/appNameClient.jar

where, of course, the directory name and the name of the client JAR will depend on your environment.

If the same behavior happens when you launch the client this way, then debugging using the appclient launch will be easier than doing so with the Java Web Start launch.

- Tim

hvilekar
Offline
Joined: 2006-10-06

>"it appears that the client is able to establish the ORB connection to a GlassFish on "localhost" (Linux or Windows) as well as on remote hosts with Windows, but not with Linux."

I deployed test app on GlassFish 3.1.2-b17, running on Red Hat Enterprise Linux Server release 6.1 (JDK 1.6.0_b30) and ran javaws client on Windows 7 Professional (JDK 1.6.0_b27) and it worked just fine.

If you run the appclient as suggested by Tim and still see the issue, try setting system property org.omg.CORBA.ORBInitialHost=remote.linux.host

mastern
Offline
Joined: 2012-01-11

Thank you very much for your help and suggestions, Tim and hvilekar!

tjquinn wrote:

>One question: Can you tell whether the client-side code is stalled, waiting? Or it is looping and using up CPU?

The client seems to wait, there is no CPU consumption when it hangs.

tjquinn wrote:

>If you could capture a thread dump that could be helpful. I realize you have already tracked the stall to the is_a method but if there is a deadlock the thread dump should help reveal it.

I attached the file "20120112_thread_dump.txt" which contains a thread dump that I created during a stall.

tjquinn wrote:

>2. Next, get the bits for your client to the remote system so you can run it manually there. On your server system, run
>
>asadmin get-client-stubs -appname name-of-your-app localdir
>
>This will create a subdirectory structure at localdir.

For unknown reasons, this second step did not work for me. Although the server quit the execution of the command with the words "Command get-client-stubs executed successfully.", no files or directories have been created at the designated directory. I also tried it by providing the client module's name manually via the "--client" option but got an exception saying "Invalid option: --client", although the option is described in the sub-command's help page. So unfortunately, I had not been able to start the client via the appclient.

After having thought about it, I realised that I did not replace and use the latest libraries in my client (i.e. "gf-client-3.1.2-b16" instead of "gf-client-3.1.1", etc.) when testing it with the GlassFish 3.1.2-b16. I am using Maven to build the client, so as simple-hearted as I am, I simply tried to update the Maven dependencies correspondingly, just to learn that promoted builds are apparently not included in the public repositories (or at least not in those I found). As our build process is quite complex, I would like to avoid having to add or deploy all the libraries manually. Is there any Maven repository from which I can get the libraries of promoted GlassFish builds?

Anyway, there is another very interesting thing that I found out: When I stop the domain on the server while the client got stuck in trying to connect to it, the client finally fails with a NamingException. I attached the file "20120112_stack_trace.txt" which contains the client exception's stack trace. Of course, the exception itself is hardly surprising but the fact that it only happens after having stopped the domain on the server leads me to the assumption that there at least exist a connection to the server, even though in some weird status.

Any ideas?

hvilekar
Offline
Joined: 2006-10-06

The client stack trace shows: org.omg.CORBA.ORBInitialPort=4842. Could you please confirm if this matches with your server side settings ? Default value is org.omg.CORBA.ORBInitialPort=3700. In any case, the client is not expected to hang. What is the OS version, GlassFish version, and JDK version on Server, Client side ?
mastern
Offline
Joined: 2012-01-11

I finally found the problem! The described behaviour is apparently caused by a specific setting of the host name resolution in the "/etc/hosts" configuration file on Linux: For some reason, my "/etc/hosts" configuration file had the alias of the server host (on which my GlassFish 3.1.1 instance is running) pointing to 127.0.0.1, e.g.:

127.0.0.1        localhost myservername

Although this setting did not cause any problems with the GlassFish version 2.1.1, I gave it a try and modified my "/etc/hosts" so that the server's very own host name alias points to its actual IP address in the network:

127.0.0.1        localhost
192.168.1.77     myservername

...and voila, the client was able to successfully connect to the server via ORB. With other network configurations or with address resolution at hand, it might also work when just removing the host name from the "etc/hosts" configuration file completely, although I did not test it.

Thank you very much for all your help and suggestions and please excuse for the inconvenience caused.

mastern
Offline
Joined: 2012-01-11

Yes, 4842 was the intended port and the server had been configured correspondingly. But just to be sure, I also tested it with the default port 3700, with the same result. Here are the OSs and GlassFish versions that I have tested so far and for which I had not been able to establish a (working) ORB connection:

Client OSs: Fedora 15 / Windows XP

Client Java Version: JDK 1.6.0_30-b12

Server OSs: Fedora 15 / Red Hat Enteprise Linux 4.1.2-48

Server Java Version: JDK 1.6.0_30-b12

GlassFish Versions: 3.1.1-b12 / 3.1.2-b16 / 3.1.2-b17 (12-31-2011)

arcifaan
Offline
Joined: 2012-01-13

Hi All,

I have a similar problem. The guys have re-implemented all this stupid corba stuff again,

and now I'm not able to connect my glassfish (3.1 Vers.) server!

What a great improvement!

I would be very grateful to lern the solution.

Thanks!