OverlappingFileLockException with WalletAppKit

[Adam Mackler]

I just started using the WalletAppKit and it has saved me a lot of code, so thank you.

One thing has started happening, not infrequently when starting my app I get OverlappingFileLockException from line 110 in SPVBlockStore.java:

fileLock = channel.tryLock();

This is bitcoinj version 0.10.1.  I'm curious what causes this, whether I'm doing something wrong, and what the consequence is, namely does it mean I need to stop and restart the application?

Eventually I'll investigate these questions myself, but if anyone can save me some time and maybe give me some insight that might otherwise elude me, I'll be all the more grateful.

Thanks,

--

Adam Mackler

[Adam Mackler]

This happens when constructing the SPVBlockStore.  For some reason RandomAccessFile.getChannel().tryLock() is raising java.nio.channels.OverlappingFileLockException indicating an overlapping lock is already held by the invoking JVM, or another thread is already blocked in tryLock() and is attempting to lock the block chain file.  My only interaction with the SPV block chain file is through the WalletAppKit, so I don't think I'm doing anything that would be locking the file.

Unfortunately I don't know much about how files are locked, whether it's in the kernel or some bit is set on the disk somewhere.  Maybe it's system-dependent.  I'm using FreeBSD.  Is it possible that shutting down the application improperly leaves the block chain file locked until it runs again?  I'm stopping my application by interrupting it with control-C.

In constructing my WalletAppKit I also override onSetupCompleted() like this

WalletAppKit kit = new WalletAppKit(networkParams, new File("."), "myApp") {

  @override void onSetupCompleted() {

    if (wallet.getKeychainSize() < 1) wallet.addKeys(allKeys);

    wallet.addEventListener(onCoinsReceived);

  }

}

Could this be causing the OverlappingFileLockException on the SPV block chain file?  I don't think this should be happening.  I'm probably doing something wrong.  I'm going to keep thinking about it, but if posting any diagnostics would make it possible for anyone to give me a clue, I'll be glad to do so.

Thanks,

--

Adam Mackler

[Mike Hearn]

Is there any chance you're somehow running two WalletAppKit's in the same process both with "myApp" as a prefix?

It's correct that the code throws if the block store file is already in use. However this (on all my machines) surfaces as a BlockStoreException. File locks are handled by the kernel and you cannot get stale locks that hang around after process termination, it would be a kernel bug if that were possible. I've never seen an OverlappingFileLockException - the docs tell me this can happen when the same JVM tries to lock the same file twice (as opposed to two different processes). So it could happen if there were to be two SPVBlockStores trying to use the same file in the same process at once.

--
You received this message because you are subscribed to the Google Groups "bitcoinj" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinj+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Adam Mackler]

On Monday, September 30, 2013 4:34:49 AM UTC-4, Mike Hearn wrote:

Is there any chance you're somehow running two WalletAppKit's in the same process both with "myApp" as a prefix?

I'm pretty sure that in converting to using WalletAppKit I had not completely removed all the prior code that was setting up the block chain file.  Probably won't affect new development using WalletAppKit, but something to look out for when converting existing code.

Thanks again,

--

Adam Mackler

[Adam Mackler]

Scratch that.  I'm pretty sure I know what it was now.  I'm using bitcoinj with the Akka actors library.  One of my actors was starting the WalletAppKit then calling WalletAppKit.peerGroup.numConnectedPeers() before the network was initialized.  When invoked too soon peerGroup() returns null, I was getting a NPE, and the Actor crashed.  The default behavior for Akka it to try to restart crashed Actors, thus I ended up with multiple threads all invoking the WalletAppKit methods that try to initialize the chain file.

--

Adam Mackler

[Mike Hearn]

I see. Yes, that does seem like a rather complex failure mode.

--