When using https://github.com/fluree/nexus-load-script to test concurrent txns locally against server, errors are thrown when 2+ txns are submitted concurrently. The following behavior is observed:
Exception updating commit with new index errors are surfaced, but 200 responses still sent to client
Data appears to be added successfully, and is query-able, but it is not clear if the data has been indexed to disk or if the indexes are supporting the query result generation
t values for the ledger are suspect (i.e. 20 txn requests might be issued, 4 at a time, but the final t value is 25+ instead of 20)
While it is hard to test this without both leveraging an in-mem instance (to allow for ephemeral test instances of db) and also an instance that creates index data (which, IIRC, mem conn instances do not), we should add tests for concurrent txns to ensure that the behavior we are experiencing is acceptable (e.g. that all data is being captured and committed, that index data is being written comprehensively, that commit/t value handling is correct)
Description
When using https://github.com/fluree/nexus-load-script to test concurrent txns locally against
server, errors are thrown when 2+ txns are submitted concurrently. The following behavior is observed:Exception updating commit with new indexerrors are surfaced, but 200 responses still sent to clienttvalues for the ledger are suspect (i.e. 20 txn requests might be issued, 4 at a time, but the finaltvalue is 25+ instead of 20)While it is hard to test this without both leveraging an in-mem instance (to allow for ephemeral test instances of
db) and also an instance that creates index data (which, IIRC,memconn instances do not), we should add tests for concurrent txns to ensure that the behavior we are experiencing is acceptable (e.g. that all data is being captured and committed, that index data is being written comprehensively, that commit/tvalue handling is correct)