[ https://issues.apache.org/jira/browse/OFBIZ-4296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13117082#comment-13117082 ]
Dimitri Unruh commented on OFBIZ-4296: -------------------------------------- Sascha, I know what you mean and I agree with you. But anyway, this was just a "hot-fix" for the current problem. As I mentioned before, I would like to do some refactoring with the hole JMS handling, because there are some more "strange" things :) So, we could do it together. What dou you think? ;) > 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