[tao-users] After an upgrade of ACE/TAO from 2.2.2 to 2.3.3, the behaviour of the portspan parameter of -ORBListenEndpoints seems to have changed.
Chernenko, Viktor (GE Healthcare)
viktor.chernenko at med.ge.com
Mon May 23 04:07:59 CDT 2016
Hi,
I also encountered the below described issue and searched for the root cause. I believe the behavior was changed by removing the ignore of the SO_REUSEADDR option on Windows (see Bugzilla 4189). Actually this is not a "portspan" problem. In contrast to the previous version, ACE/TAO 2.3.3 sets the SO_REUSEADDR option by default, which allows a socket to bind to a port in use by another socket.
Mon Oct 27 18:06:17 UTC 2014 Johnny Willemsen <jwillemsen at remedy.nl>
* ace/config-win32-common.h:
Don't define SO_REUSEPORT when it is not defined, the code
that uses this as argument to call ACE_OS::setsockopt only works
when this has been defined. Defining it here to a dummy value
causes us to call the Windows API with an invalid argument
Mon Oct 27 07:57:57 UTC 2014 Johnny Willemsen <jwillemsen at remedy.nl>
* ace/OS_NS_sys_socket.inl:
Removed the ignore of SO_REUSEADDR on windows, this is needed
for ACE_SOCK_Dgram_Bcast to work, see bugzilla 4189. Also removed
the Windows specific change of SO_REUSEPORT to SO_REUSEADDR, this
are different flags that we should not merge at this level.
--
Best regards,
Viktor Chernenko
-----Original Message-----
From: tao-users [mailto:tao-users-bounces at list.isis.vanderbilt.edu] On Behalf Of Johnny Willemsen
Sent: Mittwoch, 18. Mai 2016 17:13
To: Maarten Van Hout; tao-users at list.isis.vanderbilt.edu
Subject: EXT: Re: [tao-users] After an upgrade of ACE/TAO from 2.2.2 to 2.3.3, the behaviour of the portspan parameter of -ORBListenEndpoints seems to have changed.
Hi,
Thanks for using the PRF form. This sounds like a bug, at the moment you
use portspan the behavior should be as you described with 2.2.2.
Could you create an automated unit test (by taking one of the existing
ones under TAO/tests) that reproduces this? See
https://github.com/DOCGroup/ACE_TAO for the current git repository where
you can open a pull request with the new test.
Best regards,
Johnny Willemsen
Remedy IT
Postbus 81 | 6930 AB Westervoort | The Netherlands
http://www.remedy.nl
On 05/18/2016 03:37 PM, Maarten Van Hout wrote:
> TAO VERSION: 2.3.3
>
> ACE VERSION: 6.3.3
>
>
>
> HOST MACHINE and OPERATING SYSTEM:
>
> Windows 7, Winsock2
>
>
>
> COMPILER NAME AND VERSION (AND PATCHLEVEL):
>
> Visual Studio 2015 Express Edition 19.00.23918 for x86
>
>
>
> THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform-
>
> specific file, simply state which one]:
>
> ace/config-win32.h
>
>
>
> CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
>
> (used by MPC when you generate your own makefiles):
>
> -
>
>
>
> AREA/CLASS/EXAMPLE AFFECTED:
>
> -
>
>
>
> DOES THE PROBLEM AFFECT:
>
> COMPILATION? No
>
> LINKING? No
>
> EXECUTION? Yes
>
> The problem affects all our server applications.
>
>
>
> SYNOPSIS:
>
> After an upgrade of ACE/TAO from 2.2.2 to 2.3.3, the behaviour
>
> of the portspan parameter of -ORBListenEndpoints seems to have
>
> changed.
>
>
>
> DESCRIPTION:
>
> The following options are used to start our servers:
>
> -ORBListenEndpoints iiop://192.168.205.48:2001/portspan=31
>
> -ORBInitRef NameService=corbaloc:iiop:GET12022:1570/NameService
>
>
>
> With the first option, we use portspan=31 so our servers listen on
>
> the first free port, starting at 2001 till 2031.
>
> This has always worked, but ever since the upgrade, it didn't.
>
>
>
> What we saw when using TAO 2.3.3 was the following. After startup,
>
> all our servers where listening on port 2001, but only the first server
>
> to start was able to establish a connection with the naming service.
>
>
>
> With TAO 2.2.2 the behaviour was different. The first server started
>
> would use port 2001, the second 2002, and so on. What we expected our
>
> servers to continue doing after the upgrade to 2.3.3.
>
>
>
> We managed to get the needed behaviour by changing the first option to
>
> -ORBListenEndpoints iiop://192.168.205.48:2001/portspan=31&reuse_addr=0
>
>
>
> Is this the way to go now? Why did this behaviour change? Was it a
> bug that
>
> has been fixed? Or is it a bug now?
>
>
>
> REPEAT BY:
>
> Please adjust the ip address in the following program. When executing
>
> this application twice, you should see the 2 applications listen
>
> on the same port (2001).
>
>
>
> #include "tao/TAO_Internal.h"
>
> #include "tao/PortableServer/PortableServer.h"
>
>
>
> int main()
>
> {
>
> CORBA::ORB_var orb = CORBA::ORB::_nil();
>
> PortableServer::POA_var poa = PortableServer::POA::_nil();
>
> PortableServer::POAManager_var poa_manager
>
> = PortableServer::POAManager::_nil();
>
>
>
> if(! CORBA::is_nil(orb)) return 1;
>
> char* oargv[] = {
>
> "dummy",
>
> "-ORBListenEndpoints",
>
> const_cast<char*>(
>
> "iiop://192.168.205.48:2001/portspan=31"),
>
> 0
>
> };
>
> int oargc = (sizeof(oargv)/sizeof(char*)) - 1;
>
> orb = CORBA::ORB_init(oargc,oargv,"TAO_orb");
>
>
>
> CORBA::Object_var poa_object
>
> = orb->resolve_initial_references("RootPOA");
>
> poa = PortableServer::POA::_narrow(poa_object);
>
> poa_manager = poa->the_POAManager();
>
> poa_manager->activate();
>
>
>
> while(1);
>
>
>
> return 0;
>
> }
>
>
>
> SAMPLE FIX/WORKAROUND:
>
> Changing the first option to
>
> -ORBListenEndpoints iiop://192.168.205.48:2001/portspan=31&reuse_addr=0
>
> did the trick.
>
>
>
> _______________________________________________
> tao-users mailing list
> tao-users at list.isis.vanderbilt.edu
> http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/tao-users
>
_______________________________________________
tao-users mailing list
tao-users at list.isis.vanderbilt.edu
http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/tao-users
More information about the tao-users
mailing list