You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ofbiz.apache.org by "Jacques Le Roux (Jira)" <ji...@apache.org> on 2022/06/25 16:03:00 UTC

[jira] [Commented] (OFBIZ-12645) Update Solr to 9.0.0 and try the same for Lucene

    [ https://issues.apache.org/jira/browse/OFBIZ-12645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17558794#comment-17558794 ] 

Jacques Le Roux commented on OFBIZ-12645:
-----------------------------------------

I did not think that this would have been so much work, actually researches, days... Anyway long story short here is an abstract.

Part of the difficulties I crossed was due to the fact that we did not really follow much Solr/Lucene upgrades since it was integrated in OFBiz. And with 9.0.0 Solr has removed a lot of deprecated stuff. Also the Solr/Lucene documentation is huge and not always easy to understand. Especially if you use Google rather than the internal Solr documentation. Google returns a lot of deprecated Solr documentation pages and some are red herrings, better refer to "latest" page. Also, maybe it's me. I tried a lot of things that I finally gave up, external logging was one of them..

The 1st issue I crossed was that getting to the Solr page in OFBIz was impossible. Because there are 2 CountDownLatch/es in Solr. And 1 of them is blocking you if you simply create a core, load it and init OFBizSolrContextFilter through SolrDispatchFilter as we did before. One is in CoreContainerProvider class (name: init) and one in CoreContainerProvider static nested class ContextInitializationKey (name: initializing). Both are initialised to 1 (ie set to wait) and need to be "count[ed]Down" for SolrDispatchFilter::init to start. I'm unsure I followed the best way. At least it worked.


So I decide to use:
{code:java}
        CoreContainerProvider coreContainerProvider = new CoreContainerProvider();
        coreContainerProvider.init(servletContext);
{code}

But in this case I got a lock issue that could only be only always resolved using {{<lockType>single</lockType>}}* in solrconfig.xml. I'm not sure it's safe. In few cases I was able to make it work using {{<lockType>${solr.lock.type:native}</lockType>}} by increasing writeLockTimeout in solrconfig.xml but that's not reliable.

\* see descriptions in
* https://cwiki.apache.org/confluence/display/lucene/AvailableLockFactories
* https://lucene.apache.org/core/9_0_0/core/org/apache/lucene/store/SingleInstanceLockFactory.html
* https://solr.apache.org/guide/solr/latest/configuration-guide/index-segments-merging.html#index-locks

I even tried
{code:java}
    try { // Use reflection to be able to use the makeReady inner private method
            Class<?> ContextInitializationKey = Class.forName("org.apache.solr.servlet.CoreContainerProvider$ContextInitializationKey");
            Constructor<?> contextInitializationConstructor = ContextInitializationKey.getDeclaredConstructors()[0];
            contextInitializationConstructor.setAccessible(true);
            Object contextInitializationKey = contextInitializationConstructor.newInstance(servletContext);
            Method makeReady = ContextInitializationKey.getDeclaredMethod("makeReady");
            makeReady.setAccessible(true);
            makeReady.invoke(contextInitializationKey, new Object[] {});
        } catch (ClassNotFoundException |NoSuchMethodException | InvocationTargetException |  IllegalAccessException | InstantiationException | IllegalArgumentException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
{code}
hoping invoking ContextInitializationKey::makeReady would be enough, but CoreContainerProvider::init is mandatory.

BTW, I don't think it's related, but I noted several "THREAD_SAFETY_VIOLATION" from  sonatype-lift bot at https://github.com/apache/solr/pull/265#discussion_r739890201 with code still in 9.0.0.

I also upgraded several config files: solr.xml, schema.xml, solrconfig.xml (a lot) and core.properties after it was changed by Solr itself.

I guess since Solr and Lucene are now 2 separated projects, in DocumentIndexer and LuceneTests it's no longer necessary to call {{analyzer.setVersion(SearchWorker.getLuceneVersion());}}. Actually it's now impossible: compilation error.

To able tests to pass I followed https://lists.apache.org/thread/vot5cz98jll8bhc1hmlss8tgcqnmfzco. These are new features so should be OK.

So it works but I'm unsure of the situation. So I suggest for now to continue to use the 8 branch.

Here is the patch for the 9 branch: [^OFBIZ-12645.patch] 

> Update Solr to 9.0.0 and try the same for Lucene
> ------------------------------------------------
>
>                 Key: OFBIZ-12645
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-12645
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: lucene, solr
>    Affects Versions: Upcoming Branch
>            Reporter: Jacques Le Roux
>            Assignee: Jacques Le Roux
>            Priority: Minor
>         Attachments: OFBIZ-12645.patch
>
>
> Solr and Lucene are now separated projects. That complicated things a bit to update them in sync. This is a tentative to do so.
> https://solr.apache.org/guide/solr/latest/upgrade-notes/major-changes-in-solr-9.html
> https://solr.apache.org/docs/9_0_0/changes/Changes.html#v9.0.0
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.7#820007)