Mmm, it seems I wanted to say something here and pushed a button too fast :D
Actually I guess you saw this was done very simply at r1817040
Jacques
Le 24/11/2017 à 19:34, Jacques Le Roux a écrit :
Le 12/10/2017 à 22:12, Scott Gray a écrit :
Honestly I think the topic is generic enough
Hi Scott, Michael,
It's late but I'm still reading Java Concurrency in Practice (not now, but actually often :)) and I agree with (all) answers at
https://stackoverflow.com/questions/13834692/threads-configuration-based-on-no-of-cpu-cores
It's indeed not a trivial task to determine the best
Honestly I think the topic is generic enough that OFBiz doesn't need to
provide any information at all. Thread pool sizing is not exclusive to
OFBiz and it would be strange for anyone to modify the numbers without
first researching sources that provide far more detail than a few sentences
in our
Hi Jacques,
yes, in general I think it's best to document at the place where users
do the configuration.
In this case, I cannot say if the statement makes any sense. It can be
from ancient times where you only had single core systems not making
sense anymore and it can also be correct
Right, thanks Michael
Thought some documentation is present in ThreadPool.java, I think we should
document that at the service serviceengine.xml level
I mean, in general, we should document at the level used to configure, not
below.
Here for instance something like "Values higher than 5
Hi Jacques,
as you said, it's just a default and the value can be configured through
"max-threads".
I would leave it as is.
Regards,
Michael
Am 11.10.17 um 07:58 schrieb Jacques Le Roux:
MAX_THREADS = 5
smime.p7s
Description: S/MIME Cryptographic Signature
Le 10/10/2017 à 15:46, mbr...@apache.org a écrit :
public static final int MAX_THREADS = 5; // Values higher than 5 might slow
things down.
Hi
While reviewing recent Michael's commits (thanks Michael and the ecomify team)
I stumbled upon this static variable
I know it's only a default,
