[ https://issues.apache.org/jira/browse/SOLR-15244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311585#comment-17311585 ]
Mike Drob commented on SOLR-15244: ---------------------------------- There were actually two different issues here - 1) The behavior of {{Path.resolve}} and {{new File(File, String)}} for getting a child is different when the child path starts with a slash. Compare: {code} jshell> new File(new File("foo"), "/bar") $3 ==> foo/bar jshell> Path.of("foo").resolve("/bar") $4 ==> /bar {code} 2) When we were using our own streams to write byte buffers to files, we would use the array directly instead of reading from the buffer. We would reuse the contents of the buffer several times to do this, and it worked fine because we explicitly set the bounds. However, when we switch to using nio and passing the byte buffer to the library calls, it would correctly be using the position/limit of the buffer - which had already been read. These were hard to find until I realized that {{cf83...}} was the sha512 sum of empty string. From there, it was easy to switch to either using the bytes directly or doing mark/reset, which is efficient on an array-backed buffer. > Use NIO methods instead of IO when interacting with Lucene Directory > -------------------------------------------------------------------- > > Key: SOLR-15244 > URL: https://issues.apache.org/jira/browse/SOLR-15244 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Mike Drob > Assignee: Mike Drob > Priority: Major > Fix For: main (9.0) > > Time Spent: 50m > Remaining Estimate: 0h > > We have a lot of places where we are still using IO methods and File objects, > and then doing conversions to Path for accessing Lucene Directory. We also > have places where we are doing a bunch of conversions from Path to String and > back to Path through SolrResourceLoader. > Do a sweep of these and update at least the easy ones. There are a few places > where File APIs might still make more sense or be too burdensome to convert, > can leave those for another day. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org