After 2 days I have figured out how to open Solr 4 in IntelliJ IDEA 11.1.4 on
Tomcat 7. IntelliJ IDEA finds webapp/web/WEB-INF/web.xml and offers to make
a facet from it and adds this facet to the "parent" module, from which an
artifact can be created.
The problem is that Solr cannot run properly.
I have followed this instruction:
http://wiki.apache.org/lucene-java/HowtoConfigureIntelliJ
1. Downloaded lucene_solr_4_0 branch
2. ant idea
3. opened this project in IDEA
4. clicked Build/Make project menu
I got message: Compilation completed with 111 errors and 9 warnings
C:\solr\lucene\benchma
InelliJ IDEA is not so intelligent with Solr: to fix this problem I've
dragged these modules into the IDEA's artifact (parent module is wrong):
analysis-common
analysis-extras
analysis-uima
clustering
codecs
codecs-resources
dataimporthandler
dataimporthandler-extras
lucene-core
lucene-core-resour
owe [via Lucene]"
:
>
>
>
>
>
Hi Artyom,
>
>I don't use IntelliJ artifacts - I just edit/compile/test.
>
>I can include this stuff in the IntelliJ configuration if you'll help me. Can
&g
code, you have
>to do another "ant example" but if your goal is to simply step through Solr
>code, it's much easier to do a remote debugging session.
>
>Best
>Erick
>
>
>On Wed, Dec 5, 2012 at 11:55 PM, Artyom <[hidden email]> wrote:
>
>
>>
When an optimization event occurs in this case? Should I reindex this
spellchecker on every shard manually? Or does this even occurs every hard or
soft commit?
--
View this message in context:
http://lucene.472066.n3.nabble.com/SolrCloud-with-Near-Realtime-Search-buildOnOptimize-in-IndexBasedSp
Thank you, Tomás.
This wiki
http://wiki.apache.org/solr/UpdateXmlMessages#A.22commit.22_and_.22optimize.22
says
"*Segments are normally merged over time anyway (as determined by the merge
policy), and optimize just forces these merges to occur immediately.*"
Doesn't the merge policy affects buil
Thank you, Upayavira, I know about the DirectSpellChecker.
But I want to know how IndexBasedSpellChecker is handled in SolrCloud.
--
View this message in context:
http://lucene.472066.n3.nabble.com/SolrCloud-with-Near-Realtime-Search-buildOnOptimize-in-IndexBasedSpellChecker-tp4027499p4027514.h
I guess, response time increased, because I use master-slave configuration in
Solr 4.0 and Solr 4.1: if there are no termVectors, the full index is
replicated; if there are termVectors, only modified segments of the index
are transferred from the master to slaves. Am I right?
--
View this messag
you should check not suggestions, but collations in the response xml
--
View this message in context:
http://lucene.472066.n3.nabble.com/Issue-with-spellcheck-and-autosuggest-tp4036208p4036977.html
Sent from the Solr - User mailing list archive at Nabble.com.
I tried Solr 4.1, reindexed data using DIH (full-import) and compared
response time with version 4.0. Response time increased 1.5-2 times. How to
disable compression on stored fields in Solr 4.1? I tried to change codec
version in solrconfig:
LUCENE_40
and reindexed data using DIH (full-import)
I guess, I have to "write a new codec that uses a stored fields format which
does not compress stored fields such as Lucene40StoredFieldsFormat"
http://blog.jpountz.net/post/35667727458/stored-fields-compression-in-lucene-4-1
What is the purpose of tag then, does it affect
anything at all or LUCE
Yes, I guess, full index replication is a general bug of 4.x. I tried the
same routine with termVectors and got the same result:
1. stopped all Solr instances
2. cleared data folders of all instances
3. ran master, made full-import with optimize option using DIH
4. after import ran slave and did r
you can of course check suggestions, but then you should remove
wordbreak
from your handler, because its purpose is to find cases, when user types
spaces wrongly (e.g., solrrocks, sol rrocks, so lr)
--
View this message in context:
http://lucene.472066.n3.nabble.com/Issue-with-spellcheck
I have the same problem. This bug appeared in 4.0 rarely, but 4.1 downloads
the full index every time.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Slaves-always-replicate-entire-index-Index-versions-tp4041256p4042209.html
Sent from the Solr - User mailing list archive at
Interesting, that there is no such a bug if I disable index compression,
discussed here:
https://issues.apache.org/jira/browse/SOLR-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13566364#comment-13566364
--
View this message in context:
http://lucen
16 matches
Mail list logo