Hi Robert, As I said in the comment on the Jira, I originally used a bounded blocking queue and a CallerRuns rejected execution handler policy which does a very good job at resource management. The point of managing a threadpool in this way is to make sure that producing threads do not swamp the system and this is achieved by forcing them to do their own work when the threadpool is saturated. So, yes I have.
Now I see that the TodoManager *must* hand off to another thread for Todo execution to eliminate deadlock risk and the approach I will use will mimic the original functionality except I will use a Semaphore to throttle access and force callers to wait. Hope this answers your concerns, I'll be updating the patch in the next couple of days. best regards Paul Turner On Mon, Mar 4, 2013 at 4:59 PM, Robert Comer <[email protected]> wrote: > the bit about todo manager sleeping a bit when the queue was full (and the > queue being fixed length) was to prevent a jabbering or malicious client > from consuming too many resources. have you preserved that quality? > > On Mar 4, 2013, at 5:21 AM, paul turner <[email protected]> > wrote: > > > Hi Scott, > > > > I know how to fix it and I'll add a unit test to make sure the executing > > thread is not the calling thread while I am doing it. > > > > best regards > > > > Paul > > > > > > On Sun, Mar 3, 2013 at 6:33 PM, Paul Turner (JIRA) <[email protected]> > wrote: > > > >> > >> [ > >> > https://issues.apache.org/jira/browse/ETCH-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > >> > >> Paul Turner reopened ETCH-258: > >> ------------------------------ > >> > >> > >> Use of the CallerRunsPolicy in TodoManager in patch will mean that the > >> caller thread will execute the PoolRunnable. Scott mentioned that this > >> will cause problems due to possible deadlocking. > >> > >> Reopened while I create a new RejectedExecutionHandler that will sleep > >> when work queue is full as in original implementation . > >> > >>> Switch to using util.concurrent instead of pre Java 5 threading > >> constructs > >>> > >> > -------------------------------------------------------------------------- > >>> > >>> Key: ETCH-258 > >>> URL: https://issues.apache.org/jira/browse/ETCH-258 > >>> Project: Etch > >>> Issue Type: Improvement > >>> Components: binding-java, general > >>> Reporter: Paul Turner > >>> Priority: Minor > >>> Fix For: 1.4 > >>> > >>> Attachments: etch-20130301.patch > >>> > >>> Original Estimate: 168h > >>> Remaining Estimate: 168h > >>> > >>> thread creation is quite expensive and so a new thread per unit of work > >> is also expensive, i propose to use util.concurrent threadpools in the > java > >> binding sub-project and enhance unit tests e.g. with countdown latches > to > >> ensure competing test threads start simeltanously and semaphore to > throttle > >> access to running units of work. > >>> affects FreePool, TodoManager and associated tests and possibly more > >> classes > >> > >> -- > >> This message is automatically generated by JIRA. > >> If you think it was sent incorrectly, please contact your JIRA > >> administrators > >> For more information on JIRA, see: > http://www.atlassian.com/software/jira > >> > >
