[ 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.