Lucene store type jdbc disabled in Liferay 6.1

[Ben Longi, modificado hace 11 años.]

Hello,

I'm trying to store my luncene index on datbase as described in the 6.1 documentation:
http://www.liferay.com/documentation/liferay-portal/6.1/user-guide/-/ai/liferay-clusteri-2

It says:
There is a single property called lucene.store.type. By default this is set to go to the file system. You can change this so that the index is stored in the database by making it the following:
lucene.store.type=jdbc

But when I'm testing this on my portal I got this error:

[12-06-12 13:34:40:246 EDT] 0000006a SystemOut O 13:34:40,245 ERROR [render_portlet_jsp:154] com.liferay.portal.kernel.search.SearchException: java.lang.IllegalArgumentException: Store type JDBC is no longer supported in favor of SOLR
at com.liferay.portal.search.lucene.LuceneIndexSearcherImpl.search(LuceneIndexSearcherImpl.java:402)
at com.liferay.portal.kernel.util.MethodHandler.invoke(MethodHandler.java:83)
at com.liferay.portal.kernel.messaging.proxy.ProxyRequest.execute(ProxyRequest.java:57)
at com.liferay.portal.kernel.messaging.proxy.ProxyMessageListener.receive(ProxyMessageListener.java:50)
at com.liferay.portal.kernel.messaging.InvokerMessageListener.receive(InvokerMessageListener.java:63)
at com.liferay.portal.kernel.messaging.SynchronousDestination.send(SynchronousDestination.java:39)
at com.liferay.portal.kernel.messaging.sender.DirectSynchronousMessageSender.send(DirectSynchronousMessageSender.java:60)
at com.liferay.portal.messaging.proxy.MultiDestinationMessagingProxyAdvice.doInvokeSynchronous(MultiDestinationMessagingProxyAdvice.java:113)
at com.liferay.portal.messaging.proxy.MultiDestinationMessagingProxyAdvice.invoke(MultiDestinationMessagingProxyAdvice.java:60)
at com.liferay.portal.kernel.search.SearchEngineUtil.search(SearchEngineUtil.java:349)
at com.liferay.portal.kernel.search.SearchEngineUtil.search(SearchEngineUtil.java:304)
at com.liferay.portlet.messageboards.util.MBIndexer.doDelete(MBIndexer.java:204)
at com.liferay.portal.kernel.search.BaseIndexer.delete(BaseIndexer.java:98)
at com.liferay.portlet.messageboards.service.impl.MBThreadLocalServiceImpl.deleteThread(MBThreadLocalServiceImpl.java:131)
at com.liferay.portlet.messageboards.service.impl.MBThreadLocalServiceImpl.deleteThread(MBThreadLocalServiceImpl.java:118)
at com.liferay.portal.spring.aop.ServiceBeanMethodInvocation.proceed(ServiceBeanMethodInvocation.java:112)
at com.liferay.portal.spring.transaction.TransactionInterceptor.invoke(TransactionInterceptor.java:71)
at com.liferay.portal.spring.aop.ServiceBeanMethodInvocation.proceed(ServiceBeanMethodInvocation.java:108)
at com.liferay.portal.spring.aop.ServiceBeanAopProxy.invoke(ServiceBeanAopProxy.java:211)
at com.liferay.portlet.messageboards.service.impl.MBMessageLocalServiceImpl.deleteDiscussionMessages(MBMessageLocalServiceImpl.java:497)
Caused by: java.lang.IllegalArgumentException: Store type JDBC is no longer supported in favor of SOLR
at com.liferay.portal.search.lucene.IndexAccessorImpl.getLuceneDir(IndexAccessorImpl.java:139)
at com.liferay.portal.search.lucene.LuceneHelperImpl.getSearcher(LuceneHelperImpl.java:391)
at com.liferay.portal.search.lucene.LuceneHelperUtil.getSearcher(LuceneHelperUtil.java:333)
at com.liferay.portal.search.lucene.LuceneIndexSearcherImpl.search(LuceneIndexSearcherImpl.jav

As I can see on the source code It seems that jdbc store for lucene has been deleted:
http://www.emforge.net/web/liferay/sources;jsessionid=4F6083AC9D19D96079CC5278928974D3?p_p_id=scmportlet_WAR_emforgeportlet&p_p_lifecycle=0&p_p_state=normal&_scmportlet_WAR_emforgeportlet_path=portal%2Ftrunk%2Fportal-impl%2Fsrc%2Fcom%2Fliferay%2Fportal%2Fsearch%2Flucene%2FIndexAccessorImpl.java&_scmportlet_WAR_emforgeportlet_version=

Do you have information about that ? How features could be deleted without any notice to customers ? Moreover source code and documentation is not synchronized.
I'm using Liferay 6.1 Entreprise Edition.

Regards

[Hitoshi Ozawa, modificado hace 11 años.]

There's an error in the documentation. Liferay no longer supports lucene indexes in jdbc.

Since you're EE customer, why don't you create a ticket to claim that you need the functionality as described in the documentation.

[Ben Longi, modificado hace 11 años.]

Hello.
I'm going to create a ticket I just wanted to be sure that the feature has been removed.
How is it possible that such features can be removed between 2 Liferay version ?
Thanks.

[Mika Koivisto, modificado hace 11 años.]

The jdbc lucene store won't work with LR 6.1+ because the library that enables that is not compatible with the version of Lucene we are using and the project is no longer maintained so there will not be even any further releases that would be compatible with new Lucene versions. There was a disconnect between documentation and engineering so it's incorrectly documented.

[Ben Longi, modificado hace 11 años.]

OK I understand. Thank you for the explanation.
So we will need to find another way to manage Lucene in cluster. We don't want to settle a SOLR server (don't need this) and index synchronisation with multicast is not possible. I guess we will try to use a shared filesystem between cluster node. Is it possible to use a shared filesystem with Liferay ?

[Mika Koivisto, modificado hace 11 años.]

You can't share lucene indexes with another server by making them available through shared filesystem as the first node that opens it will lock it. You could make the other nodes read only but then any writes on those would be ignored and lost. You could replicate the index writes to all nodes via clusterlink but then if a node goes down it has to reindex everything to catch up with the others. Maybe you could do some combination of using one node for writes and then replicate the writes via clusterlink and share the indexes to other nodes via shared filesystem but when you try to setup something that complicated it's better to just use Solr in the first place.

[Hitoshi Ozawa, modificado hace 11 años.]

Following up of Mika, I tried several other indexing options on clustered liferay system and finally ended up using Solr.
The only other reliable option was to virtualize http+liferay+database setup with data being written to other drive.
On a failure, I just setup a vm to do a complete switch over to a new vm setup on failure.

I found that Solr has an advantage because I'm now able to do better searches in more Google-like fashion. :-)