[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=16635815#comment-16635815 ] Jacques Le Roux commented on OFBIZ-10592: - No worries Giulio, I changed the env. part. > 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 > > > 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-10592) OutOfMemory and stucked JobPoller issue
[ https://issues.apache.org/jira/browse/OFBIZ-10592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-10592: 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 was: Two instances Ofbiz installation on two machines, connected to an Apache Tomcat, connected via a proxy. Request to ofbiz instances are handled and dispatched by a load balancer. OFBiz version : 13.07.03 with Multitenant enabled OS: Ubuntu Linux 16.04 LTS RDBMS: MariaDB v10.1.24 > 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 > > > 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] [Assigned] (OFBIZ-10589) Update Solr and Lucene from 7.3.1 to Solr 7.5.0
[
https://issues.apache.org/jira/browse/OFBIZ-10589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux reassigned OFBIZ-10589:
---
Assignee: (was: Jacques Le Roux)
> Update Solr and Lucene from 7.3.1 to Solr 7.5.0
> ---
>
> Key: OFBIZ-10589
> URL: https://issues.apache.org/jira/browse/OFBIZ-10589
> Project: OFBiz
> Issue Type: Task
> Components: lucene, solr
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
>
> I did not find any help to migrate but got some information in log while
> trying in both product search (Lucene) and Solr component. This comes from
> the Solr log when using solrDefault core:
>
> |30/09/2018 à 12:06:22|WARN false|x:solrdefault|SolrResourceLoader|Solr
> loaded a deprecated plugin/analysis class [solr.TrieIntField]. Please consult
> documentation how to replace it accordingly.|
> |30/09/2018 à 12:06:22|WARN false|x:solrdefault|SolrResourceLoader|Solr
> loaded a deprecated plugin/analysis class [solr.TrieFloatField]. Please
> consult documentation how to replace it accordingly.|
> |30/09/2018 à 12:06:22|WARN false|x:solrdefault|SolrResourceLoader|Solr
> loaded a deprecated plugin/analysis class [solr.TrieLongField]. Please
> consult documentation how to replace it accordingly.|
> |30/09/2018 à 12:06:23|WARN false|x:solrdefault|SolrResourceLoader|Solr
> loaded a deprecated plugin/analysis class [solr.TrieDoubleField]. Please
> consult documentation how to replace it accordingly.|
> |30/09/2018 à 12:06:23|WARN false|x:solrdefault|SolrResourceLoader|Solr
> loaded a deprecated plugin/analysis class [solr.TrieDateField]. Please
> consult documentation how to replace it accordingly.|
> |30/09/2018 à 12:06:23|WARN false|x:solrdefault|SolrResourceLoader|Solr
> loaded a deprecated plugin/analysis class [solr.ManagedSynonymFilterFactory].
> Please consult documentation how to replace it accordingly.|
> |30/09/2018 à 12:06:23|WARN false|x:solrdefault|SolrResourceLoader|Solr
> loaded a deprecated plugin/analysis class [solr.LatLonType]. Please consult
> documentation how to replace it accordingly.|
> |30/09/2018 à 12:06:23|WARN false|x:solrdefault|SolrResourceLoader|Solr
> loaded a deprecated plugin/analysis class [solr.CurrencyField]. Please
> consult documentation how to replace it accordingly.|
> I also got this recurring warning message ("Received a null Security object
> from HttpServletRequest"). Not sure it's really an issue
> {quote}2018-09-30 12:01:14,554 |jsse-nio-8443-exec-4 |ControlServlet |T|
> [[[keywordsearch(Domain:https://localhost)] Request Done- total:1.248,since
> last([keywordsearch(Do...):1.248]]
> 2018-09-30 12:01:17,081 |jsse-nio-8443-exec-2 |LoginWorker |W| Received a
> null Security object from HttpServletRequest
> 2018-09-30 12:01:17,081 |jsse-nio-8443-exec-2 |OFBizSolrContextFilter |T|
> [[[solr/admin/info/logging(Domain:https://localhost)] Request Begun,
> encoding=[null]- total:0.0,since last(Begin):0.0]]
> 2018-09-30 12:01:17,082 |jsse-nio-8443-exec-2 |OFBizSolrContextFilter |T|
> [[[solr/admin/info/logging(Domain:https://localhost)] Request Done-
> total:0.001,since last([solr/admin/info/...):0.001]]
> {quote}
--
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=16635690#comment-16635690 ] Giulio Speri commented on OFBIZ-10592: -- Hi Jacques, sorry I miswrote. Ofbiz instances use the integrated Tomcat and they are connected to an external Apache Web Server, that also act as proxy. > 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 Tomcat, connected via a proxy. > Request to ofbiz instances are handled and dispatched by a load balancer. > 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 > > > 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] [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=16635625#comment-16635625 ] Jacques Le Roux commented on OFBIZ-10592: - HI Giulio, I don't think it's related but you say bq. Two instances Ofbiz installation on two machines, connected to an Apache Tomcat, connected via a proxy. So does it mean that you are not using the embedded Tomcat in your 2 OFBiz instances but that they are rather sharing a stand alone Apache Tomcat? > 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 Tomcat, connected via a proxy. > Request to ofbiz instances are handled and dispatched by a load balancer. > 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 > > > 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-10592) OutOfMemory and stucked JobPoller issue
[ https://issues.apache.org/jira/browse/OFBIZ-10592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-10592: Description: 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 was: 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,
[jira] [Created] (OFBIZ-10592) OutOfMemory and stucked JobPoller issue
Giulio Speri created OFBIZ-10592: Summary: 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 Tomcat, connected via a proxy. Request to ofbiz instances are handled and dispatched by a load balancer. 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 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 this https://issues.apache.org/jira/browse/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] [Commented] (OFBIZ-10307) Navigate from a domain to another with automated signed in authentication
[ https://issues.apache.org/jira/browse/OFBIZ-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16635445#comment-16635445 ] Jacques Le Roux commented on OFBIZ-10307: - Hi Taher, Most certainly due to my journey in IT, I must say that most often I prefer to embrace all a method code rather than having to move from sub-methods back and forth. Of course as long as the main method is not too long, say less than 50 lines. For instance I easily read checkExternalLoginKey, from which I was inspired. But I'm not against the idea of private methods, far from it. It's one of the goal of refactoring after all. And I agree my initial code was far from perfect. So I gave it a try following your suggestions. What do you think about the last patch? BTW about bq. Return error or return success could have one location only within the logic I don't see how this could be done > Navigate from a domain to another with automated signed in authentication > - > > Key: OFBIZ-10307 > URL: https://issues.apache.org/jira/browse/OFBIZ-10307 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Major > Fix For: Upcoming Branch > > Attachments: OFBIZ-10307-test from example.patch, OFBIZ-10307-test > from example.patch, OFBIZ-10307-test from example.patch, > OFBIZ-10307-test.patch, OFBIZ-10307-test.patch, OFBIZ-10307-test.patch, > OFBIZ-10307-test.patch, OFBIZ-10307.patch, OFBIZ-10307.patch, > OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch, > OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch > > > This will use a JWT Token authentication to get from one domain, where you > are signed in, to another domain where you get signed in automatically. > Something like ExternalLoginKey or Tomcat SSO, but not on the same domain. > This will build upon the initial work done at OFBIZ-9833 which has been > partially reverted in trunk with r1827439 (see OFBIZ-10304) and r1827441. I > explained why and what I did at [https://s.apache.org/a5Km] > I turned to Ajax for the "Authorization" header sending. I initially thought > I'd just pass an "Authorization" header and use it in the > externalServerLoginCheck preprocessor, et voilà. > But I stumbled upon something I did not know well : CORS! And in particular > the upstream control (Pre-verified requests): > > [https://en.wikipedia.org/wiki/Cross-origin_resource_sharing#Preflight_example] > [https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS] > [https://www.w3.org/TR/cors/] > To be able to pass an "Authorization" header, the server must respond > positively in the Preflight HTTP response (OPTIONS). To do this, either you > use a Tomcat filter (or your own filter, there are examples on the Net) or > use HTTPD (or Nginx) configuration on the target server. > I tried Tomcat first, without success. With HTTPD it's easier just 3 lines. > For my tests, future tests by OFBiz users and as an example, I asked infra to > put them in our HTTPD trunk demo config: > Header set Access-Control-Allow-Origin "https://localhost:8443; > Header set Access-Control-Allow-Headers "Authorization" > Header set Access-Control-Allow-Credentials "true" > No code change (either in all web.xml files for Tomcat or Java for own > filter), and more safety. It does not give more right to outsiders than what > we give with the admin credential. > In Header set Access-Control-Allow-Origin you can put more domains. I just > used [https://localhost:8443|https://localhost:8443/] for the tests. > It works in Chrome, Firefox and Opera and partially in IE11 (not tested in > Edge). I did not test Safari, but I guess like other modern browsers it > should work. > For those (very few I guess) interested by IE11 (for Edge test yourself and > report please), here is the solution > > [https://stackoverflow.com/questions/12643960/internet-explorer-10-is-ignoring-xmlhttprequest-xhr-withcredentials-true] > > [https://web.archive.org/web/20130308142134/http://msdn.microsoft.com/en-us/library/ms537343%28v=vs.85%29.aspx] > > [https://blogs.msdn.microsoft.com/ieinternals/2013/09/17/a-quick-look-at-p3p/] > TODO (maybe) in the future, use the new Fetch API (not available yet): > [https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API] > > Here is a complement about the way it's architectured: > # A change to cookies was introduced with OFBIZ-4959. Actually it was not > really a bug rather a clean-up. The autoLogin cookies were only used by the > ecommerce component and maybe webpos. But all applications were creating such > cookies with a one year duration. They were useless until I needed
[jira] [Updated] (OFBIZ-10307) Navigate from a domain to another with automated signed in authentication
[ https://issues.apache.org/jira/browse/OFBIZ-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-10307: Attachment: OFBIZ-10307.patch > Navigate from a domain to another with automated signed in authentication > - > > Key: OFBIZ-10307 > URL: https://issues.apache.org/jira/browse/OFBIZ-10307 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Major > Fix For: Upcoming Branch > > Attachments: OFBIZ-10307-test from example.patch, OFBIZ-10307-test > from example.patch, OFBIZ-10307-test from example.patch, > OFBIZ-10307-test.patch, OFBIZ-10307-test.patch, OFBIZ-10307-test.patch, > OFBIZ-10307-test.patch, OFBIZ-10307.patch, OFBIZ-10307.patch, > OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch, > OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch > > > This will use a JWT Token authentication to get from one domain, where you > are signed in, to another domain where you get signed in automatically. > Something like ExternalLoginKey or Tomcat SSO, but not on the same domain. > This will build upon the initial work done at OFBIZ-9833 which has been > partially reverted in trunk with r1827439 (see OFBIZ-10304) and r1827441. I > explained why and what I did at [https://s.apache.org/a5Km] > I turned to Ajax for the "Authorization" header sending. I initially thought > I'd just pass an "Authorization" header and use it in the > externalServerLoginCheck preprocessor, et voilà. > But I stumbled upon something I did not know well : CORS! And in particular > the upstream control (Pre-verified requests): > > [https://en.wikipedia.org/wiki/Cross-origin_resource_sharing#Preflight_example] > [https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS] > [https://www.w3.org/TR/cors/] > To be able to pass an "Authorization" header, the server must respond > positively in the Preflight HTTP response (OPTIONS). To do this, either you > use a Tomcat filter (or your own filter, there are examples on the Net) or > use HTTPD (or Nginx) configuration on the target server. > I tried Tomcat first, without success. With HTTPD it's easier just 3 lines. > For my tests, future tests by OFBiz users and as an example, I asked infra to > put them in our HTTPD trunk demo config: > Header set Access-Control-Allow-Origin "https://localhost:8443; > Header set Access-Control-Allow-Headers "Authorization" > Header set Access-Control-Allow-Credentials "true" > No code change (either in all web.xml files for Tomcat or Java for own > filter), and more safety. It does not give more right to outsiders than what > we give with the admin credential. > In Header set Access-Control-Allow-Origin you can put more domains. I just > used [https://localhost:8443|https://localhost:8443/] for the tests. > It works in Chrome, Firefox and Opera and partially in IE11 (not tested in > Edge). I did not test Safari, but I guess like other modern browsers it > should work. > For those (very few I guess) interested by IE11 (for Edge test yourself and > report please), here is the solution > > [https://stackoverflow.com/questions/12643960/internet-explorer-10-is-ignoring-xmlhttprequest-xhr-withcredentials-true] > > [https://web.archive.org/web/20130308142134/http://msdn.microsoft.com/en-us/library/ms537343%28v=vs.85%29.aspx] > > [https://blogs.msdn.microsoft.com/ieinternals/2013/09/17/a-quick-look-at-p3p/] > TODO (maybe) in the future, use the new Fetch API (not available yet): > [https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API] > > Here is a complement about the way it's architectured: > # A change to cookies was introduced with OFBIZ-4959. Actually it was not > really a bug rather a clean-up. The autoLogin cookies were only used by the > ecommerce component and maybe webpos. But all applications were creating such > cookies with a one year duration. They were useless until I needed them for > the feature of this Jira issue. But even if they were safe (httponly) then I > needed them to be clean, not a one year duration (to be as safe as possible, > temporary cookies are better). So after doing it crudely, [inspired by > Taher's suggestion|[https://s.apache.org/qLGC]] I introduced the > keep-autologin-cookie attribute in ofbiz-component.xml. It's used to > remove not kept cookies when login in or out. So those cookies are only kept > during a session. Also a cookie is created when an user jumps from one > application to another on the source domain. These cookies are used when > navigating from a domain to another to guarantee the safety of the user who > jumps from the source domain
[jira] [Updated] (OFBIZ-8842) Search operation on 'AssocRevisionItemView' entity causing exception.
[ https://issues.apache.org/jira/browse/OFBIZ-8842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacopo Cappellato updated OFBIZ-8842: - Fix Version/s: (was: 16.11.05) 16.11.06 > Search operation on 'AssocRevisionItemView' entity causing exception. > - > > Key: OFBIZ-8842 > URL: https://issues.apache.org/jira/browse/OFBIZ-8842 > Project: OFBiz > Issue Type: Bug > Components: framework/webtools >Affects Versions: Trunk >Reporter: Humera Khan >Assignee: Suraj Khurana >Priority: Major > Fix For: 17.12.01, 16.11.06 > > Attachments: Assoc_Actual.png, Assoc_Expected.png, OFBIZ-8842.patch > > > Steps to regenerate : > 1. Go to Entity Data Maintenance in webtools. > 2. Search entity 'AssocRevisionItemView'. Click on it and go to the overview > page. > 3. Click on the Find button. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
