[ 
https://issues.apache.org/jira/browse/OFBIZ-4296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13117083#comment-13117083
 ] 

Adrian Crum commented on OFBIZ-4296:
------------------------------------

Another thing to look at is the bug where the JMS listener is created even when 
you configure OFBiz to have JMS disabled. There is no way to shut it off.

                
> 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
>            Assignee: Jacques Le Roux
>             Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk
>
>         Attachments: OFBIZ-4296.patch, changeset_2683.patch
>
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to