When using jinterop to query WMI via Wbem classes, I have found that WMI query results initally return fairly quickly, but throughput slowly degrades under it is unacceptably slow. Meanwhile, CPU and memory of the client have gone up. This occurs after only a few thousand items.
Debugging into it, I found that the root cause is this log line within JIComOxidRuntime.addUpdateOXIDs:
Calling toString on holder renders every single element in the map. Once you have a few thousand items in the map, this string alone is about >1MB in size. Naturally, performance is destroyed if you are walking the map and allocating ~1MB strings hundreds of times per second.
I guess this project is no longer publishing new releases, but I wonder why this logging was not done at FINEST level or similar? I would love to get some of the other INFO logs, but can't afford to allow this one line to execute.
Last edit: Lincoln Atkinson 2016-02-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When using jinterop to query WMI via Wbem classes, I have found that WMI query results initally return fairly quickly, but throughput slowly degrades under it is unacceptably slow. Meanwhile, CPU and memory of the client have gone up. This occurs after only a few thousand items.
Debugging into it, I found that the root cause is this log line within
JIComOxidRuntime.addUpdateOXIDs
:Calling
toString
onholder
renders every single element in the map. Once you have a few thousand items in the map, this string alone is about >1MB in size. Naturally, performance is destroyed if you are walking the map and allocating ~1MB strings hundreds of times per second.I guess this project is no longer publishing new releases, but I wonder why this logging was not done at FINEST level or similar? I would love to get some of the other INFO logs, but can't afford to allow this one line to execute.
Last edit: Lincoln Atkinson 2016-02-05