Skip to content

Conversation

magibney
Copy link
Contributor

See: SOLR-16628

Comment on lines 396 to 398
InputStream in = null;
try {
ResourceProvider rp = new ResourceProvider(loader, name);
in = loader.openResource(name);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use try-with-resources pattern here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we cannot, unfortunately; because in most cases the InputStream should have been closed properly by the parser before reaching our finally block, so we're really relying on the "exception-swallowing" quality of IOUtils.closeQuietly().

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if we need that. I was able to apply your change here to 9.1 in my reproducing setup. Your change, as well as a tweak to use the simpler try-with-resources both yielded working test runs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think IndexSchemaFactory#loadConfig has the same pattern here? at least using loader.openResource(name) without closing it?

https://github.com/apache/solr/pull/987/files#diff-5965edf45e1dec49fea047168b81ddffbb530f5db8875b41627950773d63b3a6R138

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went ahead and used try-with-resources (b648786) where possible (it's not possible in contexts where the InputStream is opened in less straightforward ways).

@risdenk in cd4923f I also addressed the case you identified in IndexSchemaFactory, and followed up the stack trace to address a similar issue in ManagedIndexSchemaFactory.

As a consequence of the ManagedIndexSchemaFactory change, this PR's a bit easier to review ignoring whitespace: https://github.com/apache/solr/pull/1302/files?w=1

@dsmiley
Copy link
Contributor

dsmiley commented Jan 19, 2023

I found a reproducible line on branch_9_1 using JDK 11 on my aging laptop.

gradlew -p solr/core test -Ptests.iters=10 --tests TestCoreContainer

Applying the changes here made this pass! Also with simpler try-with-resources pattern in one file.
Thanks again.

@magibney
Copy link
Contributor Author

I tried reproducing this by stressing my system, but haven't been able to, FYI.

Separately, is the value/risk ratio of this change enough to warrant inclusion in an RC3 for 9.1.1?

@dsmiley
Copy link
Contributor

dsmiley commented Jan 19, 2023

RE 9.1.1 eh... I wouldn't bother, personally. Let's see if a more serious concern is brought up.

@magibney
Copy link
Contributor Author

RE 9.1.1 eh... I wouldn't bother, personally. Let's see if a more serious concern is brought up.

This makes sense to me. I suspect this has been a (mostly) latent issue for a while now. SOLR-15337 may have made it more apparent in some ways, but I think this type of issue existed, even in this part of the codebase, even before that.

@magibney
Copy link
Contributor Author

Ok, so targeting 9.2 release. Does this warrant a CHANGES.txt entry? I'm thinking "no" ... nobody has actually reported this being a problem in the wild, afaik?

@dsmiley
Copy link
Contributor

dsmiley commented Jan 19, 2023

CHANGES.txt -- I recommend adding an entry. It is a bug, albeit minor.
I recommend waiting until after 9.1.1 vote passes before merging or adding CHANGES.txt. There is a chance we'll pull it into 9.1.1 even though at this moment we think not.

@magibney
Copy link
Contributor Author

With 9.1.1 released, added a CHANGES.txt entry for 9.2.0 release. Pending any feedback, I plan to merge this tomorrow.


implementation 'commons-cli:commons-cli'

implementation 'net.jcip:jcip-annotations'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So maybe @dsmiley knows which jcip-annotations is correct.

At least based on https://github.com/stephenc/jcip-annotations - it should be https://mvnrepository.com/artifact/com.github.stephenc.jcip/jcip-annotations/1.0-1

however it looks like we include net.jcip:jcip-annotations already somehow?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These two JARs are equivalent but have different licenses. We should prefer stephenc as it's ASL licensed; a clean-room written implementation. The net.jcip https://jcip.net/annotations/doc/index.html is using Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.5) which the ASF is okay with in binary form https://www.apache.org/legal/resolved.html#cc-by but lets prefer the ASL one as we have a choice.

I removed net.jcip in #1313 this weekend; pending merge.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@magibney lets remove the use of such annotations in this PR. In #1313 I added it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 thanks for catching this, and for the work on #1313. I'll wait til after that's merged to merge this.

@risdenk
Copy link
Contributor

risdenk commented Feb 6, 2023

@magibney #1313 was merged so this should be good to go resolving any conflicts :D


int schemaZkVersion = -1;
if (!(loader instanceof ZkSolrResourceLoader)) {
Entry<String, InputStream> localSchemaInput = readSchemaLocally();
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

5% of developers fix this issue

THREAD_SAFETY_VIOLATION: Unprotected write. Non-private method ManagedIndexSchemaFactory.create(...) indirectly writes to field this.managedSchemaResourceName outside of synchronization.
Reporting because this access may occur on a background thread.


ℹ️ Expand to see all @sonatype-lift commands

You can reply with the following commands. For example, reply with @sonatype-lift ignoreall to leave out all findings.

Command Usage
@sonatype-lift ignore Leave out the above finding from this PR
@sonatype-lift ignoreall Leave out all the existing findings from this PR
@sonatype-lift exclude <file|issue|path|tool> Exclude specified file|issue|path|tool from Lift findings by updating your config.toml file

Note: When talking to LiftBot, you need to refresh the page to see its response.
Click here to add LiftBot to another repo.


Help us improve LIFT! (Sonatype LiftBot external survey)

Was this a good recommendation for you? Answering this survey will not impact your Lift settings.

[ 🙁 Not relevant ] - [ 😕 Won't fix ] - [ 😑 Not critical, will fix ] - [ 🙂 Critical, will fix ] - [ 😊 Critical, fixing now ]

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It sucks to still see this because we have a NotThreadSafe annotation, thus I wasn't anticipating the checks. From reading the Infer/RacerD docs in more detail, it appears this is because this class, despite not being ThreadSafe, and advertising itself as such nonetheless contains the "synchronized" keyword in one spot at the end of create(). The presence of the keyword in the code takes precedence over NotThreadSafe annotation. It seems to me we don't need that synchronized there because the schema is not published yet. Any way, such changes / explorations don't belong here. I'll create a PR to toy with this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, ok, that makes sense! Thanks for following up on this. I expect to merge/backport tomorrow.

@magibney magibney merged commit e20fcf8 into apache:main Feb 9, 2023
magibney added a commit that referenced this pull request Feb 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants