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
