[
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)
