Update OptaplannerKieServerExtension.java

[robertonav20]

No description provided.

[ghost]

Can one of the admins verify this PR? Comment with 'ok to test' to start the build.

[ge0ffrey]

This is too verbose to output on info logging. Let's make this debug logging.

[ge0ffrey]

No need to use StringBuilder here, it's equally fast as just String concatenation because there is no loop. (faster even, see shipilev's blog).
Furthermore, better to use this to avoid string concatenation if the logging level > debug.

     logger.debug("OptaPlanner extension created with corePoolSize ({}), queueSize ({}), ...", corePoolSize, queueSize, ...)

[ge0ffrey]

ok to test

[ge0ffrey]

@MusaTalluzi if you could take some time to review and test this changes to approve the PR, then let me know and I 'll merge it.
@tkobayas FYI ^^

Relates to https://issues.jboss.org/browse/BAPL-1364 - but I am now starting to doubt if it fixes it. I haven't investigated reqs in detail at this point - the bapl reopening relates to openshift.

[ge0ffrey]

See my earlier comments.

[yurloc]

Hey @robertonav20, welcome to KIE group! Please describe what problem you're trying to solve with this PR. Either try to explain here in PR description/comments or share links if the issue is already reported on StackOverflow or JIRA.

[robertonav20]

Hey yurloc,
i have a problem when send a lot of jobs to optaplanner from Kie Server.
Tha actual version of Kie server refuse all job if the number is major than resolvedActiveThreadCount.
This logic refuse all job and he don't add at the queue, so i receive an HTTP 500 (Internal Server Error) from kie server POST.

Below the old logic
int availableProcessorCount = Runtime.getRuntime().availableProcessors();
int resolvedActiveThreadCount = Math.max(1, availableProcessorCount - 2);
int queueSize = Integer.parseInt(System.getProperty(
KieServerConstants.KIE_OPTAPLANNER_THREAD_POOL_QUEUE_SIZE, String.valueOf(resolvedActiveThreadCount)));
logger.info("Creating a ThreadPoolExecutor with corePoolSize = " + resolvedActiveThreadCount + ","
+ " maximumPoolSize = " + resolvedActiveThreadCount + ", queueSize = " + queueSize);

this.threadPool = new ThreadPoolExecutor(
resolvedActiveThreadCount,
resolvedActiveThreadCount,
10, // thread keep alive time
TimeUnit.SECONDS,
new ArrayBlockingQueue<>(queueSize)); // queue with a size

[yurloc]

@robertonav20 What is the latest KIE Server version that is affected by this issue? Could you please try with 7.24.0.Final or newer? 7.24.0.Final was released shortly before you opened this PR and contains a fix for https://issues.jboss.org/browse/PLANNER-1553, which might also address your issue.

[yurloc]

@robertonav20 I just tried 7.24.0.Final and was I able submit problems to 30 solvers on my machine with 8 CPUs when I used org.optaplanner.server.ext.thread.pool.queue.size property (introduced by #1862) to increase the queue size.

8 CPUs => 6 threads in the pool. This means maximum of 6 solvers solving in parallel. Other solving jobs will wait in the queue until solving requests exceed queue size. The default queue size is equal to the pool size so with N CPUs you can have N problems being solved and another N waiting in the queue. Any additional requests will be rejected until there's free space in the queue.

If you want to be able to handle more than N+N request (allow more requests to wait in the queue instead of being rejected), use org.optaplanner.server.ext.thread.pool.queue.size system property.

Let me know if that helps.

[robertonav20]

Hi yurloc,
I don't see the fixed bug on Jira and I use kie server on 7.18 so the bug exist.

So I update the version of kie server then use that system property right?!

Thanks yurloc and tkobayash for fix!

[yurloc]

@robertonav20 Yes. Please upgrade to latest (at least 7.24.0.Final) and use the property to increase thread pool queue size.

If this approach doesn't help, please file a JIRA ticket and provide more information (stack trace from server log, log line with thread pool information (Creating a ThreadPoolExecutor with corePoolSize = 6, maximumPoolSize = 6, queueSize = 6), number of your CPUs and number of requests). Feel free to propose a fix as well but we need more detailed description of the problem in order to be able to validate the fix.

Closing this PR as the issue seems to be fixed by #1862 and also for the reason that merging this PR would revert #1862, introducing a regression.