[jira] [Commented] (OFBIZ-10641) Error in GetLocaleListTests.java
[
https://issues.apache.org/jira/browse/OFBIZ-10641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676969#comment-16676969
]
Jacques Le Roux commented on OFBIZ-10641:
-
First try at revision: 1845933
> Error in GetLocaleListTests.java
> -
>
> Key: OFBIZ-10641
> URL: https://issues.apache.org/jira/browse/OFBIZ-10641
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
>
> As reported in OFBIZ-10458:
> A test error related to GetLocaleListTests.java seems to happen only(?) on a
> fresh trunk install when running unit tests. For instance it always happens
> on trunk demo, and sometimes locally when clearing all and restarting, while
> testing for instance. Here is the error:
> {code:java}
> 2018-11-06 03:01:48,777 |Test worker |ComponentLocationResolver
> |E| Could not get root location for component with name [base], error was:
> org.apache.ofbiz.base.component.ComponentException: No component found named
> : base
> org.apache.ofbiz.base.component.ComponentException: No component found named
> : base
> at
> org.apache.ofbiz.base.component.ComponentConfig.getComponentConfig(ComponentConfig.java:260)
> ~[main/:?]
> at
> org.apache.ofbiz.base.component.ComponentConfig.getComponentConfig(ComponentConfig.java:241)
> ~[main/:?]
> at
> org.apache.ofbiz.base.component.ComponentConfig.getRootLocation(ComponentConfig.java:288)
> ~[main/:?]
> at
> org.apache.ofbiz.base.location.ComponentLocationResolver.getBaseLocation(ComponentLocationResolver.java:67)
> [main/:?]
> at
> org.apache.ofbiz.base.location.ComponentLocationResolver.resolveLocation(ComponentLocationResolver.java:41)
> [main/:?]
> at
> org.apache.ofbiz.base.location.FlexibleLocation.resolveLocation(FlexibleLocation.java:117)
> [main/:?]
> at
> org.apache.ofbiz.base.location.FlexibleLocation.resolveLocation(FlexibleLocation.java:103)
> [main/:?]
> at
> org.apache.ofbiz.base.util.GroovyUtil.getScriptClassFromLocation(GroovyUtil.java:154)
> [main/:?]
> at
> org.apache.ofbiz.base.util.GroovyUtil.runScriptAtLocation(GroovyUtil.java:206)
> [main/:?]
> at org.apache.ofbiz.base.util.GroovyUtil.(GroovyUtil.java:66)
> [main/:?]
> at
> org.apache.ofbiz.common.GetLocaleListTests.runScript(GetLocaleListTests.java:51)
> [test/:?]
> at
> org.apache.ofbiz.common.GetLocaleListTests.frenchLocaleName(GetLocaleListTests.java:64)
> [test/:?]
> [...]
> {code}
> It's no stopping tests. I'm not sure yet if R17 is concerned (did not try).
> Mathieu suggested to
> {quote}replace the location {{component://base/config/GroovyInit.groovy}}
> with {{ofbizhome://framework/base/config/GroovyInit.groovy}}
> {quote}
> because
> {quote}{{GroovyUtil}} [should not] depend on the component container in the
> first place
> {quote}
> in GroovyUtil.java and it seems to work. Committing and checking trunk demo
> error.log should do the trick. Then I'll check for R17 locally.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10592) OutOfMemory and stucked JobPoller issue
[ https://issues.apache.org/jira/browse/OFBIZ-10592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676970#comment-16676970 ] Shi Jinghai commented on OFBIZ-10592: - Inspired by two articles[1][2] recently I read on db automatic tuning, I think perhaps we should consider to implement an automatic tuning on OFBiz entity engine. [1] [https://docs.microsoft.com/en-us/azure/sql-database/sql-database-automatic-tuning] [2]https://brage.bibsys.no/xmlui/bitstream/handle/11250/2506148/19718_FULLTEXT.pdf > OutOfMemory and stucked JobPoller issue > --- > > Key: OFBIZ-10592 > URL: https://issues.apache.org/jira/browse/OFBIZ-10592 > Project: OFBiz > Issue Type: Bug > Components: ALL APPLICATIONS >Affects Versions: Release Branch 13.07 > Environment: Two instances Ofbiz installation on two machines, > connected to an Apache HTTPD instance which acts as a proxy. > Request to ofbiz instances are handled and load balanced. > OFBiz version : 13.07.03 with Multitenant enabled > OS: Ubuntu Linux 16.04 LTS > RDBMS: MariaDB v10.1.24 >Reporter: Giulio Speri >Assignee: Giulio Speri >Priority: Critical > Attachments: alloc_tree_600k_12102018.png, > jvm_ofbiz1_profi_telem.png, jvm_prof_ofbiz1_telem2.png, > ofbiz1_jvm_profil_nojobpoller.png, recorder_object_600k_12102018.png, > telemetry_ovrl_600k_12102018.png > > > > This installation is composed by two instances of OFBiz (v13.07.03), served > via an Apache Tomcat webserver, along with a load balancer. > The database server is MariaDB. > > We had the first problems, about 3 weeks ago, when suddenly, the front1 > (ofbiz instance 1), stopped serving web requests; front2, instead, was still > working correctly. > > Obviously we checked the log files, and we saw that async services were > failing; the failure was accompanied by this error line: > > *_Thread "AsyncAppender-async" java.lang.OutOfMemoryError: GC overhead limit > exceeded_* > > We analyzed the situation with our system specialists, and they told us that > the application was highly stressing machine resources (cpu always at or near > 100%, RAM usage rapidly increasing), until the jvm run out of memory. > This "resource-high-consumption situation", occurred only when ofbiz1 > instance was started with the JobPoller enabled; if the JobPoller was not > enabled, ofbiz run with low resource usage. > > We then focused on the db, to check first of all the dimensions; the result > was disconcerting; 45GB, mainly divided on four tables: SERVER_HIT (about 18 > GB), VISIT (about 15 GB), ENTITY_SYNC_REMOVE (about 8 GB), VISITOR (about 2 > GB). > All the other tables had a size in the order of few MB each. > > The first thing we did, was to clear all those tables, reducing considerably > the db size. > After the cleaning, we tried to start ofbiz1 again, with the JobPoller > component enabled; this caused a lot of old scheduled/queued jobs, to execute. > Except than for the start-up time, the resource usage of the machine, > stabilized around normal to low values (cpu 1-10%). > Ofbiz seemed to work (web request was served), but we noticed taht the > JobPoller did not schedule or run jobs, anymore. > The number of job in "Pending" state in the JobSandbox entity was small > (about 20); no Queued, no Failed, no jobs in other states. > In addition to this, unfortunately, after few hours, jvm run out of memory > again. > > Our jvm has an heap maximum size of 20GB ( we have 32GB on the machine), so > it's not so small, I think. > The next step we're going to do is set-up locally the application over the > same production db to see what happens. > > Now that I explained the situation, I am going to ask if, in your > opinion/experience: > > Could the JobPoller component be the root (and only) cause of the OutOfMemory > of the jvm? > > Could this issue be related to OFBIZ-5710? > > Dumping and analyzing the heap of the jvm could help in some way to > understand what or who fills the memory or is this operation a waste of time? > > Is there something that we did not considered or missed during the whole > process of problem analysis? > > > I really thank you all for your attention and your help; any suggestion or > advice would really be greatly appreciated. > > Kind regards, > Giulio -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10641) Error in GetLocaleListTests.java
[
https://issues.apache.org/jira/browse/OFBIZ-10641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux updated OFBIZ-10641:
Description:
As reported in OFBIZ-10458:
A test error related to GetLocaleListTests.java seems to happen only(?) on a
fresh trunk install when running unit tests. For instance it always happens on
trunk demo, and sometimes locally when clearing all and restarting, while
testing for instance. Here is the error:
{code:java}
2018-11-06 03:01:48,777 |Test worker |ComponentLocationResolver
|E| Could not get root location for component with name [base], error was:
org.apache.ofbiz.base.component.ComponentException: No component found named :
base
org.apache.ofbiz.base.component.ComponentException: No component found named :
base
at
org.apache.ofbiz.base.component.ComponentConfig.getComponentConfig(ComponentConfig.java:260)
~[main/:?]
at
org.apache.ofbiz.base.component.ComponentConfig.getComponentConfig(ComponentConfig.java:241)
~[main/:?]
at
org.apache.ofbiz.base.component.ComponentConfig.getRootLocation(ComponentConfig.java:288)
~[main/:?]
at
org.apache.ofbiz.base.location.ComponentLocationResolver.getBaseLocation(ComponentLocationResolver.java:67)
[main/:?]
at
org.apache.ofbiz.base.location.ComponentLocationResolver.resolveLocation(ComponentLocationResolver.java:41)
[main/:?]
at
org.apache.ofbiz.base.location.FlexibleLocation.resolveLocation(FlexibleLocation.java:117)
[main/:?]
at
org.apache.ofbiz.base.location.FlexibleLocation.resolveLocation(FlexibleLocation.java:103)
[main/:?]
at
org.apache.ofbiz.base.util.GroovyUtil.getScriptClassFromLocation(GroovyUtil.java:154)
[main/:?]
at
org.apache.ofbiz.base.util.GroovyUtil.runScriptAtLocation(GroovyUtil.java:206)
[main/:?]
at org.apache.ofbiz.base.util.GroovyUtil.(GroovyUtil.java:66)
[main/:?]
at
org.apache.ofbiz.common.GetLocaleListTests.runScript(GetLocaleListTests.java:51)
[test/:?]
at
org.apache.ofbiz.common.GetLocaleListTests.frenchLocaleName(GetLocaleListTests.java:64)
[test/:?]
[...]
{code}
It's no stopping tests. I'm not sure yet if R17 is concerned (did not try).
Mathieu suggested to
{quote}replace the location {{component://base/config/GroovyInit.groovy}} with
{{ofbizhome://framework/base/config/GroovyInit.groovy}}
{quote}
because
{quote}{{GroovyUtil}} [should not] depend on the component container in the
first place
{quote}
in GroovyUtil.java and it seems to work. Committing and checking trunk demo
error.log should do the trick. Then I'll check for R17 locally.
was:
As reported in OFBIZ-10458:
A test error related to GetLocaleListTests.java seems to happen only(?) on a
fresh trink install when running unit tests. For instance it always happens on
trunk demo, and sometimes locally when clearing all and restarting, while
testing for instance. Here is the error:
{code}
2018-11-06 03:01:48,777 |Test worker |ComponentLocationResolver
|E| Could not get root location for component with name [base], error was:
org.apache.ofbiz.base.component.ComponentException: No component found named :
base
org.apache.ofbiz.base.component.ComponentException: No component found named :
base
at
org.apache.ofbiz.base.component.ComponentConfig.getComponentConfig(ComponentConfig.java:260)
~[main/:?]
at
org.apache.ofbiz.base.component.ComponentConfig.getComponentConfig(ComponentConfig.java:241)
~[main/:?]
at
org.apache.ofbiz.base.component.ComponentConfig.getRootLocation(ComponentConfig.java:288)
~[main/:?]
at
org.apache.ofbiz.base.location.ComponentLocationResolver.getBaseLocation(ComponentLocationResolver.java:67)
[main/:?]
at
org.apache.ofbiz.base.location.ComponentLocationResolver.resolveLocation(ComponentLocationResolver.java:41)
[main/:?]
at
org.apache.ofbiz.base.location.FlexibleLocation.resolveLocation(FlexibleLocation.java:117)
[main/:?]
at
org.apache.ofbiz.base.location.FlexibleLocation.resolveLocation(FlexibleLocation.java:103)
[main/:?]
at
org.apache.ofbiz.base.util.GroovyUtil.getScriptClassFromLocation(GroovyUtil.java:154)
[main/:?]
at
org.apache.ofbiz.base.util.GroovyUtil.runScriptAtLocation(GroovyUtil.java:206)
[main/:?]
at org.apache.ofbiz.base.util.GroovyUtil.(GroovyUtil.java:66)
[main/:?]
at
org.apache.ofbiz.common.GetLocaleListTests.runScript(GetLocaleListTests.java:51)
[test/:?]
at
org.apache.ofbiz.common.GetLocaleListTests.frenchLocaleName(GetLocaleListTests.java:64)
[test/:?]
[...]
{code}
It's no stopping tests. I'm not sure yet if R17 is concerned (did not try).
Mathieu suggested to
{quote}
replace the location {{component://base/config/GroovyInit.groovy}} with
{{ofbizhome://framework/base/config/GroovyInit.groovy}}
{quote}
because
{quote}
{{GroovyUtil}}
[jira] [Created] (OFBIZ-10641) Error in GetLocaleListTests.java
Jacques Le Roux created OFBIZ-10641:
---
Summary: Error in GetLocaleListTests.java
Key: OFBIZ-10641
URL: https://issues.apache.org/jira/browse/OFBIZ-10641
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: Trunk
Reporter: Jacques Le Roux
Assignee: Jacques Le Roux
Fix For: Upcoming Branch
As reported in OFBIZ-10458:
A test error related to GetLocaleListTests.java seems to happen only(?) on a
fresh trink install when running unit tests. For instance it always happens on
trunk demo, and sometimes locally when clearing all and restarting, while
testing for instance. Here is the error:
{code}
2018-11-06 03:01:48,777 |Test worker |ComponentLocationResolver
|E| Could not get root location for component with name [base], error was:
org.apache.ofbiz.base.component.ComponentException: No component found named :
base
org.apache.ofbiz.base.component.ComponentException: No component found named :
base
at
org.apache.ofbiz.base.component.ComponentConfig.getComponentConfig(ComponentConfig.java:260)
~[main/:?]
at
org.apache.ofbiz.base.component.ComponentConfig.getComponentConfig(ComponentConfig.java:241)
~[main/:?]
at
org.apache.ofbiz.base.component.ComponentConfig.getRootLocation(ComponentConfig.java:288)
~[main/:?]
at
org.apache.ofbiz.base.location.ComponentLocationResolver.getBaseLocation(ComponentLocationResolver.java:67)
[main/:?]
at
org.apache.ofbiz.base.location.ComponentLocationResolver.resolveLocation(ComponentLocationResolver.java:41)
[main/:?]
at
org.apache.ofbiz.base.location.FlexibleLocation.resolveLocation(FlexibleLocation.java:117)
[main/:?]
at
org.apache.ofbiz.base.location.FlexibleLocation.resolveLocation(FlexibleLocation.java:103)
[main/:?]
at
org.apache.ofbiz.base.util.GroovyUtil.getScriptClassFromLocation(GroovyUtil.java:154)
[main/:?]
at
org.apache.ofbiz.base.util.GroovyUtil.runScriptAtLocation(GroovyUtil.java:206)
[main/:?]
at org.apache.ofbiz.base.util.GroovyUtil.(GroovyUtil.java:66)
[main/:?]
at
org.apache.ofbiz.common.GetLocaleListTests.runScript(GetLocaleListTests.java:51)
[test/:?]
at
org.apache.ofbiz.common.GetLocaleListTests.frenchLocaleName(GetLocaleListTests.java:64)
[test/:?]
[...]
{code}
It's no stopping tests. I'm not sure yet if R17 is concerned (did not try).
Mathieu suggested to
{quote}
replace the location {{component://base/config/GroovyInit.groovy}} with
{{ofbizhome://framework/base/config/GroovyInit.groovy}}
{quote}
because
{quote}
{{GroovyUtil}} [should not] depend on the component container in the first place
{quote}
in GroovyUtil.java and it seems to work. Committing and checking trunk demo
error.log should do the trick. Then I'll check for R17 locally.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OFBIZ-10458) GetLocaleList call can provide duplicate results
[
https://issues.apache.org/jira/browse/OFBIZ-10458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux updated OFBIZ-10458:
Component/s: framework
> GetLocaleList call can provide duplicate results
>
>
> Key: OFBIZ-10458
> URL: https://issues.apache.org/jira/browse/OFBIZ-10458
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Reporter: Mathieu Lirzin
>Assignee: Gil Portenseigne
>Priority: Minor
> Fix For: 17.12.01, 16.11.05
>
> Attachments: OFBIZ-10458_0001-Add-failing-tests.patch,
> OFBIZ-10458_0002-Fix-duplicates-bug.patch, OFBIZ-10458_0003-Refactor.patch
>
>
> This is not a huge issue but I detected an issue with the {{GetLocaleList}}
> script which when providing both a {{localeString}} and {{localeName}} can
> provide duplicate results.
> Here is a set of 3 patches that should be applied in order:
> - the first one is adding some tests with a failing one which identifies the
> bug
> - the second one resolves the bug
> - the third one refactors the code to use a more functional style
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OFBIZ-10640) Update ProductStore throws exceptions and results in messed up view
Benjamin Jugl created OFBIZ-10640:
-
Summary: Update ProductStore throws exceptions and results in
messed up view
Key: OFBIZ-10640
URL: https://issues.apache.org/jira/browse/OFBIZ-10640
Project: OFBiz
Issue Type: Bug
Components: ecommerce, framework
Affects Versions: Trunk
Reporter: Benjamin Jugl
This happened on demo-trunk:
What I did:
Catalog->Stores->Choose a Store->Click on "Update"-Button (regardless if
changes had.been made or not)
What I expected to happen:
The Page reloads. If any changes had been made these would have been processed.
What happened instead
A messed up view with almost no layout appears.
The navbarContent contains following Error Message:
{{The following has evaluated to null or missing: ==> catalogQuickaddUse [in
template "component://ecommerce/template/includes/Header.ftl" at line 108,
column 12] Tip: If the failing expression is known to legally refer to
something that's sometimes null or missing, either specify a default value like
myOptionalVar!myDefault, or use <#if
myOptionalVar??>when-present<#else>when-missing. (These only cover the last
step of the expression; to cover the whole expression, use parenthesis:
(myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? FTL stack trace
("~" means nesting-related): - Failed at: #if catalogQuickaddUse [in template
"component://ecommerce/template/includes/Header.ftl" at line 108, column 7]
}}
Further down in the document there is an error-message div, stating:
{{The Following Errors Occurred:}}
{{Error running the simple-method: Entity value not found with name: store
Method = updateProductStore, File =
file:/home/ofbizDemo/trunk/applications/product/minilang/product/store/ProductStoreServices.xml,
Element = , Line 90null}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10606) Webapp related code should be extracted from ‘ComponentConfig’
[
https://issues.apache.org/jira/browse/OFBIZ-10606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676431#comment-16676431
]
Jacques Le Roux commented on OFBIZ-10606:
-
Hi Mathieu,
In a 1st step here is the JavaDoc and comments for the
WebAppCache::getAppBarWebInfos.
I noticed that, unlike other themes, Rainbowstone does not use
LoginWorker::getAppBarWebInfos. I did not look into details and I guess access
permissions are handled another way, but this should be checked.
> Webapp related code should be extracted from ‘ComponentConfig’
> ---
>
> Key: OFBIZ-10606
> URL: https://issues.apache.org/jira/browse/OFBIZ-10606
> Project: OFBiz
> Issue Type: Improvement
> Components: base
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-10606_0001-Add-WebAppCache.patch,
> OFBIZ-10606_0001-Add-WebAppCache.patch,
> OFBIZ-10606_0002-Add-tests-for-WebAppCache.patch,
> OFBIZ-10606_0003-Refactor-WebAppCache.patch,
> OFBIZ-10606_0004-Inline-getAppBarWebInfos-String-Comparator-String-pr.patch
>
>
> The {{ComponentConfig}} mixes various concerns which should be separated to
> make the code more understandable. The method touching the {{serverWebApps}}
> static member could be put in a separated class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OFBIZ-10606) Webapp related code should be extracted from ‘ComponentConfig’
[
https://issues.apache.org/jira/browse/OFBIZ-10606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux updated OFBIZ-10606:
Attachment: OFBIZ-10606_0001-Add-WebAppCache.patch
> Webapp related code should be extracted from ‘ComponentConfig’
> ---
>
> Key: OFBIZ-10606
> URL: https://issues.apache.org/jira/browse/OFBIZ-10606
> Project: OFBiz
> Issue Type: Improvement
> Components: base
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-10606_0001-Add-WebAppCache.patch,
> OFBIZ-10606_0001-Add-WebAppCache.patch,
> OFBIZ-10606_0002-Add-tests-for-WebAppCache.patch,
> OFBIZ-10606_0003-Refactor-WebAppCache.patch,
> OFBIZ-10606_0004-Inline-getAppBarWebInfos-String-Comparator-String-pr.patch
>
>
> The {{ComponentConfig}} mixes various concerns which should be separated to
> make the code more understandable. The method touching the {{serverWebApps}}
> static member could be put in a separated class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
