Actually the race could happen in production. the real race is because LockFile will have true to remove file when unlocking. The other server could eventually lock the file before it was removed and then it would not be locked later.
you could have a server not eventually waking up because of the removal. To fix this on SharedFileLock you would have to use false on stopping the server. I have a test replicating the issue and the test will pass with the fix. Should I commit the fix and the test? On Tue, Apr 7, 2015 at 5:43 PM, Clebert Suconic <clebert.suco...@gmail.com> wrote: > I can take a look on fixing it tomorrow. > > > Take a look at my last commit later please as I have added a test for it. > > On Tue, Apr 7, 2015 at 5:39 PM, Gary Tully <gary.tu...@gmail.com> wrote: >> I think the in vm case is only used in some tests, so it is not >> critical but would be a nice addition to have it correct. >> >> On 7 April 2015 at 22:33, Clebert Suconic <clebert.suco...@gmail.com> wrote: >>> I took this JIRA to fix here: >>> >>> https://issues.apache.org/jira/browse/AMQ-5709 >>> >>> https://github.com/apache/activemq/pull/82 >>> >>> >>> >>> and I discovered a race into LockFile.java >>> >>> >>> Basically Lock will return false if you run the test I wrote in loop. >>> It's non related to my change.. but I will add the test anyways... the >>> test could fail eventually in loop >>> >>> >>> locked is not synchronized in all paths.. There are some issues with it. >>> >>> >>> Should I leave this alone? It seems it's only an issue under the same >>> VM though. although it could be something else happening. > > > > -- > Clebert Suconic > http://community.jboss.org/people/clebert.suco...@jboss.com > http://clebertsuconic.blogspot.com -- Clebert Suconic http://community.jboss.org/people/clebert.suco...@jboss.com http://clebertsuconic.blogspot.com
