(Persistent) Subscriptions implementation details

EventStoreDB
#1

Greetings,

In the process of trying of new things in my Haskell driver implementation, I had questions related to subscriptions.

Here’s the use case.

  • At time t, we have a connection to a persistent subscription running.

  • At t+1, we lose the connection with the server.
    While we lose the connection with the server, it’s possible we have a bunch of Packages waiting to be sent. Let’s pretend one of those is an Ack command.

  • At t+2, we created a new connection with the server.
    Now, is it sensible to try sending this package (Ack command), and would it be executed ? My current implementation is to discard everything and act like we have started from a fresh connection.

The thing is I’d like to be more flexible about this. While I think it is totally sensible to send operation command that missed the opportunity to be sent with the previous connection (like Write|Read commands or Subscription requests), I’m not so sure about other kind of commands like pending Transaction write|commit or persistent Ack|Nak commands. Could you shed some light please ?

Regards,

Yorick

#2

Any chance to get an input about this ?

#3

Missed it.

Inline.

Greetings,

In the process of trying of new things in my Haskell driver implementation,
I had questions related to subscriptions.

Here's the use case.

At time t, we have a connection to a persistent subscription running.
At t+1, we lose the connection with the server.

While we lose the connection with the server, it's possible we have a bunch
of Packages waiting to be sent. Let's pretend one of those is an `Ack`
command.

At t+2, we created a new connection with the server.

Now, is it sensible to try sending this package (Ack command), and would it
be executed ? My current implementation is to discard everything and act
like we have started from a fresh connection.

you can send it, it may or may not be accepted depends on bunches of
things like if the server knows already that your connection was
dropped. frankly its not really worth the trouble, they will get
retried anyways.

The thing is I'd like to be more flexible about this. While I think it is
totally sensible to send operation command that missed the opportunity to be
sent with the previous connection (like Write|Read commands or Subscription
requests), I'm not so sure about other kind of commands like pending
Transaction write|commit or persistent Ack|Nak commands. Could you shed some
light please ?

This is exactly what the .net client does. It queues and retries on
connection loss. This is part of why things are idempotent in the
server.