Any chance for an upgrade? - help please
Locked
12
12
Re: Any chance for an upgrade? - help please
 
Administrator
|
Did you look into the FAQ?
Jacques From: "Florin Popa" <[hidden email]> > I'll take a look ar Grinder, seems promising, thanks again. > > Of course life is never easy :) now I have another problem... the > network admin configured 2 ofbiz instances having an apache in front of > them as balancer.. but apache "talks" with ofbiz instances via AJP > rather than mod_jk ..which seems to be a bottleneck.. > Have you experienced that kind of things? > > best regards, > Florin Popa > > >> The Grinder is a nice tool for such things (and has a nice recording proxy). >> >> BTW, make sure to set your HTTP and thread pool sizes adequately for the load you are planning on. >> >> -David >> >> >> On Jan 28, 2010, at 11:30 AM, Florin Popa wrote: >> >> >>> Thanks everyone for the help! >>> >>> Today we succeeded port to geronimo transaction 2.1 as well as the switch from minerva to DBCP connection pool. It seems much >>> better but I am not fully content :) >>> Maybe because the automated testing tool I am using can not really hit hard enough.. >>> >>> Any recommendation for such tools? >>> >>> >>> Of course upgrade to latest version was scheduled too but this would take longer.. >>> >>> Best regards, >>> Florin >>> >>>> You're using a quite old version of OFBiz with the Minerva connection pool (I can tell from the stack trace you sent earlier). >>>> The Minerva connection pool has some issues with resetting connections when there are errors, especially if there is any code >>>> that doesn't manage errors well, but also if there are network layer issues or other sorts of things... it just doesn't recover >>>> at all. >>>> >>>> You could try making changes to use the Apache DBCP connection pool that we use now in OFBiz. To do so requires some low-level >>>> coding. You can look at the current code base for hints, but there is still some work. >>>> >>>> There are no known workarounds to this issue for really high volume sites, and for low-medium volume sites the workaround was >>>> to restart the app server(s) every day. >>>> >>>> -David >>>> >>>> >>>> On Jan 27, 2010, at 3:01 PM, Florin Popa wrote: >>>> >>>> >>>> >>>>> I was just asking myself if someone encountered before such problems on older revisions.. >>>>> >>>>> Would be Geronimo ok to be used or shall I try something else? >>>>> >>>>> regards, >>>>> Florin >>>>> >>>>> >>>>>> I'm sorry the potential for problems with this approach is just too large for me to be able to help you through it. >>>>>> >>>>>> Regards >>>>>> Scott >>>>>> >>>>>> HotWax Media >>>>>> http://www.hotwaxmedia.com >>>>>> >>>>>> On 27/01/2010, at 1:53 PM, Florin Popa wrote: >>>>>> >>>>>> >>>>>> >>>>>>> The attempt to update Ofbiz to recent revision is for the moment (time limits) not possible.. there are so many >>>>>>> differences... I am even not sure if bsh could work further instead of the newly groovy ?! ....also the entity layer >>>>>>> handling.. etc >>>>>>> >>>>>>> So what I tried was to back port the transaction management - latest attempt is attached >>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> >> > > |
|
In reply to this post by Florin Popa
Florin,
I'm not sure what you mean when you say "apache talke with ofbiz instances via AJP rather than mod_jk". I thought mod_jk used AJP. I would be interested if you find that AJP is a bottleneck. We use a configuration with Apache on the front end and ofbiz on behind it. We use mod_jk because it has a nice load balancer feature. We have also used mod_proxy which doesn't use AJP but we haven't done any performance testing to compare the differences between the two. Brett On Thu, Jan 28, 2010 at 11:58 AM, Florin Popa <[hidden email]>wrote: > I'll take a look ar Grinder, seems promising, thanks again. > > Of course life is never easy :) now I have another problem... the network > admin configured 2 ofbiz instances having an apache in front of them as > balancer.. but apache "talks" with ofbiz instances via AJP rather than > mod_jk ..which seems to be a bottleneck.. > Have you experienced that kind of things? > > best regards, > Florin Popa > > > > The Grinder is a nice tool for such things (and has a nice recording >> proxy). >> >> BTW, make sure to set your HTTP and thread pool sizes adequately for the >> load you are planning on. >> >> -David >> >> >> On Jan 28, 2010, at 11:30 AM, Florin Popa wrote: >> >> >> >>> Thanks everyone for the help! >>> >>> Today we succeeded port to geronimo transaction 2.1 as well as the switch >>> from minerva to DBCP connection pool. It seems much better but I am not >>> fully content :) >>> Maybe because the automated testing tool I am using can not really hit >>> hard enough.. >>> >>> Any recommendation for such tools? >>> >>> >>> Of course upgrade to latest version was scheduled too but this would take >>> longer.. >>> >>> Best regards, >>> Florin >>> >>> >>>> You're using a quite old version of OFBiz with the Minerva connection >>>> pool (I can tell from the stack trace you sent earlier). The Minerva >>>> connection pool has some issues with resetting connections when there are >>>> errors, especially if there is any code that doesn't manage errors well, but >>>> also if there are network layer issues or other sorts of things... it just >>>> doesn't recover at all. >>>> >>>> You could try making changes to use the Apache DBCP connection pool that >>>> we use now in OFBiz. To do so requires some low-level coding. You can look >>>> at the current code base for hints, but there is still some work. >>>> >>>> There are no known workarounds to this issue for really high volume >>>> sites, and for low-medium volume sites the workaround was to restart the app >>>> server(s) every day. >>>> >>>> -David >>>> >>>> >>>> On Jan 27, 2010, at 3:01 PM, Florin Popa wrote: >>>> >>>> >>>> >>>>> I was just asking myself if someone encountered before such problems on >>>>> older revisions.. >>>>> >>>>> Would be Geronimo ok to be used or shall I try something else? >>>>> >>>>> regards, >>>>> Florin >>>>> >>>>> >>>>>> I'm sorry the potential for problems with this approach is just too >>>>>> large for me to be able to help you through it. >>>>>> >>>>>> Regards >>>>>> Scott >>>>>> >>>>>> HotWax Media >>>>>> http://www.hotwaxmedia.com >>>>>> >>>>>> On 27/01/2010, at 1:53 PM, Florin Popa wrote: >>>>>> >>>>>> >>>>>> >>>>>>> The attempt to update Ofbiz to recent revision is for the moment >>>>>>> (time limits) not possible.. there are so many differences... I am even not >>>>>>> sure if bsh could work further instead of the newly groovy ?! ....also the >>>>>>> entity layer handling.. etc >>>>>>> >>>>>>> So what I tried was to back port the transaction management - latest >>>>>>> attempt is attached >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> >> > > |
Re: Any chance for an upgrade? - help please
|
|
Hi,
Today is planned to switch from AJP to mod_jk...I will let you know the differences. How did I reached that point: a simple tool http://httpd.apache.org/docs/2.0/programs/ab.html I tried to hit the Apache server only like /usr/local/apache2/bin/ab -c 100 -t 30 <url> and I could reach almost 50.000 req/sec When I tried to hit Ofbiz through Apache I found a VERY big bottleneck.. never more than 5 req/sec... regards, Florin > Florin, > > I'm not sure what you mean when you say "apache talke with ofbiz instances > via AJP rather than mod_jk". I thought mod_jk used AJP. > > I would be interested if you find that AJP is a bottleneck. We use a > configuration with Apache on the front end and ofbiz on behind it. We use > mod_jk because it has a nice load balancer feature. We have also used > mod_proxy which doesn't use AJP but we haven't done any performance testing > to compare the differences between the two. > > Brett > > On Thu, Jan 28, 2010 at 11:58 AM, Florin Popa <[hidden email]>wrote: > > >> I'll take a look ar Grinder, seems promising, thanks again. >> >> Of course life is never easy :) now I have another problem... the network >> admin configured 2 ofbiz instances having an apache in front of them as >> balancer.. but apache "talks" with ofbiz instances via AJP rather than >> mod_jk ..which seems to be a bottleneck.. >> Have you experienced that kind of things? >> >> best regards, >> Florin Popa >> >> >> >> The Grinder is a nice tool for such things (and has a nice recording >> >>> proxy). >>> >>> BTW, make sure to set your HTTP and thread pool sizes adequately for the >>> load you are planning on. >>> >>> -David >>> >>> >>> On Jan 28, 2010, at 11:30 AM, Florin Popa wrote: >>> >>> >>> >>> >>>> Thanks everyone for the help! >>>> >>>> Today we succeeded port to geronimo transaction 2.1 as well as the switch >>>> from minerva to DBCP connection pool. It seems much better but I am not >>>> fully content :) >>>> Maybe because the automated testing tool I am using can not really hit >>>> hard enough.. >>>> >>>> Any recommendation for such tools? >>>> >>>> >>>> Of course upgrade to latest version was scheduled too but this would take >>>> longer.. >>>> >>>> Best regards, >>>> Florin >>>> >>>> >>>> >>>>> You're using a quite old version of OFBiz with the Minerva connection >>>>> pool (I can tell from the stack trace you sent earlier). The Minerva >>>>> connection pool has some issues with resetting connections when there are >>>>> errors, especially if there is any code that doesn't manage errors well, but >>>>> also if there are network layer issues or other sorts of things... it just >>>>> doesn't recover at all. >>>>> >>>>> You could try making changes to use the Apache DBCP connection pool that >>>>> we use now in OFBiz. To do so requires some low-level coding. You can look >>>>> at the current code base for hints, but there is still some work. >>>>> >>>>> There are no known workarounds to this issue for really high volume >>>>> sites, and for low-medium volume sites the workaround was to restart the app >>>>> server(s) every day. >>>>> >>>>> -David >>>>> >>>>> >>>>> On Jan 27, 2010, at 3:01 PM, Florin Popa wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> I was just asking myself if someone encountered before such problems on >>>>>> older revisions.. >>>>>> >>>>>> Would be Geronimo ok to be used or shall I try something else? >>>>>> >>>>>> regards, >>>>>> Florin >>>>>> >>>>>> >>>>>> >>>>>>> I'm sorry the potential for problems with this approach is just too >>>>>>> large for me to be able to help you through it. >>>>>>> >>>>>>> Regards >>>>>>> Scott >>>>>>> >>>>>>> HotWax Media >>>>>>> http://www.hotwaxmedia.com >>>>>>> >>>>>>> On 27/01/2010, at 1:53 PM, Florin Popa wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> The attempt to update Ofbiz to recent revision is for the moment >>>>>>>> (time limits) not possible.. there are so many differences... I am even not >>>>>>>> sure if bsh could work further instead of the newly groovy ?! ....also the >>>>>>>> entity layer handling.. etc >>>>>>>> >>>>>>>> So what I tried was to back port the transaction management - latest >>>>>>>> attempt is attached >>>>>>>> >>>>>>>> >>>>>>> >>> >>> >> > > |
Re: Any chance for an upgrade? - help please
|
|
In reply to this post by Brett
Hi,
It seems I was on a false track... the tests hits directly against ofbiz (without Apache in front) did not work properly.. now they do and I only get max 2-3 req.sec... What could be wrong configured? I tried similar hits against one simple tomcat and on 30 secs I reach 50000 req/sec. I only touched this: <thread-pool send-to-pool="pool" purge-job-days="4" failed-retry-min="3" ttl="180000" wait-millis="750" jobs="500" min-threads="50" max-threads="500" poll-enabled="true" poll-db-millis="20000"> <run-from-pool name="pool"/> </thread-pool> What else needs to be configured for production load usage to reach more requests per second? The cache is also properly confgured thanks, Florin > Florin, > > I'm not sure what you mean when you say "apache talke with ofbiz instances > via AJP rather than mod_jk". I thought mod_jk used AJP. > > I would be interested if you find that AJP is a bottleneck. We use a > configuration with Apache on the front end and ofbiz on behind it. We use > mod_jk because it has a nice load balancer feature. We have also used > mod_proxy which doesn't use AJP but we haven't done any performance testing > to compare the differences between the two. > > Brett > > On Thu, Jan 28, 2010 at 11:58 AM, Florin Popa <[hidden email]>wrote: > > >> I'll take a look ar Grinder, seems promising, thanks again. >> >> Of course life is never easy :) now I have another problem... the network >> admin configured 2 ofbiz instances having an apache in front of them as >> balancer.. but apache "talks" with ofbiz instances via AJP rather than >> mod_jk ..which seems to be a bottleneck.. >> Have you experienced that kind of things? >> >> best regards, >> Florin Popa >> >> >> >> The Grinder is a nice tool for such things (and has a nice recording >> >>> proxy). >>> >>> BTW, make sure to set your HTTP and thread pool sizes adequately for the >>> load you are planning on. >>> >>> -David >>> >>> >>> On Jan 28, 2010, at 11:30 AM, Florin Popa wrote: >>> >>> >>> >>> >>>> Thanks everyone for the help! >>>> >>>> Today we succeeded port to geronimo transaction 2.1 as well as the switch >>>> from minerva to DBCP connection pool. It seems much better but I am not >>>> fully content :) >>>> Maybe because the automated testing tool I am using can not really hit >>>> hard enough.. >>>> >>>> Any recommendation for such tools? >>>> >>>> >>>> Of course upgrade to latest version was scheduled too but this would take >>>> longer.. >>>> >>>> Best regards, >>>> Florin >>>> >>>> >>>> >>>>> You're using a quite old version of OFBiz with the Minerva connection >>>>> pool (I can tell from the stack trace you sent earlier). The Minerva >>>>> connection pool has some issues with resetting connections when there are >>>>> errors, especially if there is any code that doesn't manage errors well, but >>>>> also if there are network layer issues or other sorts of things... it just >>>>> doesn't recover at all. >>>>> >>>>> You could try making changes to use the Apache DBCP connection pool that >>>>> we use now in OFBiz. To do so requires some low-level coding. You can look >>>>> at the current code base for hints, but there is still some work. >>>>> >>>>> There are no known workarounds to this issue for really high volume >>>>> sites, and for low-medium volume sites the workaround was to restart the app >>>>> server(s) every day. >>>>> >>>>> -David >>>>> >>>>> >>>>> On Jan 27, 2010, at 3:01 PM, Florin Popa wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> I was just asking myself if someone encountered before such problems on >>>>>> older revisions.. >>>>>> >>>>>> Would be Geronimo ok to be used or shall I try something else? >>>>>> >>>>>> regards, >>>>>> Florin >>>>>> >>>>>> >>>>>> >>>>>>> I'm sorry the potential for problems with this approach is just too >>>>>>> large for me to be able to help you through it. >>>>>>> >>>>>>> Regards >>>>>>> Scott >>>>>>> >>>>>>> HotWax Media >>>>>>> http://www.hotwaxmedia.com >>>>>>> >>>>>>> On 27/01/2010, at 1:53 PM, Florin Popa wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> The attempt to update Ofbiz to recent revision is for the moment >>>>>>>> (time limits) not possible.. there are so many differences... I am even not >>>>>>>> sure if bsh could work further instead of the newly groovy ?! ....also the >>>>>>>> entity layer handling.. etc >>>>>>>> >>>>>>>> So what I tried was to back port the transaction management - latest >>>>>>>> attempt is attached >>>>>>>> >>>>>>>> >>>>>>> >>> >>> >> > > |
|
|
Florin,
Have you tried using Apache's mod_proxy instead of mod_jk? I'm not surprised that you get faster responses directly from Apache but 2-3 req/sec doesn't sound good for Tomcat either. I'll try this same tool in our configuration and see what we get. For us we configure mod_jk to communicate through the ofbiz AJP port. We have also used mod_proxy which doesn't use AJP and goes directly to Tomcat's http port (8080). I'll run your recommended tool to see what gets better performance. Brett On Fri, Jan 29, 2010 at 6:07 AM, Florin Popa <[hidden email]> wrote: > Hi, > > It seems I was on a false track... the tests hits directly against ofbiz > (without Apache in front) did not work properly.. now they do and I only get > max 2-3 req.sec... > > What could be wrong configured? > > I tried similar hits against one simple tomcat and on 30 secs I reach 50000 > req/sec. > > I only touched this: > > <thread-pool send-to-pool="pool" > purge-job-days="4" > failed-retry-min="3" > ttl="180000" > wait-millis="750" > jobs="500" > min-threads="50" > max-threads="500" > poll-enabled="true" > poll-db-millis="20000"> > <run-from-pool name="pool"/> > </thread-pool> > > > What else needs to be configured for production load usage to reach more > requests per second? > > The cache is also properly confgured > > > thanks, > Florin > > Florin, >> >> I'm not sure what you mean when you say "apache talke with ofbiz instances >> via AJP rather than mod_jk". I thought mod_jk used AJP. >> >> I would be interested if you find that AJP is a bottleneck. We use a >> configuration with Apache on the front end and ofbiz on behind it. We use >> mod_jk because it has a nice load balancer feature. We have also used >> mod_proxy which doesn't use AJP but we haven't done any performance >> testing >> to compare the differences between the two. >> >> Brett >> >> On Thu, Jan 28, 2010 at 11:58 AM, Florin Popa <[hidden email] >> >wrote: >> >> >> >>> I'll take a look ar Grinder, seems promising, thanks again. >>> >>> Of course life is never easy :) now I have another problem... the network >>> admin configured 2 ofbiz instances having an apache in front of them as >>> balancer.. but apache "talks" with ofbiz instances via AJP rather than >>> mod_jk ..which seems to be a bottleneck.. >>> Have you experienced that kind of things? >>> >>> best regards, >>> Florin Popa >>> >>> >>> >>> The Grinder is a nice tool for such things (and has a nice recording >>> >>> >>>> proxy). >>>> >>>> BTW, make sure to set your HTTP and thread pool sizes adequately for the >>>> load you are planning on. >>>> >>>> -David >>>> >>>> >>>> On Jan 28, 2010, at 11:30 AM, Florin Popa wrote: >>>> >>>> >>>> >>>> >>>> >>>>> Thanks everyone for the help! >>>>> >>>>> Today we succeeded port to geronimo transaction 2.1 as well as the >>>>> switch >>>>> from minerva to DBCP connection pool. It seems much better but I am not >>>>> fully content :) >>>>> Maybe because the automated testing tool I am using can not really hit >>>>> hard enough.. >>>>> >>>>> Any recommendation for such tools? >>>>> >>>>> >>>>> Of course upgrade to latest version was scheduled too but this would >>>>> take >>>>> longer.. >>>>> >>>>> Best regards, >>>>> Florin >>>>> >>>>> >>>>> >>>>> >>>>>> You're using a quite old version of OFBiz with the Minerva connection >>>>>> pool (I can tell from the stack trace you sent earlier). The Minerva >>>>>> connection pool has some issues with resetting connections when there >>>>>> are >>>>>> errors, especially if there is any code that doesn't manage errors >>>>>> well, but >>>>>> also if there are network layer issues or other sorts of things... it >>>>>> just >>>>>> doesn't recover at all. >>>>>> >>>>>> You could try making changes to use the Apache DBCP connection pool >>>>>> that >>>>>> we use now in OFBiz. To do so requires some low-level coding. You can >>>>>> look >>>>>> at the current code base for hints, but there is still some work. >>>>>> >>>>>> There are no known workarounds to this issue for really high volume >>>>>> sites, and for low-medium volume sites the workaround was to restart >>>>>> the app >>>>>> server(s) every day. >>>>>> >>>>>> -David >>>>>> >>>>>> >>>>>> On Jan 27, 2010, at 3:01 PM, Florin Popa wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> I was just asking myself if someone encountered before such problems >>>>>>> on >>>>>>> older revisions.. >>>>>>> >>>>>>> Would be Geronimo ok to be used or shall I try something else? >>>>>>> >>>>>>> regards, >>>>>>> Florin >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I'm sorry the potential for problems with this approach is just too >>>>>>>> large for me to be able to help you through it. >>>>>>>> >>>>>>>> Regards >>>>>>>> Scott >>>>>>>> >>>>>>>> HotWax Media >>>>>>>> http://www.hotwaxmedia.com >>>>>>>> >>>>>>>> On 27/01/2010, at 1:53 PM, Florin Popa wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> The attempt to update Ofbiz to recent revision is for the moment >>>>>>>>> (time limits) not possible.. there are so many differences... I am >>>>>>>>> even not >>>>>>>>> sure if bsh could work further instead of the newly groovy ?! >>>>>>>>> ....also the >>>>>>>>> entity layer handling.. etc >>>>>>>>> >>>>>>>>> So what I tried was to back port the transaction management - >>>>>>>>> latest >>>>>>>>> attempt is attached >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>> >>>> >>> >>> >> >> >> > > |
Re: Any chance for an upgrade? - help please
|
|
Hi,
It is even worse for me... I dropped the tests regarding apache and I tried tests directly against one ofbiz instance, without any apache in front..using the same apache ab tool. I never exceee 3-4 requests per second :( I tried also to hit one static page and I reach arround 2000 req/sec and for a page with one singe DB access through GenericDelegator I get aprox 1000 req/sec Why for the the entire ecommerce application (actually for its main page where I display few promo products, indeed with some processing for PriceServices) I never get more than 34 requests per second? regards, Florin > Florin, > > Have you tried using Apache's mod_proxy instead of mod_jk? > > I'm not surprised that you get faster responses directly from Apache but 2-3 > req/sec doesn't sound good for Tomcat either. > > I'll try this same tool in our configuration and see what we get. > > For us we configure mod_jk to communicate through the ofbiz AJP port. > > We have also used mod_proxy which doesn't use AJP and goes directly to > Tomcat's http port (8080). > > I'll run your recommended tool to see what gets better performance. > > > > Brett > > On Fri, Jan 29, 2010 at 6:07 AM, Florin Popa <[hidden email]> wrote: > > >> Hi, >> >> It seems I was on a false track... the tests hits directly against ofbiz >> (without Apache in front) did not work properly.. now they do and I only get >> max 2-3 req.sec... >> >> What could be wrong configured? >> >> I tried similar hits against one simple tomcat and on 30 secs I reach 50000 >> req/sec. >> >> I only touched this: >> >> <thread-pool send-to-pool="pool" >> purge-job-days="4" >> failed-retry-min="3" >> ttl="180000" >> wait-millis="750" >> jobs="500" >> min-threads="50" >> max-threads="500" >> poll-enabled="true" >> poll-db-millis="20000"> >> <run-from-pool name="pool"/> >> </thread-pool> >> >> >> What else needs to be configured for production load usage to reach more >> requests per second? >> >> The cache is also properly confgured >> >> >> thanks, >> Florin >> >> Florin, >> >>> I'm not sure what you mean when you say "apache talke with ofbiz instances >>> via AJP rather than mod_jk". I thought mod_jk used AJP. >>> >>> I would be interested if you find that AJP is a bottleneck. We use a >>> configuration with Apache on the front end and ofbiz on behind it. We use >>> mod_jk because it has a nice load balancer feature. We have also used >>> mod_proxy which doesn't use AJP but we haven't done any performance >>> testing >>> to compare the differences between the two. >>> >>> Brett >>> >>> On Thu, Jan 28, 2010 at 11:58 AM, Florin Popa <[hidden email] >>> >>>> wrote: >>>> >>> >>> >>>> I'll take a look ar Grinder, seems promising, thanks again. >>>> >>>> Of course life is never easy :) now I have another problem... the network >>>> admin configured 2 ofbiz instances having an apache in front of them as >>>> balancer.. but apache "talks" with ofbiz instances via AJP rather than >>>> mod_jk ..which seems to be a bottleneck.. >>>> Have you experienced that kind of things? >>>> >>>> best regards, >>>> Florin Popa >>>> >>>> >>>> >>>> The Grinder is a nice tool for such things (and has a nice recording >>>> >>>> >>>> >>>>> proxy). >>>>> >>>>> BTW, make sure to set your HTTP and thread pool sizes adequately for the >>>>> load you are planning on. >>>>> >>>>> -David >>>>> >>>>> >>>>> On Jan 28, 2010, at 11:30 AM, Florin Popa wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Thanks everyone for the help! >>>>>> >>>>>> Today we succeeded port to geronimo transaction 2.1 as well as the >>>>>> switch >>>>>> from minerva to DBCP connection pool. It seems much better but I am not >>>>>> fully content :) >>>>>> Maybe because the automated testing tool I am using can not really hit >>>>>> hard enough.. >>>>>> >>>>>> Any recommendation for such tools? >>>>>> >>>>>> >>>>>> Of course upgrade to latest version was scheduled too but this would >>>>>> take >>>>>> longer.. >>>>>> >>>>>> Best regards, >>>>>> Florin >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> You're using a quite old version of OFBiz with the Minerva connection >>>>>>> pool (I can tell from the stack trace you sent earlier). The Minerva >>>>>>> connection pool has some issues with resetting connections when there >>>>>>> are >>>>>>> errors, especially if there is any code that doesn't manage errors >>>>>>> well, but >>>>>>> also if there are network layer issues or other sorts of things... it >>>>>>> just >>>>>>> doesn't recover at all. >>>>>>> >>>>>>> You could try making changes to use the Apache DBCP connection pool >>>>>>> that >>>>>>> we use now in OFBiz. To do so requires some low-level coding. You can >>>>>>> look >>>>>>> at the current code base for hints, but there is still some work. >>>>>>> >>>>>>> There are no known workarounds to this issue for really high volume >>>>>>> sites, and for low-medium volume sites the workaround was to restart >>>>>>> the app >>>>>>> server(s) every day. >>>>>>> >>>>>>> -David >>>>>>> >>>>>>> >>>>>>> On Jan 27, 2010, at 3:01 PM, Florin Popa wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I was just asking myself if someone encountered before such problems >>>>>>>> on >>>>>>>> older revisions.. >>>>>>>> >>>>>>>> Would be Geronimo ok to be used or shall I try something else? >>>>>>>> >>>>>>>> regards, >>>>>>>> Florin >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> I'm sorry the potential for problems with this approach is just too >>>>>>>>> large for me to be able to help you through it. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Scott >>>>>>>>> >>>>>>>>> HotWax Media >>>>>>>>> http://www.hotwaxmedia.com >>>>>>>>> >>>>>>>>> On 27/01/2010, at 1:53 PM, Florin Popa wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> The attempt to update Ofbiz to recent revision is for the moment >>>>>>>>>> (time limits) not possible.. there are so many differences... I am >>>>>>>>>> even not >>>>>>>>>> sure if bsh could work further instead of the newly groovy ?! >>>>>>>>>> ....also the >>>>>>>>>> entity layer handling.. etc >>>>>>>>>> >>>>>>>>>> So what I tried was to back port the transaction management - >>>>>>>>>> latest >>>>>>>>>> attempt is attached >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>> >>>> >>> >>> >> > > |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |