[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.

Maarten Van Hout Maarten.VanHout at get.be
Tue May 24 09:02:33 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?

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