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)