[
https://issues.apache.org/jira/browse/LUCENE-9232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038816#comment-17038816
]
Dawid Weiss commented on LUCENE-9232:
-------------------------------------
I'm not convinced it should be a binary decision. I think the reason you had so
many daemons is that you experiment with different VMs; a daemon is forked for
each different VM/ VMopt combination.
Disabling the daemon has a performance penalty that is going to affect user
experience. And for most people there will always be a single daemon running in
the background... so maybe we can just set daemon expiry to a shorter timeout?
[1]
org.gradle.daemon.idletimeout=[ms]
We *can* add a daemon-disabling setting to local properties but have it
commented out initially (so that folks eyeballing it can enable it if they so
desire)?
[1] https://docs.gradle.org/current/userguide/build_environment.html
> disable gradle daemon by default
> --------------------------------
>
> Key: LUCENE-9232
> URL: https://issues.apache.org/jira/browse/LUCENE-9232
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
> Priority: Major
>
> We should disable the gradle daemon by default: the user can opt-in by
> changing the properties file.
> If you forget to do this, you end out with leaked JVMs everywhere. It won't
> just leak one daemon, it will leak multiple ones.
> I ran {{ps}} on my laptop, surprised at 13:00 to find 2 leaked gradle jvms
> when I hadn't used the thing since 07:00.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
