[philippose]

Hello,
Good day!

I installed the latest Fedora Core (FC6) a day ago, and reinstalled the OpenFOAM 1.3 system as I had done in my previous linux version (Fedora Core 5).

Everything works fine, except for FoamX. When I run "FoamX", the system successfully starts the FoamXHB and creates a name server with:

inet:localhost.localdomain:1234

Once the HostBrowser is up, it continues to load the Java CaseBrowser. At this stage, it quits with the error:

"Default name service could not be contacted"

I tried running just "runFoamXHB" in one console.... it ran fine, and then used the administrative tools.... "iordump" and "nsadmin", to see if there was anything amiss.... everything seems to be fine.

Then when I run FoamX from another console, it finds the running server (from nsd.ref), and tries to connect to it, but exits with the same error.

Does anyone have any suggestions on what this might be? I have opened the port 1234 as both tcp and udp in the firewall, and looked through SELinux for anything obvious which might be blocking access... but have not found anything so far.

Any leads will be welcome :-) While I continue snooping around under the hood!

Have a nice weekend!

Philippose

[philippose]

Hi again,
Looks like perseverance does pay off after all :-)! Got it working finally! As it is with most problems, once it is solved one wonders why the solution didnt strike you straight-away!

Anyway, it was just a question of setting a hostname alias. A change using "hostname <name>" in the console did not help, because that change somehow does not get reflected to the system.

I had to set the hostname using the network settings in KDE (or Gnome too I am sure!), and it worked.

Was wondering.... is there a specific reason why the CORBA name service does not work when the hostname is set to "localhost" or "localhost.localdomain" ?

So... have a working OpenFOAM 1.3 on Fedora Core 6 now!

Have a nice day!

Philippose

[mattijs]

> is there a specific reason ... "localhost"

Guess since it is not unique. The IOR might get picked up by a process running on another machine who interprets localhost again.

[philippose]

Hi Mattijs,
That does make sense.... it would be ambiguous in an environment with more than one Host running the Foam name service...

Maybe we should make a simple change to the FoamX script which lets the user know when a Hostname is not valid, and quits before creating the CORBA name service

Currently, the problem is, that the Host runs, and successfully creates a CORBA name service using "localhost", but the Java Host Browser fails to find it, and quits with a very cryptic error message.

Since the FoamX script is a normal bash script, it is easy to make this change which would save people a lot of trouble :-) (I turned the screws on every possible network related thing I could :-)!)

What do you think?

Have a nice day!

Philippose

[mattijs]

Good idea but how do I know a hostname is not valid? If localhost is not valid then why has nsd no problems with it and only the Java bit? Is 10.0.0.127 acceptable?

For now I added a check for 'localhost' to the runFoamXHB script.

[philippose]

Hi Mattijs,
You have a valid point there, but thing is, suppose you tell CORBA that the hostname is "10.0.0.127" for example... and it cannot find this IP address... it will quit with an error even before the name service is created by nsd.

On the other hand, "localhost" would be something which CORBA will always find to be theoretically valid, because most (if not all) unix based systems have localhost set to 127.0.0.1, and pinging "localhost" will most definitely give a valid response.

So under most circumstances, giving a simple check for "localhost" as you have done will be good enough, since other errors are detected by nsd.

When someone installs Linux for example on a standalone system, he/she wouldnt really bother to set a special hostname, since it is not required. So a check for "localhost" in my view, would be quite helpful.

Its an interesting question as to why nsd has no problem creating a name service on "localhost", but later when the CORBA system is called from within Java, it fails to find that name service.

I couldnt find any references to such a limitation in any of the CORBA documentation I came across while trying to solve that problem a few days ago.

Maybe we should look a little deeper into some form of CORBA programming documentation.

Have a nice day, and let me know if you find something interesting.

Philippose