[
https://issues.apache.org/jira/browse/OFBIZ-4296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113313#comment-13113313
]
Dimitri Unruh commented on OFBIZ-4296:
--------------------------------------
this is strange...
I just tried it and it works fine for me
{code}
2011-09-23 12:02:14,611 (main) [ BirtContainer.java:72 :INFO ] Start birt
container
2011-09-23 12:02:14,631 (main) [ GenericDispatcher.java:69 :INFO ] Creating
new dispatcher [birt-dispatcher] (main)
2011-09-23 12:02:14,635 (main) [ BirtContainer.java:130:INFO ] Startup
birt platform
2011-09-23 12:02:15,198 (org.ofbiz.service.jms.JmsListenerFactory@1d8f1a8) [
JmsListenerFactory.java:89 :INFO ] JMS Listener Factory Thread Finished; All
listeners connected.
2011-09-23 12:02:16,415 (main) [ BirtContainer.java:137:INFO ] Create
factory object
2011-09-23 12:02:16,462 (main) [ BirtContainer.java:143:INFO ] Create
report engine
{code}
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
