Multiple ReadJournal instances cause actor name conflicts and incorrect query throttling

[Aaronontheweb]

Version Information
Version of Akka.NET? v1.5.40
Which Akka.NET Modules? Akka.Persistence.Sql

Problem Description

When running multiple persistence journals in the same Akka.NET application with Akka.Persistence.Sql, creating multiple ReadJournal instances causes actor name conflicts. This occurs when multiple projection actors (ReceivePersistentActor instances) try to create their own read journals using Context.System.ReadJournalFor<SqlReadJournal>().

Error Messages

Users encounter either of these exceptions:

• Actor name "akka.persistence.query.journal.contact-query-permitter" is not unique\!
• Actor name "journalakka-persistence-sql-sequence-actor" is not unique\!

Current Implementation Issues

1. ReadJournal is being created multiple times unnecessarily
2. Each ReadJournal creates its own query throttler, defeating the purpose of having a throttler in the first place
3. The actors are created in the /user hierarchy instead of being /system actors

Reproduction Steps

1. Create multiple persistence journals in the same Akka.NET application
2. Use these journals for data projections to various destinations (SQL, RabbitMQ, etc.)
3. Run multiple projector actors simultaneously
4. When the second projection actor reaches its OnReplaySuccess() method and calls:

var readJournal = Context.System.ReadJournalFor<SqlReadJournal>("my-domain-name");

The exception is thrown.

Technical Details

• Version: 1.5.38.1 (also present in 1.5.40)
• Relevant Code:
  • SqlReadJournal.cs#L86-L88
  • SqlReadJournalProvider.cs#L25-L26

Proposed Solutions

1. Make the ReadJournal and query throttler singleton instances
2. Move the actors to the /system hierarchy instead of /user
3. Implement proper naming/scoping for these actors when multiple journals are in use

Impact

This issue affects anyone trying to run multiple projections simultaneously using Akka.Persistence.Sql, which is a common use case for data projections and event sourcing scenarios.