lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christine Poerschke (BLOOMBERG/ LONDON)" <>
Subject Re: 10 Resource Leak warnings dated to Q2 2017
Date Wed, 05 Jul 2017 15:39:15 GMT
Hi Erick,

Thanks for the extra context re: JavaBinCodec and SOLR-10779.

I agree that backporting warning fixes to 6x is optional at this point and for complex fixes
probably not worth the risk of introducing subtle bugs in the process.

+1 to your idea of making precommit fail for some but not all resource leaks. Implementation
wise, how might one go about that? Redirecting precommit output and post-processing it should
be do-able but seems hacky ...


----- Original Message -----
To: Christine Poerschke (BLOOMBERG/ LONDON),
At: 07/04/17 16:45:11


I fixed the JavaBinCodec warnings in SOLR-10779 for master/7.0, but
didn't backport to 6x. So if those warnings are creeping back in to
the 7x code line we can take a look.

I didn't backport to 6x since this seems to be long-term enough that
there isn't much point, along with the feeling that we'll introduce
problems at times in the effort and my view is that 6x is close enough
to end of development that we shouldn't expend the effort or introduce
instabilities. Or, put another way, I didn't want to be responsible
for introducing bugs in 6x, 7x is fair game ;)

Along the lines of making forward progress though.... Is it possible
to make precommit fail for resource leaks for specific classes only?
Or for specific files? It wouldn't be perfect, but cleaning up
warnings for a class then having precommit fail if resource leaks came
back in would feel less like Sisyphus.

I'm looking for either of the following. Or both of course.
- fail if precommit issues resource leak warnings for the _class_
JavaBinCodec wherever it's used.
- fail if precommit issues resource leak warnings in the _file_ if any resource leak warnings are found for any class.

The first one is the one I'd probably use on the theory that one gets
familiar with the quirks of a particular class and it's easier to
clean up the resource leak warnings for that class than all the
warnings that might be in a file. But that's a personal preference.


On Tue, Jul 4, 2017 at 3:47 AM, Christine Poerschke (BLOOMBERG/
LONDON) <> wrote:
> Hi Everyone,
> The following list is the latest Q2 2017 portion of the dated-warnings.log file I've
attached to and it was generated by the also
attached shell script that correlates warnings with git commit history.
> Any help to investigate and take care of these warnings would be appreciated. The short
term goal is to not increase the number of warnings we have and in the medium to long term
the goal would be to fail precommit if any warnings are detected.
> Christine
> PS: @SuppressWarnings("resource") can be used to suppress inappropriate warnings and
Erick Erickson is already looking into warnings related to JavaBinCodec.
> -----------------------------------------
>  ant precommit warnings dated to Q2 2017
> -----------------------------------------
> 2017-06-21
> 2017-06-21
> 2017-06-21
> 2017-06-16
> 2017-06-16
> 2017-06-16
> 2017-05-30
> 2017-05-16
> 2017-04-12
> 2017-04-11

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message