[jira] [Commented] (OFBIZ-4296) JmsTopicListener started twice when distributed-cache-clear is active
[
https://issues.apache.org/jira/browse/OFBIZ-4296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13117078#comment-13117078
]
Sascha Rodekamp commented on OFBIZ-4296:
Hm guys in my opinion the code in the JmsListenerFactory could be improved:
Creating a Singelton in Java with the double lock is not necessarily thread
safe!!
The reason is the JVM memory model.
I prefer to use a eager creation without synchronization overhead:
{code}
public static JmsListenerFactory getInstance(ServiceDispatcher dispatcher) {
if (Holder.serviceDispatcher == null) {
Holder.serviceDispatcher = dispatcher;
}
return Holder.JLF;
}
private static class Holder {
private static ServiceDispatcher serviceDispatcher = null;
private static final JmsListenerFactory JLF = new
JmsListenerFactory(serviceDispatcher);
}
{code}
The JmsListenerFactory is created when the Holder JLF variable is called first.
Any opinions?
Sascha
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
[jira] [Commented] (OFBIZ-4296) JmsTopicListener started twice when distributed-cache-clear is active
[
https://issues.apache.org/jira/browse/OFBIZ-4296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[jira] [Commented] (OFBIZ-4296) JmsTopicListener started twice when distributed-cache-clear is active
[
https://issues.apache.org/jira/browse/OFBIZ-4296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[jira] [Commented] (OFBIZ-4296) JmsTopicListener started twice when distributed-cache-clear is active
[
https://issues.apache.org/jira/browse/OFBIZ-4296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13117102#comment-13117102
]
Dimitri Unruh commented on OFBIZ-4296:
--
Let's start do diskuss this things here OFBIZ-4453
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
[jira] [Commented] (OFBIZ-4296) JmsTopicListener started twice when distributed-cache-clear is active
[
https://issues.apache.org/jira/browse/OFBIZ-4296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[jira] [Commented] (OFBIZ-4296) JmsTopicListener started twice when distributed-cache-clear is active
[
https://issues.apache.org/jira/browse/OFBIZ-4296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13109371#comment-13109371
]
Jacques Le Roux commented on OFBIZ-4296:
Dimitri,
In case you activate DCC your patch does not work: any JMS listener is
created...
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
[jira] [Commented] (OFBIZ-4296) JmsTopicListener started twice when distributed-cache-clear is active
[
https://issues.apache.org/jira/browse/OFBIZ-4296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107749#comment-13107749
]
Dimitri Unruh commented on OFBIZ-4296:
--
Jacques,
thank you for your comment.
I provided a new patch to resolve the listener problem.
Anyway, I would like to do some JMS handling improvements/refactoring and will
open a new ticket for this
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
[jira] [Commented] (OFBIZ-4296) JmsTopicListener started twice when distributed-cache-clear is active
[
https://issues.apache.org/jira/browse/OFBIZ-4296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13106020#comment-13106020
]
Dimitri Unruh commented on OFBIZ-4296:
--
Hi everybody,
I guess we should open this issue again and revert the provided patch (r1131144
in trunk).
The solution looks really strange. The result at the moment starts just one
JmsTopicListener, but only if you activated DistributedCacheClear.
With no DistributionCacheClear JMS is not working anymore.
So in my opinion the problem is not resolved, it is justed deferred to another
place.
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
[jira] [Commented] (OFBIZ-4296) JmsTopicListener started twice when distributed-cache-clear is active
[
https://issues.apache.org/jira/browse/OFBIZ-4296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13039660#comment-13039660
]
Martin Kreidenweis commented on OFBIZ-4296:
---
Another thing we noticed when we looked at the problem: Prior to
[r1090952|https://fisheye6.atlassian.com/changelog/ofbiz?cs=1090952] the DCC
was initialized before the ECA handlers. Now it is the other way round. Don't
know it this was intended and/or could be a problem.
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
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
