Using the Java client. There doesn’t seem to be any “is now live” notification in the new gRPC client, so I was wondering what is the recommended way for a subscription to detect that it is now “live” mode and can allow queries to the generated read model?
I don’t think it has been implemented, but we’re working on it.
Is there any recommended workaround?
I can tell you what I’m doing currently. Before starting I get the last event’s revision in the stream, and then the catchup subscriber knows to at least read to that revision. After that I check if the events start to “trickle” in (I do batch handling, so any handle with less than full batch qualifies as a “trickle”) and then trigger a custom “subscription is live” notification. Works, but it’s a complete mess.
I am not sure what I can suggest as I never saw the value in this notification. I only measure the gap between the stream and and the last processed event, set up a metric for that, and monitor it (alerting included). As soon as the gap is within an SLA, it’s ok.
When our application starts up it will subscribe to stream and update read model based on where it left off. Sometimes the database is deleted (to force a rebuild), in which case the rebuild might take a long time (hours), and during that time we need to make sure there are no requests to the API. Before the best way to do this was to wait for the live notification, and then continue with application startup sequence and allow API calls to come in. That’s the value of it, in my experience.
Right, blue-green thing. Makes sense. If the number of events per sec isn’t large, the gap measurement can help here too imo.
I believe it has been merged, but not yet released: https://github.com/EventStore/EventStoreDB-Client-Java/pull/144
(From this: Support for detecting a subscription being "live" with gRPC)