Sonic Cache file pubsub.odb perpetually increases in size

  • Document ID:7002580
  • Creation Date:06-Feb-2009
  • Modified Date:26-Apr-2012
    • Micro Focus Products:
      Sentinel

Environment

Novell Sentinel 6.0
Novell Sentinel 6.1
Sentinel Communication Server
SonicMQ

Situation

 

Within Sonic MQ the pubsub.odb file will increase in size from normal 1 GB to well above this size.

Sonic (and JMS buses in general) provide the capability to register for data using a "durable subscription". This means that even if the client that is reading the data goes down (i.e., the process exits), the JMS will hold onto the data that was generated while the process was down and it will provide the data to the process when it comes back up.

The only thing that subscribes in a durable way is the das_binary process on the event channels. You can see how this is done by searching for "#durable" in the das_binary.xml file.

A durable subscription is identified by its UUID. UUIDs are used by the DAS_Binary service in the configuration.xml file to identify the subscriber. Each time das_binary is launched, it registers the durable subscription with Sonic using this UUID. This is how Sonic knows that the new registration is related to a durable subscription that was made in the past and will send this subscriber the data it missed while it was down.

Resolution

The most likely cause of the large Sonic cache file is the presence of, at some point in the past, a das_binary that made a durable subscription to Sonic using a UUID but is no longer reading data from Sonic.  This could be caused simply by the UUID somehow changing in the configuration.xml file (user intervention); das_binary may have been moved from one machine to another, thus causing a new UUID to be generated in the new configuration.xml file that was used.


To See your Durable Subscription's you will need to launch Sonic Management Console. Please refer to Tid # 7002753 


If you look at the  image, you can see a simulated scenario.


 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Using the Sonic Management Console, we can see there are two sets of registrations on the event channels, one from a DAS_Binary with a client id starting with 7091 and the other with a client id starting with C0A2.  The das_binary with the client id 7091 was down for a long time, so it's count column is quite high, indicating that Sonic is holding on to a lot of events for it.  In this case, the Sonic cache is about 26 GB in size.



 
If you right click on the connections related to the 7091 connection, you can select "delete" to delete the durable subscription.  This will cause Sonic to forget about the old subscription. 
 
 
 
 

Additional Information

If desired, you can reclaim the used space from the unwanted durable subscription. In order to compact the Sonic cache down to a smaller size, do the following:

1. Shutdown Sentinel. Make sure all processes are stopped (in particular, Sonic).

2. Run the following command:

For Linux/Unix: $ESEC_HOME/3rdparty/SonicMQ/MQ7.0/bin> ./dbtool.sh -f ../db.ini /z

For windows: %ESEC_HOME%\3rdparty\SonicMQ\MQ7.0\bin> dbtool.bat /f ../db.ini /z

NOTE: It seems that in order for the command to work properly, you must be in the ESEC_HOME\3rdparty\SonicMQ\MQ7.0 when you execute the command.


When you run the above command you may get the following message ("InitBrokerDatabase terminates.") and the size of the Sonic cache will not decrease. Therefore, do the following, in order to recreate the Sonic DB.
 
Note:  If there were any events in the cache that das_binary didn't process, they will be lost!

Use the following command:

For Linux/Unix: $ESEC_HOME/3rdparty/SonicMQ/MQ7.0/bin> ./dbtool.sh -f ../db.ini /r all

For windows: %ESEC_HOME%\3rdparty\SonicMQ\MQ7.0\bin> dbtool.bat /f ../db.ini /r all

Note:  The -r option used to compact the tool may need temporary space to perform.  Make sure you have serveral GB of free disk space where Sonic (Sentinel Communication Server) is installed.  If space is not available, you may need to perform a delete and re-create.

This clears out the cache and shrinks the size of the Sonic directory down to less than 1 GB.