You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our caching solution with NATS works really great! We use a hosted NATS service and out FastAPI GCP Cloud Run instances (minimum 4) connect to it to write and read JetStream KV items.
But, after around 1 day we get errors in Sentry like:
[Errno 104] Connection reset by peer
nats: timeout
Error getting key value: nats: timeout
ConnectionDoesNotExistError
And then after a few minutes it works again like a champ.
Looking at the NatsService initialisation we just do this on FastAPI instance startup once. so with out current setup of 4 instances this is just 4 connections.
Were can we look to resolve or debug this issue? Has anyone else used NATS as KV also? Or are we implementing it in a totally wrong way?
First of all, network is never-guaranteed thing. Time-outs is OK until it's too much. How often it happens? What's network quality?
Are you using any network retry library? What's packet losses in your setup?
The meaning is: "Query NATS Jetstream metadata about stream". Cache that data, don't query that every single time.
How much streams you have? They have identical TTL, just different names.
If you have not so much data, you can bring an excellent Watch feature of NATS KV. You can store some values directly in RAM of every worker, and update them with incoming KV messages. Even if data is more than single worker machine RAM, you can use Watch on specific key or key part, because it's all subjects under the hood. Bring pieces on demand. Forget them too. That's much faster, because you eliminate a network round trip at all.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Our caching solution with NATS works really great! We use a hosted NATS service and out FastAPI GCP Cloud Run instances (minimum 4) connect to it to write and read JetStream KV items.
But, after around 1 day we get errors in Sentry like:
And then after a few minutes it works again like a champ.
Looking at the
NatsService
initialisation we just do this on FastAPI instance startup once. so with out current setup of 4 instances this is just 4 connections.Were can we look to resolve or debug this issue? Has anyone else used NATS as KV also? Or are we implementing it in a totally wrong way?
Thanks.
Here is the code we use:
Our NATS Service:
The NATS Service gets initialised on instance start with Dishka DI https://github.com/reagento/dishka:
And this is how we retrieve the cached items:
Beta Was this translation helpful? Give feedback.
All reactions