JmsTopicListener started twice when distributed-cache-clear is active
---------------------------------------------------------------------

                 Key: OFBIZ-4296
                 URL: https://issues.apache.org/jira/browse/OFBIZ-4296
             Project: OFBiz
          Issue Type: Bug
          Components: framework
    Affects Versions: SVN trunk
            Reporter: Martin Kreidenweis


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:
{code}
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.
{code}

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. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to