[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.
Johnny Willemsen
jwillemsen at remedy.nl
Tue May 24 03:44:53 CDT 2016
Hi,
> Can you (or someone else) think of any way I can create a test that reproduces this issue?
There are some BiDIR tests that look into the transport cache with
current open transports, maybe you can use that, check with some
internal code whether the server listens on the address it should
Johnny
>
> Best regards,
> Maarten Van Hout
>
> -----Oorspronkelijk bericht-----
> Van: Chernenko, Viktor (GE Healthcare) [mailto:viktor.chernenko at med.ge.com]
> Verzonden: maandag 23 mei 2016 11:08
> Aan: jwillemsen at remedy.nl; Maarten Van Hout; tao-users at list.isis.vanderbilt.edu
> Onderwerp: [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,
>
> 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