[jira] [Issue Comment Edited] (OFBIZ-4296) JmsTopicListener started twice when distributed-cache-clear is active

["Jacques Le Roux (JIRA)" <ji...@apache.org>]

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

Jacques Le Roux edited comment on OFBIZ-4296 at 6/3/11 9:33 PM:
----------------------------------------------------------------

Thanks Martin,

Your comments helped a lot. It's fixed at 
r1131144 in trunk
r1131163 in R10.04
r1131164 in R11.04

I 1st tried the lazy init solution (see attached patch) but there was a little overhead.


      was (Author: jacques.le.roux):
    Thanks Martin,

Your comments helped a lot. It's fixed at 
r1131144 in trunk
r1131163 in R10.04
r1131164 in R11.04

I 1st tried the lazy init solution (see patch attaches) but there was a little overhead.

  
> 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: 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira