[ https://issues.apache.org/jira/browse/DAEMON-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871350#comment-17871350 ]
Mark Linley commented on DAEMON-460: ------------------------------------ Hi [~markt] I tried changing our code to blocking on start until stop is called and that did appear to resolve the issue. Thanks for pointing that out in the documentation. I accept that we missed the documentation here. I think the confusion for me comes down to the naming. I would expect a start method to return quickly and then the application would be in a running state. Then later you call 'stop' and it stops. In this case the 'start' method is more of a 'run' method which would be expected to block until the app is no longer running. Perhaps on the native side, things could be more robust to cater for scenarios where a possible 100% CPU utilization condition is exposed, like in this case. At the least, perhaps a warning in the log file saying that the start method has returned before stop has been called. I also think some throttle or pause to avoid the stuck loop in this scenario might also be advisable. Thanks for all your help. > High CPU usage in prunsrv.exe since Daemon 1.3.3 > ------------------------------------------------ > > Key: DAEMON-460 > URL: https://issues.apache.org/jira/browse/DAEMON-460 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv > Affects Versions: 1.3.3 > Reporter: Japie vd Linde > Priority: Major > Attachments: EspRun-Service-Log.2023-06-05.log, > image-2023-05-31-09-31-21-485.png, image-2023-06-05-13-38-38-435.png, > image-2024-05-29-15-56-35-585.png, image-2024-05-29-15-57-37-665.png, > image-2024-05-31-10-00-10-916.png, test-windows-service.zip > > > When using the --StopTimeout=30 parameter on service using prunsrv the CPU > usage is reported as very high on Windows. Rolling back to older prunsrv > seems to resolve the problem. > !image-2023-05-31-09-31-21-485.png! > What could be the possible causes for this problem? -- This message was sent by Atlassian Jira (v8.20.10#820010)