[
https://issues.apache.org/jira/browse/LUCENE-5644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16047842#comment-16047842
]
ASF GitHub Bot commented on LUCENE-5644:
----------------------------------------
Github user NightOwl888 commented on the issue:
https://github.com/apache/lucenenet/pull/208
> Second, assuming we have no threading issues at the moment, how can we be
sure this doesn't introduce any? cc @NightOwl888
@synhershko
First of all, we still have some threading issues. The
[Lucene.Net.Store.TestLockFactory.TestStressLocksNativeFSLockFactory
test](https://teamcity.jetbrains.com/viewLog.html?buildId=1084071&tab=buildResultsDiv&buildTypeId=LuceneNet_PortableBuilds_TestOnNet451)
and [Lucene.Net.Store.TestLockFactory.TestStressLocks
test](https://teamcity.jetbrains.com/viewLog.html?buildId=1071425&tab=buildResultsDiv&buildTypeId=LuceneNet_PortableBuilds_TestOnNet451)
still fail randomly, and there may be others (last I checked there were 2
tests that failed *only* when the MMapDirectory was randomly selected).
Secondly, this change is part of the Lucene 4.8.1 patch. Much of this port
(including most or all of Analysis.Common) is from 4.8.1 already, so we should
probably try to include the rest of the fixes to get us all the way to 4.8.1,
especially if they have performance benefits.
@vvdb
If we are going to work toward 4.8.1 on a gradual basis, we should probably
include a comment at the top of each changed file indicating the version
compatibility level so we don't have to check the entire file to see if it is
up to speed.
```
// Version compatibility level: 4.8.1
```
As for getting all the way there, I have outlined a procedure
[here](https://github.com/apache/lucenenet/pull/174#issuecomment-251614795) for
upgrading Lucene.Net to 4.8.1, which should be a lot quicker and easier than
porting it from scratch again. Of course, it requires you to have a text
comparison tool that allows you to filter out "unimportant changes" such as
Beyond Compare. This will ensure we get all of the changes between the old file
and new file and port them into the .NET file.
It would be better to have a tool that allows you to ignore simple code
formatting changes (such as changing the curly bracket from the same line to
the following line of a function or if statement), but to my knowledge a tool
like that doesn't exist.
> ThreadAffinityDocumentsWriterThreadPool should clear the bindings on flush
> --------------------------------------------------------------------------
>
> Key: LUCENE-5644
> URL: https://issues.apache.org/jira/browse/LUCENE-5644
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/index
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 4.8.1, 4.9, 6.0
>
> Attachments: LUCENE-5644.patch, LUCENE-5644.patch, LUCENE-5644.patch,
> LUCENE-5644.patch, LUCENE-5644.patch
>
>
> This class remembers which thread used which DWPT, but it never clears
> this "affinity". It really should clear it on flush, this way if the
> number of threads doing indexing has changed we only use as many DWPTs
> as there are incoming threads.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
