[jira] [Issue Comment Edited] (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-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
[jira] [Closed] (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:all-tabpanel
]
Jacques Le Roux closed OFBIZ-4296.
--
Resolution: Fixed
Fix Version/s: SVN trunk
Release Branch 11.04
Release Branch 10.04
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
buildbot success in ASF Buildbot on ofbiz-trunk
The Buildbot has detected a restored build on builder ofbiz-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/ofbiz-trunk/builds/1855 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: isis_ubuntu Build Reason: scheduler Build Source Stamp: [branch ofbiz/trunk] 1131144 Blamelist: jleroux Build succeeded! sincerely, -The Buildbot
[jira] [Updated] (OFBIZ-4308) CalendarDateSelect Shows wrong selected date
[ https://issues.apache.org/jira/browse/OFBIZ-4308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Rufle updated OFBIZ-4308: - Attachment: OFBIZ-4308.patch Changing the standard '-' to a '/' and then letting parseFormattedString be called seems to fix the issue locally > CalendarDateSelect Shows wrong selected date > - > > Key: OFBIZ-4308 > URL: https://issues.apache.org/jira/browse/OFBIZ-4308 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Release Branch 10.04 >Reporter: Stephen Rufle > Attachments: OFBIZ-4308.patch, > OrderPurchaseReportOptions-CalendarDateSelect.jpg > > > When a date value is initially specified ex.2011-05-03 and then the calendar > is popped open the date is off by one. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (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:all-tabpanel
]
Jacques Le Roux updated OFBIZ-4296:
---
Attachment: changeset_2683.patch
A patch using just lazy initializations (use dispatcherCache), not intended to
inclusion (anyway already committed/fixed)
> 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
> 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] [Updated] (OFBIZ-4308) CalendarDateSelect Shows wrong selected date
[ https://issues.apache.org/jira/browse/OFBIZ-4308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Rufle updated OFBIZ-4308: - Attachment: OrderPurchaseReportOptions-CalendarDateSelect.jpg This shows the issue. I entered 2011-05-03, the image shows 2011-05-02 selected > CalendarDateSelect Shows wrong selected date > - > > Key: OFBIZ-4308 > URL: https://issues.apache.org/jira/browse/OFBIZ-4308 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Release Branch 10.04 >Reporter: Stephen Rufle > Attachments: OrderPurchaseReportOptions-CalendarDateSelect.jpg > > > When a date value is initially specified ex.2011-05-03 and then the calendar > is popped open the date is off by one. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4308) CalendarDateSelect Shows wrong selected date
CalendarDateSelect Shows wrong selected date - Key: OFBIZ-4308 URL: https://issues.apache.org/jira/browse/OFBIZ-4308 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 10.04 Reporter: Stephen Rufle When a date value is initially specified ex.2011-05-03 and then the calendar is popped open the date is off by one. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Freemarker Macro Library
That's an interesting approach, but it duplicates code. It would be preferable to fix the macros. -Adrian On 6/3/2011 10:26 AM, Bilgin Ibryam wrote: Hi Adrian, On Fri, Jun 3, 2011 at 6:12 AM, Adrian Crum< adrian.c...@sandglass-software.com> wrote: I'm working on a project where screen widgets can't be used and I need to use Freemarker templates instead. I would like to use the Freemarker macros found in the widget macro library, but they are cumbersome to use because they have MANY parameters - and almost all of them are set up as required parameters. The markup the macros generate requires only a handful of the parameters, and the rest of them are optional. So, I would like to work on the macro library and provide default arguments for any parameters that aren't required by the markup. Any thoughts or objections? I reused form widget lookup macros in freemarker templates using similar approach. Just create a wrapper macro with default values and then call the widget macros. For an example check how htmlTemplate.lookupField macro is used and implemented in htmlTemplate.ftl HTH Bilgin Ibryam
Re: Freemarker Macro Library
Hi Adrian, On Fri, Jun 3, 2011 at 6:12 AM, Adrian Crum < adrian.c...@sandglass-software.com> wrote: > I'm working on a project where screen widgets can't be used and I need to > use Freemarker templates instead. I would like to use the Freemarker macros > found in the widget macro library, but they are cumbersome to use because > they have MANY parameters - and almost all of them are set up as required > parameters. The markup the macros generate requires only a handful of the > parameters, and the rest of them are optional. So, I would like to work on > the macro library and provide default arguments for any parameters that > aren't required by the markup. Any thoughts or objections? > I reused form widget lookup macros in freemarker templates using similar approach. Just create a wrapper macro with default values and then call the widget macros. For an example check how htmlTemplate.lookupField macro is used and implemented in htmlTemplate.ftl HTH Bilgin Ibryam
