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 >
