- 04 Apr, 2023 7 commits
-
-
Julien Muchembled authored
-
Julien Muchembled authored
- When undoing current record, fix: - crash of storage nodes that don't have the undo data (non-readable cells); - and conflict resolution. - Fix undo deduplication in replication when NEO deduplication is disabled. - client: minor fixes in undo() about concurrent storage disconnections and PT updates.
-
Julien Muchembled authored
undone_data_tid can't be equal to a TTID.
-
Julien Muchembled authored
-
Julien Muchembled authored
-
Julien Muchembled authored
-
Julien Muchembled authored
Found by running testPruneOrphan many times. Once I even got: SystemError: NULL result without error in PyObject_Call
-
- 09 Mar, 2023 2 commits
-
-
Julien Muchembled authored
-
Julien Muchembled authored
The reverts a wrong change in commit 30a02bdc ("importer: new option to write back new transactions to the source database").
-
- 19 Feb, 2023 1 commit
-
-
Julien Muchembled authored
-
- 16 Feb, 2023 2 commits
-
-
Julien Muchembled authored
-
Julien Muchembled authored
-
- 14 Feb, 2023 3 commits
-
-
Julien Muchembled authored
-
Julien Muchembled authored
It's been many years we don't get 'array' objects, no idea when exactly.
-
Julien Muchembled authored
-
- 10 Feb, 2023 1 commit
-
-
Julien Muchembled authored
Like commit 243c1a0f ("sqlite: optimize storage of metadata"), the fake changes in test data are because we don't force upgrade for this optimization.
-
- 02 Feb, 2022 1 commit
-
-
Kirill Smelkov authored
Starting from zodbpickle 2 its binary class does not allow users to set arbitrary attributes and so binary._pack = bytes.__str__ fails with TypeError: can't set attributes of built-in/extension type 'zodbpickle.binary' -> Fix it by explicitly checking for binary type on encoding instead of setting binary._pack See slapos@27f574bc for pre-history. /cc @jerome
-
- 04 Jun, 2021 1 commit
-
-
Julien Muchembled authored
Traceback (most recent call last): ... File ".../neo/lib/handler.py", line 75, in dispatch method(conn, *args, **kw) File ".../neo/admin/handler.py", line 174, in wrapper return func(self, name, *args, **kw) File ".../neo/admin/handler.py", line 190, in notifyMonitorInformation self.app.updateMonitorInformation(name, **info) File ".../neo/admin/app.py", line 290, in updateMonitorInformation self._notify(self.operational) File ".../neo/admin/app.py", line 315, in _notify body += '', name, ' ' + backup.formatSummary(upstream)[1] File ".../neo/admin/app.py", line 83, in formatSummary tid = self.ltid AttributeError: 'Backup' object has no attribute 'ltid'
-
- 11 May, 2021 1 commit
-
-
Julien Muchembled authored
-
- 02 Apr, 2021 5 commits
-
-
Julien Muchembled authored
-
Julien Muchembled authored
-
Julien Muchembled authored
-
Julien Muchembled authored
-
Julien Muchembled authored
-
- 22 Mar, 2021 1 commit
-
-
Julien Muchembled authored
-
- 04 Mar, 2021 2 commits
-
-
Julien Muchembled authored
-
Julien Muchembled authored
-
- 15 Jan, 2021 2 commits
-
-
Julien Muchembled authored
The purpose of suppress_ragged_eofs=False was to micro-optimize the normal case: when there's no EOF. But commit 061cd5d8 showed that this option only turns ragged EOF into an exception. It may be easier for alternate NEO implementations to close the SSL connection properly. Or the performance benefit was not worth the risk to freeze a NEO process.
-
Kirill Smelkov authored
Testing NEO/go client wrt NEO/py server revealed a bug in NEO/py SSL handling: proper non-ragged EOF from a peer is ignored, and so leads to hang in infinite loop inside _SSL.receive with read_buf memory growing indefinitely. Details are below: NEO/py wraps raw sockets with ssl.wrap_socket(suppress_ragged_eofs=False) which instructs SSL layer to convert unexpected EOF when receiving a TLS record into SSLEOFError exception. However when remote peer properly closes its side of the connection, socket.read() still returns b'' to report non-ragged regular EOF: https://github.com/python/cpython/blob/v2.7.18/Lib/ssl.py#L630-L650 The code was handling SSLEOFError but not b'' return from socket recv. Thus after NEO/go client was disconnecting and properly closing its side of the connection, the code started to loop indefinitely in _SSL.receive under `while 1` with b'' returned by self.socket.recv() appended to read_buf again and again. -> Fix it by detecting non-ragged EOF as well and, similarly to how SSLEOFError is handled, converting them into self._error('recv', None). See merge request nexedi/neoppod!17
-
- 11 Jan, 2021 4 commits
-
-
Julien Muchembled authored
-
Julien Muchembled authored
-
Julien Muchembled authored
-
Julien Muchembled authored
The scenario that was described in comments was meaningless because S1 never goes out-of-date.
-
- 02 Oct, 2020 1 commit
-
-
Julien Muchembled authored
For the master, the purpose of -m/--masters is to specify addresses of other master nodes, since its own address is already known via -b/--bind. Therefore, an empty value for -m/--masters is valid. The user remains free to repeat the -b value in -m. More generally, a node may choose to only specify master addresses via -D/--dynamic-master-list, so the check that at least one master address is specified is moved where the NodeManager is expected to be initialized.
-
- 29 Sep, 2020 1 commit
-
-
Julien Muchembled authored
-
- 25 Sep, 2020 4 commits
-
-
Julien Muchembled authored
-
Julien Muchembled authored
The time complexity of previous one was too bad. With several tens of concurrent transactions, we saw commits take minutes to complete and the whole application looked frozen. This new algorithm is much simpler. Instead of asking the oldest transaction to somewhat restart (we used the "rebase" term because the concept was similar to what git-rebase does), the storage gives it priority and the newest is asked to relock (this request is ignored if vote already happened, which means there was actually no deadlock). testLocklessWriteDuringConflictResolution was initially more complex because Transaction.written (client) ignored KeyError (which is not the case anymore since commit 8ef1ddba).
-
Julien Muchembled authored
-
Julien Muchembled authored
-
- 10 Sep, 2020 1 commit
-
-
Julien Muchembled authored
This is all the more important for RocksDB that it wants to keep all transaction work in RAM. Once we had to truncate 40% of a 1TB MyRocks DB with 24 partitions, 4 being processed in parallel. Even when committing between partitions, MariaDB used up to 200 GB. Without the commit, 1TB RAM would not have been enough.
-