[
https://issues.apache.org/jira/browse/OFBIZ-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890336#action_12890336
]
Adam Heath commented on OFBIZ-3867:
-----------------------------------
Hmm, interesting points. Having a single, global pool of available worker
threads makes sense. If you have 10 tenants, each with a 4-thread pool, then
you could have 40 threads all trying to do work. That sucks.
But, if you have a single global pool, with 4 threads, it's possible for a
single tenant to overload the global pool with work, and starve the other
tenants. So, some kind of PriorityQueue needs to be used. With appropriate
configuration knobs.
I think the jobs should not be stored in the main database. That makes
database backups more difficult.
But, maybe have a separate feature for wanting to run a job on all tenants.
There are several ideas floating here, each one would need to be done
separately.
> JobManager.poll() enters an endless loop when it can't get a connection
> -----------------------------------------------------------------------
>
> Key: OFBIZ-3867
> URL: https://issues.apache.org/jira/browse/OFBIZ-3867
> Project: OFBiz
> Issue Type: Bug
> Reporter: Adam Heath
> Assignee: Adam Heath
>
> JobManager.poll(), line 157, where it calls storeByCondition, can fail when
> there is no connection available from the database(due to a connection leak,
> or just load, or whatever). An exception then gets thrown by
> storeByCondition(deep inside ofbiz/commons-dbcp/postgres). The
> catch(Throwable) then logs the error, and the loop tries again. Since
> pollDone never gets set to true, this loop is *very* tight, and the log file
> starts to fill up *very* fast, each each thread of JobPoller tries the same
> thing over and over.
> I'm filing this bug mainly to see if anyone else works on it, but if not,
> it's a reminder for me.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
