Re: Issue loading solr component [was Re: Issue when debugging with Eclipse]
Fixed Le 17/08/2019 à 09:00, Jacques Le Roux a écrit : I have created OFBIZ-11156 for this issue Jacques Le 14/08/2019 à 14:42, Jacques Le Roux a écrit : This is due to the Solr component Checking what I can do Jacques Le 14/08/2019 à 12:51, Jacques Le Roux a écrit : Hi Girish, Yes I think I'll go this way indeed. I tried to run R17 and R18 locally no issues. Even reverting changes for OFBIZ-11151 does not help Jacques Le 14/08/2019 à 12:40, Girish Vasmatkar a écrit : Hi Jacques Hooking up OFBiz with a profiler should help as to which method (eventually leading to the dependency/API) is taking a lot of time helping narrowing down the cause. Not sure if you want to go down this road, but it may help. Best, Girish On Wed, Aug 14, 2019 at 3:56 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: This is due to logging, here it a sample from trunk demo log (to be sure it's not on my machine): 2019-08-14 03:06:57,734 |main |ConfigXMLReader |I| controller loaded: 0.009s, 207 requests, 81 views in file:/home/ofbizDemo/trunk/plugins/scrum/webapp/scrum/WEB-INF/controller.xml 2019-08-14 03:06:59,831 |main |log |I| Logging initialized @54684ms to org.eclipse.jetty.util.log.Slf4jLog 2019-08-14 03:07:00,052 |main |config |W| Trusting all certificates configured for Client@4da6d664[provider=null,keyStore=null,trustStore=null] After my change in OFBIZ-11151 I tried to revert to log4j-api:2.11.2 But still got this locally after 2019-08-14 11:31:34,409 |main |log |I| Logging initialized @269930ms to org.eclipse.jetty.util.log.Slf4jLog Since there is not this problem in stable demo, I reverted to log4j-api:2.6.2 but got the same type of issue I then ran R16 locally and there was no issue. So it's something else than just log4j-api version. I continue... Jacques Le 14/08/2019 à 11:08, Jacques Le Roux a écrit : The issue I initially reported (stop after loading scrum controller) also happens to me in console now, still investigating... Jacques Le 13/08/2019 à 18:57, Mathieu Lirzin a écrit : Hello, Jacques Le Roux writes: Yes it was much faster before (but before what???), as fast as running it in console. Seems like a good scenario for a ‘git bisect’. ;-)
Issue loading solr component [was Re: Issue when debugging with Eclipse]
I have created OFBIZ-11156 for this issue Jacques Le 14/08/2019 à 14:42, Jacques Le Roux a écrit : This is due to the Solr component Checking what I can do Jacques Le 14/08/2019 à 12:51, Jacques Le Roux a écrit : Hi Girish, Yes I think I'll go this way indeed. I tried to run R17 and R18 locally no issues. Even reverting changes for OFBIZ-11151 does not help Jacques Le 14/08/2019 à 12:40, Girish Vasmatkar a écrit : Hi Jacques Hooking up OFBiz with a profiler should help as to which method (eventually leading to the dependency/API) is taking a lot of time helping narrowing down the cause. Not sure if you want to go down this road, but it may help. Best, Girish On Wed, Aug 14, 2019 at 3:56 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: This is due to logging, here it a sample from trunk demo log (to be sure it's not on my machine): 2019-08-14 03:06:57,734 |main |ConfigXMLReader |I| controller loaded: 0.009s, 207 requests, 81 views in file:/home/ofbizDemo/trunk/plugins/scrum/webapp/scrum/WEB-INF/controller.xml 2019-08-14 03:06:59,831 |main |log |I| Logging initialized @54684ms to org.eclipse.jetty.util.log.Slf4jLog 2019-08-14 03:07:00,052 |main |config |W| Trusting all certificates configured for Client@4da6d664[provider=null,keyStore=null,trustStore=null] After my change in OFBIZ-11151 I tried to revert to log4j-api:2.11.2 But still got this locally after 2019-08-14 11:31:34,409 |main |log |I| Logging initialized @269930ms to org.eclipse.jetty.util.log.Slf4jLog Since there is not this problem in stable demo, I reverted to log4j-api:2.6.2 but got the same type of issue I then ran R16 locally and there was no issue. So it's something else than just log4j-api version. I continue... Jacques Le 14/08/2019 à 11:08, Jacques Le Roux a écrit : The issue I initially reported (stop after loading scrum controller) also happens to me in console now, still investigating... Jacques Le 13/08/2019 à 18:57, Mathieu Lirzin a écrit : Hello, Jacques Le Roux writes: Yes it was much faster before (but before what???), as fast as running it in console. Seems like a good scenario for a ‘git bisect’. ;-)
Re: Issue when debugging with Eclipse
This is due to the Solr component Checking what I can do Jacques Le 14/08/2019 à 12:51, Jacques Le Roux a écrit : Hi Girish, Yes I think I'll go this way indeed. I tried to run R17 and R18 locally no issues. Even reverting changes for OFBIZ-11151 does not help Jacques Le 14/08/2019 à 12:40, Girish Vasmatkar a écrit : Hi Jacques Hooking up OFBiz with a profiler should help as to which method (eventually leading to the dependency/API) is taking a lot of time helping narrowing down the cause. Not sure if you want to go down this road, but it may help. Best, Girish On Wed, Aug 14, 2019 at 3:56 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: This is due to logging, here it a sample from trunk demo log (to be sure it's not on my machine): 2019-08-14 03:06:57,734 |main |ConfigXMLReader |I| controller loaded: 0.009s, 207 requests, 81 views in file:/home/ofbizDemo/trunk/plugins/scrum/webapp/scrum/WEB-INF/controller.xml 2019-08-14 03:06:59,831 |main |log |I| Logging initialized @54684ms to org.eclipse.jetty.util.log.Slf4jLog 2019-08-14 03:07:00,052 |main |config |W| Trusting all certificates configured for Client@4da6d664[provider=null,keyStore=null,trustStore=null] After my change in OFBIZ-11151 I tried to revert to log4j-api:2.11.2 But still got this locally after 2019-08-14 11:31:34,409 |main |log |I| Logging initialized @269930ms to org.eclipse.jetty.util.log.Slf4jLog Since there is not this problem in stable demo, I reverted to log4j-api:2.6.2 but got the same type of issue I then ran R16 locally and there was no issue. So it's something else than just log4j-api version. I continue... Jacques Le 14/08/2019 à 11:08, Jacques Le Roux a écrit : The issue I initially reported (stop after loading scrum controller) also happens to me in console now, still investigating... Jacques Le 13/08/2019 à 18:57, Mathieu Lirzin a écrit : Hello, Jacques Le Roux writes: Yes it was much faster before (but before what???), as fast as running it in console. Seems like a good scenario for a ‘git bisect’. ;-)
Re: Issue when debugging with Eclipse
Hi Girish, Yes I think I'll go this way indeed. I tried to run R17 and R18 locally no issues. Even reverting changes for OFBIZ-11151 does not help Jacques Le 14/08/2019 à 12:40, Girish Vasmatkar a écrit : Hi Jacques Hooking up OFBiz with a profiler should help as to which method (eventually leading to the dependency/API) is taking a lot of time helping narrowing down the cause. Not sure if you want to go down this road, but it may help. Best, Girish On Wed, Aug 14, 2019 at 3:56 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: This is due to logging, here it a sample from trunk demo log (to be sure it's not on my machine): 2019-08-14 03:06:57,734 |main |ConfigXMLReader |I| controller loaded: 0.009s, 207 requests, 81 views in file:/home/ofbizDemo/trunk/plugins/scrum/webapp/scrum/WEB-INF/controller.xml 2019-08-14 03:06:59,831 |main |log |I| Logging initialized @54684ms to org.eclipse.jetty.util.log.Slf4jLog 2019-08-14 03:07:00,052 |main |config|W| Trusting all certificates configured for Client@4da6d664[provider=null,keyStore=null,trustStore=null] After my change in OFBIZ-11151 I tried to revert to log4j-api:2.11.2 But still got this locally after 2019-08-14 11:31:34,409 |main |log |I| Logging initialized @269930ms to org.eclipse.jetty.util.log.Slf4jLog Since there is not this problem in stable demo, I reverted to log4j-api:2.6.2 but got the same type of issue I then ran R16 locally and there was no issue. So it's something else than just log4j-api version. I continue... Jacques Le 14/08/2019 à 11:08, Jacques Le Roux a écrit : The issue I initially reported (stop after loading scrum controller) also happens to me in console now, still investigating... Jacques Le 13/08/2019 à 18:57, Mathieu Lirzin a écrit : Hello, Jacques Le Roux writes: Yes it was much faster before (but before what???), as fast as running it in console. Seems like a good scenario for a ‘git bisect’. ;-)
Re: Issue when debugging with Eclipse
Hi Jacques Hooking up OFBiz with a profiler should help as to which method (eventually leading to the dependency/API) is taking a lot of time helping narrowing down the cause. Not sure if you want to go down this road, but it may help. Best, Girish On Wed, Aug 14, 2019 at 3:56 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > This is due to logging, here it a sample from trunk demo log (to be sure > it's not on my machine): > > 2019-08-14 03:06:57,734 |main > |ConfigXMLReader |I| controller loaded: 0.009s, 207 requests, > 81 views in > file:/home/ofbizDemo/trunk/plugins/scrum/webapp/scrum/WEB-INF/controller.xml > 2019-08-14 03:06:59,831 |main > |log |I| Logging initialized @54684ms to > org.eclipse.jetty.util.log.Slf4jLog 2019-08-14 03:07:00,052 > |main > |config|W| Trusting all certificates configured > for Client@4da6d664[provider=null,keyStore=null,trustStore=null] > > After my change in OFBIZ-11151 I tried to revert to log4j-api:2.11.2 > > But still got this locally after > > 2019-08-14 11:31:34,409 |main > |log |I| Logging initialized @269930ms to > org.eclipse.jetty.util.log.Slf4jLog > > Since there is not this problem in stable demo, I reverted to > log4j-api:2.6.2 but got the same type of issue > > I then ran R16 locally and there was no issue. So it's something else than > just log4j-api version. > > I continue... > > Jacques > > Le 14/08/2019 à 11:08, Jacques Le Roux a écrit : > > The issue I initially reported (stop after loading scrum controller) > also happens to me in console now, still investigating... > > > > Jacques > > > > Le 13/08/2019 à 18:57, Mathieu Lirzin a écrit : > >> Hello, > >> > >> Jacques Le Roux writes: > >> > >>> Yes it was much faster before (but before what???), as fast as running > it in console. > >> Seems like a good scenario for a ‘git bisect’. ;-) > >> > > >
Re: Issue when debugging with Eclipse
This is due to logging, here it a sample from trunk demo log (to be sure it's not on my machine): 2019-08-14 03:06:57,734 |main |ConfigXMLReader |I| controller loaded: 0.009s, 207 requests, 81 views in file:/home/ofbizDemo/trunk/plugins/scrum/webapp/scrum/WEB-INF/controller.xml 2019-08-14 03:06:59,831 |main |log |I| Logging initialized @54684ms to org.eclipse.jetty.util.log.Slf4jLog 2019-08-14 03:07:00,052 |main |config |W| Trusting all certificates configured for Client@4da6d664[provider=null,keyStore=null,trustStore=null] After my change in OFBIZ-11151 I tried to revert to log4j-api:2.11.2 But still got this locally after 2019-08-14 11:31:34,409 |main |log |I| Logging initialized @269930ms to org.eclipse.jetty.util.log.Slf4jLog Since there is not this problem in stable demo, I reverted to log4j-api:2.6.2 but got the same type of issue I then ran R16 locally and there was no issue. So it's something else than just log4j-api version. I continue... Jacques Le 14/08/2019 à 11:08, Jacques Le Roux a écrit : The issue I initially reported (stop after loading scrum controller) also happens to me in console now, still investigating... Jacques Le 13/08/2019 à 18:57, Mathieu Lirzin a écrit : Hello, Jacques Le Roux writes: Yes it was much faster before (but before what???), as fast as running it in console. Seems like a good scenario for a ‘git bisect’. ;-)
Re: Issue when debugging with Eclipse
The issue I initially reported (stop after loading scrum controller) also happens to me in console now, still investigating... Jacques Le 13/08/2019 à 18:57, Mathieu Lirzin a écrit : Hello, Jacques Le Roux writes: Yes it was much faster before (but before what???), as fast as running it in console. Seems like a good scenario for a ‘git bisect’. ;-)
Re: Issue when debugging with Eclipse
Hello, Jacques Le Roux writes: > Yes it was much faster before (but before what???), as fast as running it in > console. Seems like a good scenario for a ‘git bisect’. ;-) -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Issue when debugging with Eclipse
It is pretty much the same case with me as well. Not just this, I observe lag during DB operations as well. Did it use to be fast for you earlier? I would say first request always takes more time than the subsequent requests. My eclipse version - Version: Photon Release (4.8.0) Build id: 20180619-1200 Best, Girish On Tue, Aug 13, 2019 at 8:13 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Hi, > > Since sometimes now (few weeks?) I get an issue when debugging with > Eclipse (version 2018-12). I have to wait a long time before passing these > lines > > 2019-08-13 15:00:05,186 |main |ServiceContainer |I| Created > new dispatcher: scrum > 2019-08-13 15:00:05,187 |main |ControlServlet|I| Loading > webapp [scrum], located at C:\projectsASF\ofbiz\plugins\scrum\webapp\scrum\ > 2019-08-13 15:00:05,221 |main |ConfigXMLReader |I| > controller loaded: 0.003s, 207 requests, 81 views in > > file:/C:/projectsASF/ofbiz/plugins/scrum/webapp/scrum/WEB-INF/controller.xml > > I tried it's not related with scrum component. If I remove it, the same > happens with order component. > > The timeout is few minutes and quite annoying. Nobody has an idea? > > Thanks > > Jacques > >
Issue when debugging with Eclipse
Hi, Since sometimes now (few weeks?) I get an issue when debugging with Eclipse (version 2018-12). I have to wait a long time before passing these lines 2019-08-13 15:00:05,186 |main |ServiceContainer |I| Created new dispatcher: scrum 2019-08-13 15:00:05,187 |main |ControlServlet |I| Loading webapp [scrum], located at C:\projectsASF\ofbiz\plugins\scrum\webapp\scrum\ 2019-08-13 15:00:05,221 |main |ConfigXMLReader |I| controller loaded: 0.003s, 207 requests, 81 views in file:/C:/projectsASF/ofbiz/plugins/scrum/webapp/scrum/WEB-INF/controller.xml I tried it's not related with scrum component. If I remove it, the same happens with order component. The timeout is few minutes and quite annoying. Nobody has an idea? Thanks Jacques
