0 Replies Latest reply on Jan 16, 2012 2:11 AM by Yong Hao Gao

    Caching the internal messaging objects

    Yong Hao Gao Master

      As the server are receiving and delivering messages, a lot of internal message objects (mostly ServerMessageImpl) are created. In many cases the messages are short lived, meaning they are acknowledged shortly after they have been delivered. This may cause many ServerMessageImpl objects to be created and then discarded (waiting to be garbage collected).

       

      I'm thinking to save some creation time, we can create a factory to manage the creation and reuse of ServerMessageImpl objects. For example

       

      public class MessageFactory

      {

          ServerMessageImpl createMessage(...);

          void releaseMessage(ServerMessageImpl);

      }

       

      where

       

      createMessage() will return a new ServerMessageImpl. The factory first try to find one in the cache. If the cache has one, marks it as used and return it. If not, create a new one and put it to cache.

       

      releaseMessage() will be called whenever a message is completed, i.e. the message is acked, committed, dropped for any reason. When this is called, the ServerMessageImpl object will be marked as unused and return it to the cache.

       

      The cache keeps track of all the ServerMessageImpl objects.

       

      With this factory I hope to achieve 2 goals:

       

      1. performance improvement. Because the 'new' function is supposed to be expensive. Using cache can avoid frequent 'new' objects and therefore improve performance.

      2. reduce garbage collection: In case there are a lot of short lived objects created and discarded frequently, GC could be triggered more times than usual, if the memory size keeps jumping above and below the GC boundaries. Caching these highly dynamic objects will likely to keep the memory size variation more stable.

       

      The implementation seems straightforward. Only that we need to be careful to make sure calling releaseMessage() in every place where such a object is complete (otherwise memory leak).

       

      Is it a good idea?

       

      Howard