> Hi,
>
> First of all, I hope your solved the CORBA.INV_OBJREF exception
> problem.
First of all, many thanks for trying to help :-)
> Now, concerning your question, if you're on Solaris, may be using
> 'truss' can help your to find the problem.
Unfortunately not. I already have the stack trace. Besides, when using
truss on event driven programs it will typically just show the
routines that drive it round the event loop. For CORBA programs that
will be the socket read and select calls.
> BTW, it is usually a good
> idea to specify the platform you're working on (even if you're writing
> in Java).
Solaris 8.
> When you say 'When we start the 3 servers', do you mean you start them
> after the reboot or you're starting them after those servers were
> shuted down (restarted)?
There is no reboot. The machine stays up the whle time. I should have
been more specific. When I said "restart tings" that was a bit vague.
What I meant was running a script that finds the server pids (using
ps) then issues a kill -9. Then I run the script that starts the
servers again.
> Are your servers configured to run always on
> the same port?
There is no port configuration as such. This is CORBA, where ports are
an implementation detail buried in the IOR. I have made no changes in
this area so OW will choose whatever ports it sees fit. There is a
particular port number used to communicate with the orbix daemon, it
is port 1570, er, I think. Anyhow this also is the default and if
there was a problem with that then the Orbix daemon would not start.
> Is it possible other processes are using those ports?
No.
> Regards,
> Yakov
Yakov Gerlovin - 06 Feb 2008 11:11 GMT
OK, I had a very similar problem with Solaris 8 a couple of years ago.
When your process does not gracefully close the socket the port it
listens on remains used for some time ( this time is configurable).
Any attepts to bind to the same port will fail (until the OS frees
it).
kill -9 is unmaskable, while regular kill can be caught in your
server. Implement signal handlrer ( if it is possible in Java ) that
just shuts down the ORB.
The more clean solution is to add 'shutdown' method to some root
object (or write a small servant with only this method). It would be
easier if the object with shutdown method will be persistent and
registered under POA, configured with direct persistency (check the
documentation whether OrbixWeb supports direct persistency). This way
the object reference will not change between restarts.
> This is CORBA, where ports are an implementation detail buried in the IOR.
Indeed, port allocation is implementation specific. However many
implementations allows some level of control over it.
marlow.andrew@googlemail.com - 07 Feb 2008 20:50 GMT
> OK, I had a very similar problem with Solaris 8 a couple of years ago.
[snip]
> The more clean solution is to add 'shutdown' method to some root
> object
There is another approach. Rollback all the java work and revert to
the original C++ servers. This is what is going to be done. The
reasoning is that the introduction of java on the server side appears
to coincide with a greater number of Orbix connectivity problems.
Removing java from the equation and seeing if these connectivity
incidence decrease is the only way to be sure whether or not the
incidents are connected with the presence of java in the system.