search

novitski / bitcoinj

Automatically exported from code.google.com/p/bitcoinj
Apache License 2.0
0 stars 0 forks source link

Split processing on repla not as robust as it could be. #376

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
This week I have been adding block replay into MultiBit for the bcj 0.8-MASTER 
code.
I have it working but it is not as robust as it could be.

The main area is of trouble is the AbstractBlockChain#findSplit and related 
methods.
This is typical:

14:02:25.127 [New I/O worker #2] WARN com.google.bitcoin.core.Peer - 
[80.218.174.253]:8333 - java.lang.NullPointerException: Attempt to follow an 
orphan chain
at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:204) 
~[multibit-exe.jar:na]
at 
com.google.bitcoin.core.AbstractBlockChain.findSplit(AbstractBlockChain.java:615
) ~[multibit-exe.jar:na]
at 
com.google.bitcoin.core.AbstractBlockChain.handleNewBestChain(AbstractBlockChain
.java:524) ~[multibit-exe.jar:na]
at 
com.google.bitcoin.core.AbstractBlockChain.connectBlock(AbstractBlockChain.java:
483) ~[multibit-exe.jar:na]
at com.google.bitcoin.core.AbstractBlockChain.add(AbstractBlockChain.java:359) 
~[multibit-exe.jar:na]
at com.google.bitcoin.core.AbstractBlockChain.add(AbstractBlockChain.java:247) 
~[multibit-exe.jar:na]
at com.google.bitcoin.core.Peer.endFilteredBlock(Peer.java:741) 
~[multibit-exe.jar:na]
at com.google.bitcoin.core.Peer.processMessage(Peer.java:257) 
~[multibit-exe.jar:na]
at com.google.bitcoin.core.Peer.access$400(Peer.java:48) ~[multibit-exe.jar:na]
at com.google.bitcoin.core.Peer$PeerHandler.messageReceived(Peer.java:237) 
~[multibit-exe.jar:na]
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296) 
~[multibit-exe.jar:na]
at 
org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(Fr
ameDecoder.java:462) ~[multibit-exe.jar:na]
at 
org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecode
r.java:536) ~[multibit-exe.jar:na]
at 
org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingD
ecoder.java:435) ~[multibit-exe.jar:na]
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) 
~[multibit-exe.jar:na]
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) 
~[multibit-exe.jar:na]
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) 
~[multibit-exe.jar:na]
at 
org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.j
ava:107) ~[multibit-exe.jar:na]
at 
org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.j
ava:312) ~[multibit-exe.jar:na]
at 
org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:
88) ~[multibit-exe.jar:na]
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) 
~[multibit-exe.jar:na]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:8
95) [na:1.6.0_43]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) 
[na:1.6.0_43]
at java.lang.Thread.run(Thread.java:680) [na:1.6.0_43]

The net result of this is that the Peer gets dropped and so you waste time 
creating a new one. It still works but is not ideal.

Also to get the SPVBlockStore to replay ok I am creating a brand new 
SPVBlockStore on replay. If I don't, the precondition 'higher and lower are 
reversed' in AbstractBlockChain#getPartialChain fires.

Again, recreating a new blockstore works but you always end up having to sync 
back to the last checkpoint even though you have all the block headers since 
then in the SPVBlockStore. This is a bit inefficient.

The code in the MultiBit mb-0.5-bcj-v0.8 branch is what I am working on.

Original issue reported on code.google.com by jimburto...@gmail.com on 28 Mar 2013 at 3:41

GoogleCodeExporter commented 9 years ago 
Hmm. Nobody else has reported that assert firing, so I suspect there's some 
issue with how your replay code is implemented.

Rewinding the chain inherently means making a new one. It always has done - 
same with BOBS. To rewind the chain you need to:

1) Shut down PeerGroup (stopAndWait)
2) Save/close the wallet
3) Save/close the block store
4) Throw away the objects.
5) Delete the chain file
6) Make a new chain file and checkpoint it to the rewind time.
7) Start everything up again

It's very important that the whole thing is shut down before you blow away the 
old chain file and make a new one.

I'll leave this issue open for a while but I suspect the issue is with how the 
chain is being replayed.

Original comment by mh.in.en...@gmail.com on 29 Mar 2013 at 4:47

GoogleCodeExporter commented 9 years ago 
Not been reported elsewhere and I never saw this myself.

Original comment by hearn@google.com on 30 Sep 2013 at 12:57