one thought does concern me. one of the reasons for using todo manager was to move stuff off of the current thread to break a deadlock. there should have been tests for this but might not have been.
the deadlock occurs when a message marked @AsyncReceiver(Queued) runs. it cannot run on the thread of the queuer, as that is the reader thread. i hope this is preserved. On 3/2/2013 3:53 PM, Paul Turner (JIRA) wrote: > [ > https://issues.apache.org/jira/browse/ETCH-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Paul Turner resolved ETCH-258. > ------------------------------ > > Resolution: Implemented > > Patch ready for review > >> 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
