-
Notifications
You must be signed in to change notification settings - Fork 768
SOLR-16628: Ensure that InputStreams are closed after Xml parsing #1302
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
InputStream in = null; | ||
try { | ||
ResourceProvider rp = new ResourceProvider(loader, name); | ||
in = loader.openResource(name); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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()
.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
I found a reproducible line on branch_9_1 using JDK 11 on my aging laptop.
Applying the changes here made this pass! Also with simpler try-with-resources pattern in one file. |
solr/core/src/java/org/apache/solr/schema/ManagedIndexSchemaFactory.java
Show resolved
Hide resolved
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? |
RE 9.1.1 eh... I wouldn't bother, personally. Let's see if a more serious concern is brought up. |
solr/core/src/java/org/apache/solr/schema/ManagedIndexSchemaFactory.java
Show resolved
Hide resolved
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. |
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? |
solr/core/src/java/org/apache/solr/schema/ManagedIndexSchemaFactory.java
Outdated
Show resolved
Hide resolved
CHANGES.txt -- I recommend adding an entry. It is a bug, albeit minor. |
solr/core/src/java/org/apache/solr/schema/ManagedIndexSchemaFactory.java
Show resolved
Hide resolved
With 9.1.1 released, added a CHANGES.txt entry for 9.2.0 release. Pending any feedback, I plan to merge this tomorrow. |
solr/core/src/java/org/apache/solr/schema/ManagedIndexSchemaFactory.java
Outdated
Show resolved
Hide resolved
solr/core/build.gradle
Outdated
|
||
implementation 'commons-cli:commons-cli' | ||
|
||
implementation 'net.jcip:jcip-annotations' |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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.
|
||
int schemaZkVersion = -1; | ||
if (!(loader instanceof ZkSolrResourceLoader)) { | ||
Entry<String, InputStream> localSchemaInput = readSchemaLocally(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 ]
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
) (cherry picked from commit e20fcf8)
See: SOLR-16628