Uploaded image for project: 'Infinispan'
  1. Infinispan
  2. ISPN-4139

Upgrade Lucene 4 Infinispan Directory to Lucene 4.7.0

This issue belongs to an archived project. You can view it, but you can't modify it. Learn more

    • Icon: Task Task
    • Resolution: Done
    • Icon: Blocker Blocker
    • 7.0.0.Alpha2
    • None
    • Lucene Directory
    • None

      • DirectoryLuceneV4 should not probably extend BaseDirectory instead of plain Directory
      • Lock#release got removed into Lock#close. BaseLuceneLock needs to change, but I am not sure how this works in order to support Lucene 3 and 4!?

            [ISPN-4139] Upgrade Lucene 4 Infinispan Directory to Lucene 4.7.0

            Infinispan Query uses Hibernate Search, currently still using 4.5.0. So there are tests in this tree which use Hibernate Search 4.5 in combination with the Lucene Directory too, run with Lucene 3.6.2

            Would it not help to extract these Lucene sub modules from the main Infinispan tree? Not only is there an nasty interdependency, but you also need a full Infinispan release in order to get out a new version of the Infinispan Directory (which is required by Search). Why not move Infinispan Directory in its own repo or Hibernate Search?

            If you have a plan to fix this issue I'm happy to reassign to you as I've been busy with debugging other Search issues,

            Ok. Right now, I have also other things I want to finish first. Let's see who gets to it first. We just need to make sure t sync in case either one of us starts working on this.

            but be aware of the intricate compatibility requirements.

            Hardy Ferentschik (Inactive) added a comment - Infinispan Query uses Hibernate Search, currently still using 4.5.0. So there are tests in this tree which use Hibernate Search 4.5 in combination with the Lucene Directory too, run with Lucene 3.6.2 Would it not help to extract these Lucene sub modules from the main Infinispan tree? Not only is there an nasty interdependency, but you also need a full Infinispan release in order to get out a new version of the Infinispan Directory (which is required by Search). Why not move Infinispan Directory in its own repo or Hibernate Search? If you have a plan to fix this issue I'm happy to reassign to you as I've been busy with debugging other Search issues, Ok. Right now, I have also other things I want to finish first. Let's see who gets to it first. We just need to make sure t sync in case either one of us starts working on this. but be aware of the intricate compatibility requirements.

            How is this even related?

            Infinispan Query uses Hibernate Search, currently still using 4.5.0. So there are tests in this tree which use Hibernate Search 4.5 in combination with the Lucene Directory too, run with Lucene 3.6.2

            We need to solve our integration issues in Hibernate Search to replace the one used by Infinispan Query so that I can drop the need to have the Lucene Directory to support both old and new Lucene versions. Current roadblock is the serialization, and as you know we might introduce more roadbocks while making more changes in Search 5.. which is why it's good to keep an eye on both projects as we need to converge quickly.

            If you have a plan to fix this issue I'm happy to reassign to you as I've been busy with debugging other Search issues, but be aware of the intricate compatibility requirements. If you can avoid any SPI changes it would be best; otherwise I think we'd be better off postponing this upgrade after we dropped Lucene 3.6, and postponed the update in Search too.

            Sanne Grinovero (Inactive) added a comment - How is this even related? Infinispan Query uses Hibernate Search, currently still using 4.5.0. So there are tests in this tree which use Hibernate Search 4.5 in combination with the Lucene Directory too, run with Lucene 3.6.2 We need to solve our integration issues in Hibernate Search to replace the one used by Infinispan Query so that I can drop the need to have the Lucene Directory to support both old and new Lucene versions. Current roadblock is the serialization, and as you know we might introduce more roadbocks while making more changes in Search 5.. which is why it's good to keep an eye on both projects as we need to converge quickly. If you have a plan to fix this issue I'm happy to reassign to you as I've been busy with debugging other Search issues, but be aware of the intricate compatibility requirements. If you can avoid any SPI changes it would be best; otherwise I think we'd be better off postponing this upgrade after we dropped Lucene 3.6, and postponed the update in Search too.

            Lol, that's the reason for me to work on including Search 5 in Infinispan asap: to get rid of that (remove the Lucene3 support)

            How is this even related?

            Hardy Ferentschik (Inactive) added a comment - Lol, that's the reason for me to work on including Search 5 in Infinispan asap: to get rid of that (remove the Lucene3 support) How is this even related?

            Is this preventing you to upgrade Search to Lucene 4.7?

            That's the missing piece. Everything else works, just have tests failures in the infinispan module. Here is an example:

            Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.228 sec <<< FAILURE! - in org.hibernate.search.infinispan.sharedIndex.SharedIndexTest
            testSingleResultFromDeviceIndex(org.hibernate.search.infinispan.sharedIndex.SharedIndexTest)  Time elapsed: 0.228 sec  <<< ERROR!
            java.lang.AbstractMethodError: org.apache.lucene.store.Lock.close()V
            	at org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1052)
            	at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:927)
            	at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:889)
            	at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:159)
            	at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:109)
            	at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:104)
            	at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:272)
            	at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:561)
            	at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManagers(IndexManagerHolder.java:530)
            	at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:107)
            	at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:386)
            	at org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:225)
            	at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:143)
            	at org.hibernate.search.hcore.impl.HibernateSearchSessionFactoryObserver.sessionFactoryCreated(HibernateSearchSessionFactoryObserver.java:79)
            	at org.hibernate.internal.SessionFactoryObserverChain.sessionFactoryCreated(SessionFactoryObserverChain.java:52)
            	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:588)
            	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1857)
            	at org.hibernate.search.test.util.FullTextSessionBuilder.build(FullTextSessionBuilder.java:181)
            	at org.hibernate.search.infinispan.ClusterTestHelper.createClusterNode(ClusterTestHelper.java:97)
            	at org.hibernate.search.infinispan.ClusterTestHelper.createClusterNode(ClusterTestHelper.java:61)
            	at org.hibernate.search.infinispan.sharedIndex.SharedIndexTest.setUp(SharedIndexTest.java:100)
            

            I can take care of this, it's quite a minefield of backwards compatibility requirements.

            If you want. I finally have Infinispan configured in my IDE though and I kind of see what I need to do. I guess I would need something similar to DirectoryBuilderImpl#create in BaseLockFactory (or somewhere in this care). Depending on the Lucene version I need to return an appropriate instance of Lock.

            I actually tried to implement #release() and #lock at the same time in BaseLuceneLock, but that did not work The class is still not compatible then when run with Lucene 4.7.

            Just let me know if you fix this, then I leave it for now.

            BTW If you can't upgrade Search to 4.7 without an Infinispan release first, it's getting messy. We would need an Infinispan release, and the Infinispan patch would need to support both Lucene 3, and Lucene 4.6 and Lucene 4.7 (both!).

            I can upgrade, but the Infinispan DirectoryProvider would be broken until a new updated Infinspan release is available. Probably not so nice. Why would you need to support 3, 4.6 and 4.7. That sounds terrible (and is btw not what I have been working on the last couple of hours)?

            Hardy Ferentschik (Inactive) added a comment - - edited Is this preventing you to upgrade Search to Lucene 4.7? That's the missing piece. Everything else works, just have tests failures in the infinispan module. Here is an example: Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.228 sec <<< FAILURE! - in org.hibernate.search.infinispan.sharedIndex.SharedIndexTest testSingleResultFromDeviceIndex(org.hibernate.search.infinispan.sharedIndex.SharedIndexTest) Time elapsed: 0.228 sec <<< ERROR! java.lang.AbstractMethodError: org.apache.lucene.store.Lock.close()V at org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1052) at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:927) at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:889) at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:159) at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:109) at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:104) at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:272) at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:561) at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManagers(IndexManagerHolder.java:530) at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:107) at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:386) at org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:225) at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:143) at org.hibernate.search.hcore.impl.HibernateSearchSessionFactoryObserver.sessionFactoryCreated(HibernateSearchSessionFactoryObserver.java:79) at org.hibernate.internal.SessionFactoryObserverChain.sessionFactoryCreated(SessionFactoryObserverChain.java:52) at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:588) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1857) at org.hibernate.search.test.util.FullTextSessionBuilder.build(FullTextSessionBuilder.java:181) at org.hibernate.search.infinispan.ClusterTestHelper.createClusterNode(ClusterTestHelper.java:97) at org.hibernate.search.infinispan.ClusterTestHelper.createClusterNode(ClusterTestHelper.java:61) at org.hibernate.search.infinispan.sharedIndex.SharedIndexTest.setUp(SharedIndexTest.java:100) I can take care of this, it's quite a minefield of backwards compatibility requirements. If you want. I finally have Infinispan configured in my IDE though and I kind of see what I need to do. I guess I would need something similar to DirectoryBuilderImpl#create in BaseLockFactory (or somewhere in this care). Depending on the Lucene version I need to return an appropriate instance of Lock . I actually tried to implement #release() and #lock at the same time in BaseLuceneLock , but that did not work The class is still not compatible then when run with Lucene 4.7. Just let me know if you fix this, then I leave it for now. BTW If you can't upgrade Search to 4.7 without an Infinispan release first, it's getting messy. We would need an Infinispan release, and the Infinispan patch would need to support both Lucene 3, and Lucene 4.6 and Lucene 4.7 (both!). I can upgrade, but the Infinispan DirectoryProvider would be broken until a new updated Infinspan release is available. Probably not so nice. Why would you need to support 3, 4.6 and 4.7. That sounds terrible (and is btw not what I have been working on the last couple of hours)?

            BTW If you can't upgrade Search to 4.7 without an Infinispan release first, it's getting messy. We would need an Infinispan release, and the Infinispan patch would need to support both Lucene 3, and Lucene 4.6 and Lucene 4.7 (both!).

            Sanne Grinovero (Inactive) added a comment - BTW If you can't upgrade Search to 4.7 without an Infinispan release first, it's getting messy. We would need an Infinispan release, and the Infinispan patch would need to support both Lucene 3, and Lucene 4.6 and Lucene 4.7 (both!).

            Is this preventing you to upgrade Search to Lucene 4.7?

            Might be able to create pull request, once I understand the whole Lucene 3 + 4 support thing ...

            Lol, that's the reason for me to work on including Search 5 in Infinispan asap: to get rid of that (remove the Lucene3 support)

            I can take care of this, it's quite a minefield of backwards compatibility requirements.

            Sanne Grinovero (Inactive) added a comment - Is this preventing you to upgrade Search to Lucene 4.7? Might be able to create pull request, once I understand the whole Lucene 3 + 4 support thing ... Lol, that's the reason for me to work on including Search 5 in Infinispan asap: to get rid of that (remove the Lucene3 support) I can take care of this, it's quite a minefield of backwards compatibility requirements.

            Might be able to create pull request, once I understand the whole Lucene 3 + 4 support thing ...

            Hardy Ferentschik (Inactive) added a comment - Might be able to create pull request, once I understand the whole Lucene 3 + 4 support thing ...

              sgrinove Sanne Grinovero (Inactive)
              hardy.ferentschik_jira Hardy Ferentschik (Inactive)
              Archiver:
              rhn-support-adongare Amol Dongare

                Created:
                Updated:
                Resolved:
                Archived: