[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 11:12:09 CDT 2016
Hi,
> Thanks for your suggestions.
> I have found an existing unit test for portspan that should have failed, but didn't. I changed it and opened a pull request. https://github.com/DOCGroup/ACE_TAO/pull/261/files
>
> Can I take any other action to help this issue being looked into?
Maybe you can see if you can fix it, also read
http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/ACE/docs/ACE-bug-process.html.
Best regards,
Johnny
>
> Best regards,
> Maarten Van Hout
>
> -----Oorspronkelijk bericht-----
> Van: Johnny Willemsen [mailto:jwillemsen at remedy.nl]
> Verzonden: dinsdag 24 mei 2016 11:06
> Aan: Maarten Van Hout; Chernenko, Viktor (GE Healthcare); tao-users at list.isis.vanderbilt.edu
> Onderwerp: 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,
>
>> Can you (or someone else) think of any way I can create a test that reproduces this issue?
>
> Or start multiple servers with portspan and then try to start a server again with a fixed port number of the second server you started, that should fail.
>
> 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