[jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1637) Interruption is busted

[ https://jira.jboss.org/jira/browse/JBMESSAGING-1637?page=com.atlassian.ji... ] Howard Gao commented on JBMESSAGING-1637: ----------------------------------------- Hi David, In your patch: boolean intr = Thread.interrupted(); for (;;) try { lock.readLock().acquire(); break; } catch (InterruptedException ex) { intr = true; } I don't understand why in JBM needs to reset the interrupted state of the calling thread. My reason: 1. If the thread is interrupted by someone, JBM assumes no responsibility of resetting it. The interrupter should know of the consequence of his action and be prepared for any exceptions caused by this interruption. Actually this code may produce an effect that against the will of the interrupter, see the following comment from JBAS-6546: ...To avoid a rogue plugin degrading the plugin container performance as a whole, the plugin container invokes plugin component methods via a thread pool/future/timeout mechanism - if a plugin component's facet method takes too long to complete, a timeout will trigger, the plugin container will abort and the thread will be interrupted. So if the above code is applied, it possible that the thread will wait there for long even if the caller has interrupted it. 2. The acquire() method's InterruptedException indicates a failure of acquiring the lock, nothing more nothing less. We can't assume too much about the internal impl of this method. If in an environment we're having problem in getting synchronization, then it is a good reason JBM throws exception notifying any interested party that JBM is not able to work properly under such a condition. wdyt? Howard -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira