1 Reply Latest reply on Jun 18, 2015 9:12 AM by sjclutter

    How to optimize the LBM UM configuration for avoiding Core-5688-540: WARNING: source for topic  * "MSG_FEED:SYM" forced reclaim 41c. "

    New Member

      How to optmize the LBM configuration for avoiding source retention buffer problem that eventually end up in giving

      Core-5688-540: WARNING: source for topic  * "MSG_FEED:SYM" forced reclaim 41c. " continuously.

       

      What are the set of configurations to use for this.  As there are lots of configuration options are present in both source and receiver section in the LBM xml config.

      I did some experiments but no luck. I guess I am missing lots of information to do so.

       

      I see below options and dont really know how to set the right values.

      restransmit_request_outstanding_maximum

      retransmit_request_maximum

      retransmit_request_internal

      retransmit_request_generation_internal

      delivery_control_loss_check_internal

       

      retransmit_retention_size_threshold

      retransmit_retention_age_threshold

      retransmit_retention_size_limit

       

      Also SOme besic fundamentals questions.

      1. How to know how many sources and how many receivers are present. Are these source and receiver two threads of the same process.

      2. How to know when late joining is hapening?  Under exactly what condition it happnes.

      3. When we restart the system ( process who is responsible to listen for say market data written over LBM apis), What exactly happen from source , receiver and their buffer point of view.?

       

      I believe it brings a good discussion.

       

      Thanks,

      Abhishek

        • 1. Re: How to optimize the LBM UM configuration for avoiding Core-5688-540: WARNING: source for topic  * "MSG_FEED:SYM" forced reclaim 41c. "
          New Member

          Hello Abishek,

           

          Forced reclaims can only occur on UMP or UMQ versions of the UM product line.

           

          What the warning means is that one of the retention settings has not been meet, thus the message is still in the retention buffer; but the given message is also over the retention buffer's size limit.

           

          Typically this occurs when the age threshold and the retention buffer memory limit are mismatched based on the amount of data you are publishing on the given topic source object.

           

          When setting both the age threshold and the retention size limit, you need to calculate the amount of data your application is sending (in bytes) for that period of time.  The retention buffer's size limit needs to be larger than that calculated value by a good margin to address spikes in the load.

           

          Please note: this answer assumes that you are not using persistence.  The use of UMP and UM Stores adds more possibilities for seeing forced reclaims, however, those possibilities would not cause ongoing forced reclaim reports.

           

          Regards,

          Sherwin Clutter