[network] Performance refactoring 5.0.x#19427
Conversation
…nhab#17972) * Fix performance * Improvements * Add logging * Improve logging * Update bundles/org.openhab.binding.network/src/main/java/org/openhab/binding/network/internal/utils/NetworkUtils.java * Improve thread handling * Improve shutdown * thread cleanup * Improve per thread allocation * Stop on finishing all interfaces * Change Arping to make use of completeablefeature * Seperate presence detection from lifecycle * Improve logging and filtering * Create seperate ScheduledExecutorService * Fix review comment * Improve network address checks * Improve interrupthandling * Revert threadlocal * Refactor Presencedetection * Make LatencyParser accept Windows' <1ms syntax for minimal latency * Remove misleading reference to non-existing NetworkHandlerBuilder * Handle thread-safety of NetworkDiscoveryService.executorService * Fix network interface exclusion * Make PresenceDetectionValue thread-safe * Partial refactoring of PresenceDetection Fixes: - Synchronization of lastSeen - Joining of async tasks - Minor logging improvements Addition: - Create setIcmpPingMethod() * Partial refactoring of NetworkDiscoveryService Fixes: - Correct the number of addresses in a /24 subnet. - Restructure task creation so that one less thread is needed per scanned address, and so that startScan() is guaranteed to return quickly. - Create independent threads for posting discovery results, as this can take a long time and might not finish before the executor shuts down. * Make NetworkHandler thread-safe * Make SpeedTestHandler thread-safe * Make sure that process output is consumed * Implement tool-specific latency parsing * Fix NetworkDiscoveryService configuration and make the thread pool size configurable * i18n * Fix test Signed-off-by: Leo Siepel <leosiepel@gmail.com> Co-authored-by: Wouter Born <github@maindrain.net> Co-authored-by: Ravi Nadahar <nadahar@rediffmail.com>
…nhab#19398) * Use a threaded consumer for Process output consumption Signed-off-by: Ravi Nadahar <nadahar@rediffmail.com>
|
@lsiepel I've created this for 5.0.x. My guess is that it will backport smoothly to 4.3.x too, but I can try to verify that. Given #19398 (comment), I assume that we should let this PR hang around for a while. The big question is how to remember it when the time is due..? |
|
For some reason your signature fails the DCO check... but it probably doesn't matter. |
|
@lsiepel It didn't backport cleanly to 4.3.x, because #18083 hasn't been backported either. I figured that #18083 has been out for a while and can be considered "safe", and the changes it makes are important improvements IMO, so I simply included it as well in #19428. That meant that there were no conflicts, so it should work "smoothly". |
lsiepel
left a comment
lsiepel
left a comment
There was a problem hiding this comment.
Thanks, will backport later when no regressions have been found and prior to next patch release.
@jlaur I don't know your internal routines for backporting, release notes and all that. I did cherry-pick them, but I didn't know in advance if there would be conflicts or not. It turns out there were none, so yeah, technically this PR does very little. But, I've still done the cherry-picking - and why waste what has already been done? I chose to create the two PRs with the cherry-picks so that nobody else had to repeat it 😉 In this case, where we want to hold off the backports a bit to make sure there are no regressions, it might be easier to handle merging a couple of PR's than cherry-picking 5 commits (the situation is the same with #19428) in the correct order when the time is due? This is all up to you guys and how you want to handle it, I'm just trying to make things easier. |
It's all good, just wanted to double-check what this PR represents. 🙂 |
3 participants
This is a backport that combines #17972 and #19398
This probably shouldn't be squashed to retain the references to the original PRs.