Commit Graph

311 Commits

Author SHA1 Message Date
Olaoluwa Osuntokun
1e3635b5aa
chainntnfs: properly account for partial historical confirmation dispatch
This commit modifies the recently added logic to the ChainNotifier to:
  1. Fix the off-by-one confirmation error that was missed due a flaky
test
  2. Ensure that partial historical confirmations are properly handled.

The partial hostile confirmation case arises when a transaction already
a non-zero number of confirmations when the notification is registered,
but less than what would trigger the confirmation notification. To fix
this, transaction which have a partial number of confirmation are now
properly inserted into the confHeap, skipping first first phase for
notifications.
2016-12-08 16:16:29 -08:00
bryanvu
909c3f8df9 chainntfs: add checks for previously confirmed transactions and spends
Without these checks, “zombie” notification requests that would never
be dispatched could be registered. This would occur if notification
requests were made for events (transaction confirmation and output
spent) that had already been recorded on the blockchain.
2016-12-08 12:28:15 -08:00
Olaoluwa Osuntokun
7b016fef0a
chainntfns: extend testSpendNotification to test for multi-client dispatch 2016-11-27 19:18:24 -08:00
Olaoluwa Osuntokun
d1f12627d2
chainntfns/btcdnotify: add support for multi-dispatch spend notifications
This commit adds support for dispatching the same spend notification to
multiple clients. This is now required by the ChainNotiifer interface
documentation and will be needed within the daemon in order to support
some upcoming refactors.
2016-11-27 19:17:34 -08:00
Olaoluwa Osuntokun
0bd5c6790d
chainntfns: specify that implementations must support multiple clients
This commit updates the documentation for the ChainNotifier interface
to specify that all implementation MUST be able to support dispatching
the same notification to multiple clients.
2016-11-27 19:16:06 -08:00
Olaoluwa Osuntokun
913504581d
chainntfns: eliminate dead lock possibility when dispatching notifications
This commit fixes a possible dead lock when dispatching notifications
caused by the circular communication between the notificationDisptcher
thread and the main notification thread within the btcrpcclient.

Rather than potentially blocking for eternity on a blocking send,
notifications are now instantly handled by appending the notification
on an unbounded queue then launching a goroutine to signal the
dispatcher thread that a new item is available within the queue.
2016-09-22 19:12:22 -07:00
Olaoluwa Osuntokun
112ad616f6
chainntnfs: remove unnecessary print statement in tests 2016-09-13 15:33:32 -07:00
Olaoluwa Osuntokun
39044cb2fa
chainntnfs: fix recursive loop, add additional logging 2016-09-12 19:07:48 -07:00
Olaoluwa Osuntokun
0873c4da76
chainntnfs: add multi-client txid support for confirmation notifications
This commit adds multi-client support for confirmation notification of
the same transaction. Within the daemon there might be scenarios where
multiple goroutines are waiting for the same transaction to be
confirmed in order to properly fulfill their tasks. Previously if
multiple clients were registered for the same txid confirmation
notification, then only the client who registered last would receive
the notification.
2016-09-12 19:07:16 -07:00
Olaoluwa Osuntokun
e72c52288d
chainntfns: implement RegisterBlockEpochNtfn for BtcdNotifier, add tests 2016-09-12 19:07:08 -07:00
Olaoluwa Osuntokun
4d1a1d2799
chainntnfs: add cross interface implementation tests
This commit refactors the existing chainntnfns package in order to
allow more easily allow integration into the main system, by allowing
one to gain access to a set of end-to-end tests for a particular
ChainNotifier implementation.

In order to achieve this, the existing set of tests for the only
concrete implementation (`BtcdNoitifer`) have been refactored to test
against all “registered” notifier interfaces registered. This is
achieved by creating the concept of a “driver” for each concrete
`ChainNotifer` implementation. Once a the package of a particular
driver is imported, solely for the side effects, the init() method
automatically registers the driver.

Additionally, the documentation in various areas of the package have
been cleaned up a bit.
2016-09-01 19:13:10 -07:00