Retries & Error Handling
Messages being processed by neo4j-streams may provoke transaction errors in Neo4j. In general, neo4j-streams does not support retries, and careful thought is needed to design a strategy that will work. For example:
-
Errors may be caused by too much parallelism and node locking when writing relationships; in this case, rather than retries, a different write mechanism is a better idea
-
If Neo4j-streams grows to support retries, it needs to have configurable strategies for how many times to retry, when to backoff, and so on. This would greatly complicate the situation
-
If a cascade of errors starts happening (for example during a leader re-election) under constant load from Kafka, you could have a cascade of retries, which would basically turn into a denial of service attack on the cluster.
For all of these reasons, neo4j-streams doesn’t support retries but sends error messages (at the user’s option) to a configurable dead letter queue. (DLQ). If your application needs retry logic you might consider downstream logic on the DLQ to handle them however is appropriate.
Was this page helpful?