Subject: Introduction - Oleksandr Klymenko (PR #2734) Hi,
I was asked to introduce myself here before PR #2734 gets reviewed, so: I'm Oleksandr [Alex] Klymenko, alxkm on GitHub. Java developer, about 12 years, mostly backend and web. I contribute to a few Java projects but I'm new to PLC4X and to industrial automation in general. Let me answer the use case question directly, because the answer is that I don't have one. No PLC hardware, no production system behind this. I've wanted to get into this side of software for a while and came at it from the only angle I know, the JVM. I read through spi to learn the codebase, and RequestThrottle is where I stopped, because throttling and concurrency are what I do at work; rate limiting in a web backend is much the same problem. What I found is written up in the PR: a limit reduction that can't be fully applied while requests are in flight gets silently dropped, so the throttle ends up permanently above the limit it was configured for. 12 tests added; the 8 that compile against develop all fail there. What I can't judge is whether this matters to you. No driver hits it today. And I don't know the protocol constraints behind the throttling policy, which is why I didn't touch the policy itself. If the current behaviour is deliberate, or you'd rather it were fixed differently, or split up, tell me and I'll follow. I'd rather stick around than land one patch and vanish. No hardware, but the simulated driver and the test suite look like enough to work against. If there's somewhere a Java developer is actually useful to you, point me at it. Oleksandr (Alex)
