Karl Schulze
2006-06-14 15:05:47 UTC
Hello all,
I have currently investigated a very odd problem when using omniORB 4.0.7.
The problem arises on several client/server applications I am working on.
The setup I am using is, running omniNames on a Linux box, running the
servers on
a Linux box and running the clients on windows boxes. Within this setup
the clients
sometimes are not able to to get objects from omniNames.
I was able to reproduce the problem with the echo example that is
included in omniORB 4.0.7.
Therefore is started omniNames with the default parameters, except the
following
scanGranularity = 1
inConScanPeriod = 1
threadPerConnectionPolicy = 0
maxServerThreadPoolSize = 5
The eg3_impl server ist started on the same machine as omniNames,
without any special needs.
For the client I have used eg3_clt with some small notifications in
'main', that are as follows
int
main (int argc, char **argv)
{
try {
CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
for (CORBA::ULong count=0; count < 1000; count++)
{
cerr << count << "/1000" << endl;
CORBA::Object_var obj = getObjectReference(orb);
Echo_var echoref = Echo::_narrow(obj);
hello(echoref);
Sleep(2000);
}
orb->destroy();
}
... the remaining code (except #include <Windows.h> for Sleep) is the
original code.
Using now this modified client with the above mentioned omniNames, I get
the error:
Caught system exception COMM_FAILURE -- unable to contact the object.
This usually occur for count between 100 and 300, sometimes below
sometimes above.
The problem seems somehow be related with the cleanup of the idle
connections, because
when I set scanGranularity = 0 the problem no longer exist, but I need
the cleanup of the
connections to prevent the omniNames to run out of network-file-descriptors.
I have also tried to use omniNames from 4.1.0beta2 that shows the same
behavior.
Using Linux for the client does not show this problem.
Is this a known behavior? (I have searched the archive but found nothing
that seems similar)
Anything I did wrong?
Regards,
Karl
I have currently investigated a very odd problem when using omniORB 4.0.7.
The problem arises on several client/server applications I am working on.
The setup I am using is, running omniNames on a Linux box, running the
servers on
a Linux box and running the clients on windows boxes. Within this setup
the clients
sometimes are not able to to get objects from omniNames.
I was able to reproduce the problem with the echo example that is
included in omniORB 4.0.7.
Therefore is started omniNames with the default parameters, except the
following
scanGranularity = 1
inConScanPeriod = 1
threadPerConnectionPolicy = 0
maxServerThreadPoolSize = 5
The eg3_impl server ist started on the same machine as omniNames,
without any special needs.
For the client I have used eg3_clt with some small notifications in
'main', that are as follows
int
main (int argc, char **argv)
{
try {
CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
for (CORBA::ULong count=0; count < 1000; count++)
{
cerr << count << "/1000" << endl;
CORBA::Object_var obj = getObjectReference(orb);
Echo_var echoref = Echo::_narrow(obj);
hello(echoref);
Sleep(2000);
}
orb->destroy();
}
... the remaining code (except #include <Windows.h> for Sleep) is the
original code.
Using now this modified client with the above mentioned omniNames, I get
the error:
Caught system exception COMM_FAILURE -- unable to contact the object.
This usually occur for count between 100 and 300, sometimes below
sometimes above.
The problem seems somehow be related with the cleanup of the idle
connections, because
when I set scanGranularity = 0 the problem no longer exist, but I need
the cleanup of the
connections to prevent the omniNames to run out of network-file-descriptors.
I have also tried to use omniNames from 4.1.0beta2 that shows the same
behavior.
Using Linux for the client does not show this problem.
Is this a known behavior? (I have searched the archive but found nothing
that seems similar)
Anything I did wrong?
Regards,
Karl