lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From NightOwl888 <...@git.apache.org>
Subject [GitHub] lucenenet issue #208: LUCENE-5644: switch to simpler LIFO thread to ThreadSt...
Date Tue, 13 Jun 2017 12:54:26 GMT
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.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message