- 25 Apr, 2017 1 commit
-
-
Julien Muchembled authored
-
- 24 Apr, 2017 6 commits
-
-
Julien Muchembled authored
The election is not a separate process anymore. It happens during the RECOVERING phase, and there's no use of timeouts anymore. Each master node keeps a timestamp of when it started to play the primary role, and the node with the smallest timestamp is elected. The election stops when the cluster is started: as long as it is operational, the primary master can't be deposed. An election must happen whenever the cluster is not operational anymore, to handle the case of a network cut between a primary master and all other nodes: then another master node (secondary) takes over and when the initial primary master is back, it loses against the new primary master if the cluster is already started.
-
Julien Muchembled authored
-
Julien Muchembled authored
-
Julien Muchembled authored
-
Julien Muchembled authored
In order to do that correctly, this commit contains several other changes: When connecting to a primary master, a full node list always follows the identification. For storage nodes, this means that they now know all nodes during the RECOVERING phase. The initial full node list now always contains a node tuple for: - the server-side node (i.e. the primary master): on a master, this is done by always having a node describing itself in its node manager. - the client-side node, to make sure it gets a id timestamp: now an admin node also receives a node for itself.
-
Julien Muchembled authored
This keeps the connection fully functional when a handler raises an exception.
-
- 19 Apr, 2017 2 commits
-
-
Julien Muchembled authored
Commits like 7eb7cf1b ("Minimize the amount of work during tpc_finish") dropped what was done in commit 07b48079 ("Ignore some requests, based on connection state") to protect request handlers when they respond. This commit fixes this in a generic way.
-
Julien Muchembled authored
-
- 18 Apr, 2017 4 commits
-
-
Julien Muchembled authored
The initial intention was to rely on stable sorting when several events have the same key. For this to happen, sorting must not continue the comparison with the second item of events. This could lead to data corruption (conflict resolution with wrong base): FAIL: testNotifyReplicated (neo.tests.threaded.test.Test) ---------------------------------------------------------------------- Traceback (most recent call last): File "neo/tests/threaded/__init__.py", line 1093, in wrapper return wrapped(self, cluster, *args, **kw) File "neo/tests/threaded/test.py", line 2019, in testNotifyReplicated self.assertEqual([15, 11, 13, 16], [r[x].value for x in 'abcd']) File "neo/tests/__init__.py", line 187, in assertEqual return super(NeoTestBase, self).assertEqual(first, second, msg=msg) failureException: Lists differ: [15, 11, 13, 16] != [19, 11, 13, 16] First differing element 0: 15 19 - [15, 11, 13, 16] ? ^ + [19, 11, 13, 16] ? ^
-
Julien Muchembled authored
-
Julien Muchembled authored
'aborted' could appear twice.
-
Julien Muchembled authored
-
- 13 Apr, 2017 1 commit
-
-
Julien Muchembled authored
-
- 04 Apr, 2017 1 commit
-
-
Kirill Smelkov authored
zodburi[1] provides a way to open ZODB storages by URL/URI. It already has support for file:// zeo:// zconfig:// memory:// etc schemes out of the box and third-party-to-ZODB storages can add support for their schemes via providing zodburi.resolvers entrypoint. For example relstorage and newtdb do this. Let's also teach NEO to open itself via neo:// URI schema. [1] http://docs.pylonsproject.org/projects/zodburi [2] https://github.com/zodb/relstorage/blob/2.1a1-15-g68c8cf1/relstorage/zodburi_resolver.py [3] https://github.com/newtdb/db/blob/0.5.2-1-gbd36e90/src/newt/db/zodburi.py
-
- 31 Mar, 2017 14 commits
-
-
Julien Muchembled authored
Commit 58d0b602 didn't fix the issue completely. Storage space can be freed with --repair option. This adds an expectedFailure test.
-
Julien Muchembled authored
This is a follow up of commit 64afd7d2, which focused on read accesses when there is no transaction activity. This commit also includes a test to check a simpler scenario that the one described in the previous commit.
-
Julien Muchembled authored
-
Julien Muchembled authored
Commit ad43dcd3 should have bumped it as well.
-
Julien Muchembled authored
Unused but it is likely to be useful in the future.
-
Julien Muchembled authored
The bug could lead to data corruption (if a partition is wrongly marked as UP_TO_DATE) or crashes (assertion failure on either the storage or the master). The protocol is extended to handle the following scenario: S M partition 0 outdated <-- UnfinishedTransactions ------> replication of partition 0 ... partition 1 outdated --- UnfinishedTransactions ... ... replication finished --- ReplicationDone ... tweak <-- partition 1 discarded -------- tweak <-- partition 1 outdated --------- ... UnfinishedTransactions --> ... ReplicationDone ---------> The master can't simply mark all outdated cells as being updatable when it receives an UnfinishedTransactions packet.
-
Julien Muchembled authored
-
Julien Muchembled authored
After an attempt to read from a non-readable, which happens when a client has a newer or older PT than storage's, the client now retries to read. This bugfix is for all kinds of read-access except undoLog, which can still report incomplete results.
-
Julien Muchembled authored
-
Julien Muchembled authored
-
Julien Muchembled authored
This revert commit bddc1802, to fix the following storage crash: Traceback (most recent call last): ... File "neo/lib/handler.py", line 72, in dispatch method(conn, *args, **kw) File "neo/storage/handlers/master.py", line 44, in notifyPartitionChanges app.pt.update(ptid, cell_list, app.nm) File "neo/lib/pt.py", line 231, in update assert node is not None, 'No node found for uuid ' + uuid_str(uuid) AssertionError: No node found for uuid S3 Partitition table updates must also be processed with InitializationHandler when nodes remain in PENDING state because they're not added to the cluster.
-
Julien Muchembled authored
-
Julien Muchembled authored
-
Julien Muchembled authored
-
- 30 Mar, 2017 1 commit
-
-
Julien Muchembled authored
-
- 23 Mar, 2017 9 commits
-
-
Julien Muchembled authored
In the worst case, with many clients trying to lock the same oids, the cluster could enter in an infinite cascade of deadlocks. Here is an overview with 3 storage nodes and 3 transactions: S1 S2 S3 order of locking tids # abbreviations: l1 l1 l2 123 # l: lock q23 q23 d1q3 231 # d: deadlock triggered r1:l3 r1:l2 (r1) # for S3, we still have l2 # q: queued d2q1 q13 q13 312 # r: rebase Above, we show what happens when a random transaction gets a lock just after that another is rebased. Here, the result is that the last 2 lines are a permutation of the first 2, and this can repeat indefinitely with bad luck. This commit reduces the probability of deadlock by processing delayed stores/checks in the order of their locking tid. In the above example, S1 would give the lock to 2 when 1 is rebased, and 2 would vote successfully.
-
Julien Muchembled authored
-
Julien Muchembled authored
This fixes a bug that could to data corruption or crashes.
-
Julien Muchembled authored
It becomes possible to answer with several packets: - the last is the usual associated answer packet - all other (previously sent) packets are notifications Connection.send does not return the packet id anymore. This is not useful enough, and the caller can inspect the sent packet (getId).
-
Julien Muchembled authored
-
Julien Muchembled authored
-
Julien Muchembled authored
-
Julien Muchembled authored
-
Julien Muchembled authored
-
- 22 Mar, 2017 1 commit
-
-
Julien Muchembled authored
In reality, this was tested with taskset 1 neotestrunner ...
-