[ http://jira.jboss.com/jira/browse/JBREM-658?page=comments#action_12353297 ] Ron Sigal commented on JBREM-658: --------------------------------- According to http://altair.cs.oswego.edu/pipermail/concurrency-interest/2004-September..., "in certain circumstances the combination of PooledExecutor with BoundedLinkedQueue with a waitWhenBlocked policy can lead to deadlock" Therefore, changed BasicThreadPool blocking policy to RUN in org.jboss.remoting.Client and org.jboss.remoting.ServerInvoker. This means that if the threads and queue in the thread pool are exhausted, the request will be executed on the calling thread. In the course of testing the changes, a race condition in Client.getOnewayThreadpool() and ServerInvoker.getOnewayThreadpool() was discovered that can lead to the creation of multiple thread pools. The body of those methods has been placed in a synchronized block. Unit tests: org.jboss.test.remoting.oneway.OnewayThreadPoolTestCase. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBREM-658?page=all ] Ron Sigal closed JBREM-658. --------------------------- Resolution: Done In the course of testing the new blocking policy, a problem was discovered in the way client side oneway invocations are handled in the socket transport. See JIRA issue JBREM-706: "In socket transport, prevent client side oneway invocations from artificially reducing concurrency". The unit tests have passed on cruisecontrol. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira