Announcing beta for new NodeJS, Python, dotnet and rust SDK

Funny, I wrote an almost similar post, but then decided I was not in the right to share your data on the forum, so I added it to a draft email.
I then decided to also run a test with your code, so I decided not to send it. I added my email below, but yes, I agree, I think this is a CLR “issue” and I just .NET that is used to things using more RAM.

Just a quick catch up.

  • I see OpenFlow has been running non-stop for more than 7 days.
  • I need to conclude the memory “issue” is a .NET CLR issue and not an error in my code. Here is the last 7 days with your own code in your environment:

That non-stop increase over multiple days hurts my eyes. I don’t like it, but I saw the same in my own tests until I told the CLR to stop overcommitting. Here is a 3-day non-stop test in my environment, and it does stabilize either way:

I am 99.9% sure adding the runtimeconfig.template.json will help. Here is my test with runtimeconfig.template.json added to the code you shared with me:


( i wanted to wait some hours or a day before taking the last screenshot and send it but still looks like it starts out much lower )

More for others, but still:
This is the graph for the agent running for 2 weeks:


“Iteration: 120403, 2024-11-26T10:11:44.3529465+00:00”
That’s 120k iterations of checking 2 queues every 10s.
The left-most graph spiking up and down is just a timing/grouping thing, since it’s a 10s await in-between the checks, so things shift a tiny bit.
There were no restarts during that time (as confirmed by the uptime on the right).
So from everything I can gather, the .Net part is stable with the 0.0.15 version of the api package running on the 111-4 agent image.

Would be nice to get a namespace as discussed up in the thread, and IMHO it could be bumped to 0.1.0 with that, as it’s a) pretty much feature complete, b) stable. And the change in minor is I think justified the moment the namespace is added, as it would be a breaking change by definition.

1 Like