ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Crum <adrian.c...@sandglass-software.com>
Subject Re: svn commit: r1627092 - in /ofbiz/trunk/framework: base/src/org/ofbiz/base/concurrent/ catalina/src/org/ofbiz/catalina/container/ entity/dtd/ entity/src/org/ofbiz/entity/ entity/src/org/ofbiz/entity/config/model/ entity/src/org/ofbiz/entity/datasource/ ...
Date Thu, 25 Sep 2014 09:42:30 GMT
The problem with setting it in code is that the setting is dependent on 
hardware configuration.

Please don't assume no one is using it. I use it, Adam (the code author) 
uses it, and I encourage my development staff to use it.

Adrian Crum
Sandglass Software

On 9/25/2014 10:34 AM, Jacopo Cappellato wrote:
> Thank you Adrian, it is interesting!
> Unfortunately I don't have time to look at the details at the moment but I will follow
up with some comments as I will find some time; in the meantime please see below:
> On Sep 25, 2014, at 11:15 AM, Adrian Crum <adrian.crum@sandglass-software.com>
>> With your previous change, 12 CPUs = 12 threads = n * 2. The data load took twice
as long as when I was able to configure it for 4 threads.
> The main goal of my changes was to shutdown the threads after they have completed their
job at bootstrap; this is now true; the side effect of my first commit has been that of running
more threads for the dbCheck task, instead of just run it with 1 as it was before (with default
configuration); after my second commit, based on your feedback, at bootstrap the system behaves
as before my changes, still shutting down the threads when done.
> I really didn't care too much about startup times but rather of resource utilization
after the bootstrap.
> I still think that the max-worker-pool-size is a too low level setting that just controls
the number of threads for the dbCheck task and it doesn't make much sense to have it in the
datasource configuration... I doubt that many users are actually setting it and so everyone
is running with the default of 1 thread for the dbCheck task... which is actually fine (and
probably better than using a numOfProcessor threads) but in my opinion we could get rid of
this "configuration" option and set it in code. But at this point it is not too much important
to me and we can revisit this at a later point in time.
> Jacopo

View raw message