Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

substrate does not allow non durable subscriptions to Nats streaming #55

Open
slawo opened this issue Mar 18, 2019 · 3 comments
Open

substrate does not allow non durable subscriptions to Nats streaming #55

slawo opened this issue Mar 18, 2019 · 3 comments

Comments

@slawo
Copy link

slawo commented Mar 18, 2019

Connection to Nats streaming are always done using durable groups. This is problematic in cases where the client ID of the subscriber is not the same on reconnection (new pod name for example), or when we don't want to have more than one client for a given durable subscription.

It is preferable to connect to non group subscriptions when a unique instance is consuming events from a queue (ex most projectors in the current configuration)

stan.DurableName(c.conf.QueueGroup),

@mjgarton
Copy link
Contributor

Can you elaborate on the problem please? What actually goes wrong in your application(s) that you need to fix? This issue is phrased like a solution, but I don't understand the problem.

@slawo
Copy link
Author

slawo commented Mar 25, 2019

In case of our projectors we don't want to have more than one consumer for a given sequence of events.
The group subscription (conn.QueueSubscrib) allows multiple consumers for the same stream of events.
This creates the potential for missed messages on one consumer while they are are consumed by another one.
It also creates the potential of stale messages resulting if late redeliveries (broken order) in case of a consumer crashing/and reconnecting with a new client ID.

@mjgarton
Copy link
Contributor

Let me understand first. Are you starting multiple consuming applications (or multiple instances of the same application) with the same QueueGroup ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants