Hi,
after creating a new , very simple service, I ended up in lots and lots of Logs that indicate the creation and deletion of terminators a lot of times per second.
Any idea what this is caused by?
What additional information can I provide for more details?
Woah, that looks very abnormal! Do you know what commands you ran? Also what version of the controller is running?
Is that something you can reproduce? Collecting the logs from the identity making the terminator and the controller would be a good first step.
Hi @dmuensterer,
This is something I also encountered recently. I put some fixes in
The first fix is in OpenZiti v0.31.0.
The second is in the Go SDK v0.20.129.
Let me know what versions you're using, for controller/routers and sdk.
I'm also doing some refactoring in this area, so if you're still seeing the issue with the latest code, I should have something soon that will address the issue.
Paul
I actually did reproduce it - but I don't know how 
I had this problem a couple of days ago already while experimenting with a wildcard intercept.
This time again - I gave a server an identity, the attribute "ssh" for the wildcard service and SSH binding and additionally I created a service via the ZAC "Quick Create" feature to intercept/dial to another server...
Let me please check @plorenz suggestions and pull the logs!
@plorenz I'm running Ziti SDK 0.35.2 on client/server with Ziti Edge Tunnel v0.22.11
Controller is on v0.30.5, one router is running on v0.30.5, one is running on v.29.0.
I know, what I also did - rename the service, configs and policies... Maybe that resulted in an issue somehow? Let me check if the problem persists after restarting the identity where the terminators are created, because I didn't do so after renaming...
Edit: Welp Problem solved after restarting the Ziti-Edge-Tunnel... Interesting 
Were you able to reproduce it while running 0.31.0 on the routers?
No, I’ll try with v0.31.0
Is there a way to gracefully ask identities to connect to another router without just restarting the router and dropping existing connections?
Depending on your definition of 'graceful', "probably". One easy mechanism is you update the edge router policy that indicates the router can be used for the particular service. For example, if it's a public router, you turn off the #public attribute and then it isn't public any more and all your clients stop using it. That's one definition of graceful.
There are other, more fine-grained ways of effecting this via policies but it'll depend on how you have configured the overlay as to what sorts of options to do this would be available.
I believe there has been talk of implementing some kind of message to the endpoints indicatng "please pick another router" which maybe is a bit less abrupt than removing the router from a pool as I mentioned before, but I don't know if that's been implemented yet. I think that was going to be used to support rolling upgrades. I'm just not as close to that as @plorenz is, so I'm not sure if that was implemented yet.
Makes perfect sense and was exactly what I was looking for. Thanks.
I've also noticed the following logs spamming after creating another wildcard service, without any "special" doings afterwards like renaming etc.
But I'm still running v0.30.5 so let me upgrade to v0.31.0 as @plorenz mentioned, a couple things were fixed
