[jira] [Commented] (LUCENE-9232) disable gradle daemon by default

["Dawid Weiss (Jira)" <ji...@apache.org>]

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org