Uploaded image for project: 'OFBiz'
  1. OFBiz
  2. OFBIZ-4296

JmsTopicListener started twice when distributed-cache-clear is active

    XMLWordPrintableJSON

    Details

      Description

      This is a follow up issue of OFBIZ-3987 and OFBIZ-4202. Apparently the problem was not properly fixed. The infinite loop during startup went away, but there still are other side effects.

      Log output excerpt:

      2011-05-26 09:43:56,336 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [ JmsListenerFactory.java:64 :INFO ] Starting JMS Listener Factory Thread
      ...
      2011-05-26 09:44:00,499 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [ JmsListenerFactory.java:64 :INFO ] Starting JMS Listener Factory Thread
      2011-05-26 09:44:01,076 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [   JmsTopicListener.java:88 :INFO ] Listening to topic [ofbiz-cache] on [activemq]...
      2011-05-26 09:44:01,111 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [   JmsTopicListener.java:88 :INFO ] Listening to topic [ofbiz-cache] on [activemq]...
      ...
      2011-05-26 09:44:21,081 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [ JmsListenerFactory.java:74 :INFO ] JMS Listener Factory Thread Finished; All listeners connected.
      2011-05-26 09:44:21,111 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [ JmsListenerFactory.java:74 :INFO ] JMS Listener Factory Thread Finished; All listeners connected.
      

      What happens is this:

      DelegatorFactory.getDelegator("default") is called during startup (CatalinaContainer init). After creating the delegator and putting it in the cache it calls delegator.initEntityEcaHandler(). Somewhere inside it tries to get a dispatcher, so the first ServiceDispatcher instance is initialized. Inside the constructor code the JobManager wants to access the database and somewhere inside the EntityExpr another call to DelegatorFactory.getDelegator("default") is done. As the ECAHandler is already initialized it now initializes the DCC using EntityCacheServices.setDelegator(). This creates the second ServiceDispatcher instance and starts up the first JmsListenerFactory thread. Further up the call stack, a little later the "outer" ServiceDispatcher now also creates a JmsListenerFactory thread. So we have two listeners and every JMS message is handled twice.

      As a workaround we broke the recursion in the ServiceDispatcher constructor by doing a lazy initialization of the dispatcher in EntityCacheServices: We moved the call to EntityServiceFactory.getLocalDispatcher(delegator) out from the setDelegator method to when it is first needed.

      This doesn't seem like the proper solution, though. Maybe someone with more insight on how all the initialization of the dispatcher and delegator works can contribute a proper fix.

        Attachments

        1. OFBIZ-4296.patch
          5 kB
          Dimitri Unruh
        2. changeset_2683.patch
          3 kB
          Jacques Le Roux

          Issue Links

            Activity

              People

              • Assignee:
                jleroux Jacques Le Roux
                Reporter:
                mkreidenweis Martin Kreidenweis
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: