Model for frequent configuration dynamic updates #2566
-
Hello! In this case, I have YARP receiving connections from different peers and I want to save each peer's cluster for future outbound requests. I was thinking that, when a peer connects, I would build the Cluster and it's Routes and update Yarp with it, but doesn't seem to be possible. Am I thinking this in the wrong way and the modelling should be different for these types of use-cases? I already read #2182, and I am using the an Thank you and best regards, |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Your understanding is sound. InMemoryProvider is a good place to start. You can fork and extend that with Add and Remove methods that update the internal state and signal to YARP that a change is available. Yes this state needs to be managed in a thread safe way, and it needs to provide YARP with a read-only copy each time. Note that you don't have to wait for the YARP update to finish, if another change comes through before the current one is finished it will still be picked up on the next pass. You can cut down on the churn by making those adds and removes batch operations (AddList, RemoveList). |
Beta Was this translation helpful? Give feedback.
Your understanding is sound. InMemoryProvider is a good place to start. You can fork and extend that with Add and Remove methods that update the internal state and signal to YARP that a change is available. Yes this state needs to be managed in a thread safe way, and it needs to provide YARP with a read-only copy each time. Note that you don't have to wait for the YARP update to finish, if another change comes through before the current one is finished it will still be picked up on the next pass. You can cut down on the churn by making those adds and removes batch operations (AddList, RemoveList).