[opendds-main] Memory usage changes following connection and disconnection.

[Kevin A. <au...@me...>]

PROBLEM-REPORT-FORM for an issue around handling the error events that 
result when an attempt is made to use an already in use address.

     OpenDDS VERSION: 3.1  (OpenDDS version 3.1, released Wed Mar 28 
17:41:16 UTC 2012)
     TAO VERSION: 1.6a_p13
     (ACE VERSION: 5.6a_p13)

     HOST MACHINE and OPERATING SYSTEM: Linux, Fedora Core 17

     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:

     COMPILER NAME AND VERSION (AND PATCHLEVEL): g++ (GCC) 4.7.0 (Red 
Hat 4.7.0.5)


     CONTENTS OF $ACE_ROOT/ace/config.h [if you use a link to a platform-
     specific file, simply state which one]: $ACE_ROOT/ace/config-linux.h

     CONTENTS OF $ACE_ROOT/include/makeinclude/platform_macros.GNU (unless
     this isn't used in this case, e.g., with Microsoft Visual C++): 
$ACE_ROOT/include/makeinclude/platform_linux.GNU
     (with optimization and inline enabled)

     CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
     (used by MPC when you generate your own makefiles): none used

     LEVEL OF URGENCY (LOW, MEDIUM, or HIGH): MEDIUM

     AREA/CLASS/EXAMPLE AFFECTED: examples/DCPS/IntroductionToOpenDDS.

     DOES THE PROBLEM AFFECT: Execution

     SYNOPSIS:

     Large changes in physical memory used by a publisher on connection 
of a subscriber that may be released on disconnection.

     DESCRIPTION:
      We have three examples with similar memory behaviour:
       1. The IntroductionToOpenDDS example running under the linux 
platform described above.
           In this instance the memory used by the publisher jumps 6Mb 
following the
          connection of a subscriber. At some point (may be several 
seconds) after the subscriber
          is killed the memory usage of the publisher jumps down 6Mb. 
Restarting the subscriber
          before the memory is released can cause the memory in use by 
the publisher to climb
          another 6Mb. The memory can remain high following disconnection.

          Multiple subscriber connections results in multiple jumps of 
6Mb in physical memory
          assigned to the publisher.

       2. We have our own DDS based applications running under linux:
            In this instance, the physical memory for the publisher 
jumps 6-7Mb on subscriber connection
            and is returned on subscriber disconnection.

       3. Our own DDS based applications running under QNX:
           In this instance, the physical memory for the publisher jumps 
6-7Mb on subscriber connection
           but is not returned on disconnection. The memory assigned to 
the publisher can grow large.



     REPEAT BY:
      Use the example publisher and subscriber in 
$DDS_ROOT/examples/DCPS/IntroductionToOpenDDS/
      do the following:
       1. Set LD_LIBRARY_PATH environment variable: export 
LD_LIBRARY_PATH=$ACE_ROOT/lib:$DDS_ROOT/lib
       2. Start the information repository:
            $DDS_ROOT/bin/.DCPSInfoRepo -ORBEndpoint 
iiop://localhost:12345 -NOBITS
       3. Start the publisher:
            - $DDS_ROOT/examples/DCPS/IntroductionToOpenDDS/publisher 
-DCPSConfigFile 
$DDS_ROOT/examples/DCPS/IntroductionToOpenDDS/dds_tcp_conf.ini
       4. Identify the PID for the publisher and run top to view the 
memory usage
            - top -p <publisher PID>
       5. Start the subscriber:
            - $DDS_ROOT/examples/DCPS/IntroductionToOpenDDS/subscriber 
-DCPSConfigFile 
$DDS_ROOT/examples/DCPS/IntroductionToOpenDDS/dds_tcp_conf.ini
       6. Observe the physical memory field reported by top (RES field) 
jump by 6Mb.
       7. Stop the subscriber
       8. Observe the physical memory field for the publisher jump back 
down by 6Mb
           (time to change may vary, but wait at least 20s or until 
change occurs).
       9. Restart the subscriber.
       10. Observe the memory for the publisher jump by 6Mb.
       11. Stop the subscriber and restart the subscriber before the 
change in publisher memory occurs (if possible).


     Of most concern to us is the behaviour when run under QNX, i.e. we 
don't get a return of memory.
     However the similar memory changes under linux suggest a common 
action at the root of the issue.
     We would like to understand what causes these large changes in 
memory used, so that we may
     work out what we are doing wrong in our own applications.

     SAMPLE FIX/WORKAROUND: