Re: Solrits - Problem with facing after restart yetty
I think you're asking if the (very temporary on trunk) faceting bug is fixed. The answer is yes. Erik On May 29, 2009, at 3:10 AM, Jörg Agatz wrote: i the Bug fixt in the news Nightliy Bilds?
replication solr 1.4
Hi guys, I didnt ennoy you for ages now ... hope everybody is fine ... I've an issue with my replication I was wondering ... after a while replication doesnt work anymore ... we have a script which enable or not replication every 2hours and this morning it didnt pull anything and it's maybe because the version is too far away ? is it possible ??? is it possible to tell it to just take the last one ? cuz now it's working but because i clicked on replication. thanks a lot, Johanna Replicatable Index Version:1239958162858, Generation: 1741 Poll Interval 00:00:30 Local Index Index Version: 1239958162819, Generation: 1702 Location: /data/solr/video/data/index Size: 8.86 GB Times Replicated Since Startup: 896 Previous Replication Done At: Thu May 28 14:39:51 CEST 2009 Config Files Replicated At: Config Files Replicated: Times Config Files Replicated Since Startup: Next Replication Cycle At: Thu May 28 14:34:31 CEST 2009 Current Replication Status Start Time: Fri May 29 11:49:50 CEST 2009 Files Downloaded: 0 / 12 Downloaded: 1.66 GB / 8.87 GB [18.0%] Downloading File: _5io.prx, Downloaded: 1.66 GB / 2.22 GB [74.0%] Time Elapsed: 122s, Estimated Time Remaining: 528s, Speed: 13.96 MB/s Controls Cores: [video ][user ][group ] Current Time: Fri May 29 11:51:52 CEST 2009 Server Start At: Thu May 28 10:43:30 CEST 2009 Return to Admin Page -- View this message in context: http://www.nabble.com/replication-solr-1.4-tp23777206p23777206.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: replication solr 1.4
what would be the url to ping to replicate like http://slave_host:port/solr/replication?command=enablepoll thanks -- View this message in context: http://www.nabble.com/replication-solr-1.4-tp23777206p23777272.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: java.lang.RuntimeException: after flush: fdx size mismatch
Very interesting: FieldsWriter thinks it's written 12 bytes to the fdx
file, yet the directory says the file does not exist.
Can you re-run with this new patch? I'm suspecting that FieldsWriter
wrote to one segment, but somehow we are then looking at the wrong
segment. The attached patch prints out which segment FieldsWriter
actually wrote to.
What filesystem underlying IO system/device are you using?
Mike
On Thu, May 28, 2009 at 10:53 PM, James X
hello.nigerian.spamm...@gmail.com wrote:
My apologies for the delay in running this patched Lucene build - I was
temporarily pulled onto another piece of work.
Here is a sample 'fdx size mismatch' exception using the patch Mike
supplied:
SEVERE: java.lang.RuntimeException: after flush: fdx size mismatch: 1 docs
vs 0 length in bytes of _1i.fdx exists=false didInit=false inc=0 dSO=1
fieldsWriter.doClose=true fieldsWriter.indexFilePointer=12
fieldsWriter.fieldsFilePointer=2395
at
org.apache.lucene.index.StoredFieldsWriter.closeDocStore(StoredFieldsWriter.java:96)
at
org.apache.lucene.index.DocFieldConsumers.closeDocStore(DocFieldConsumers.java:83)
at
org.apache.lucene.index.DocFieldProcessor.closeDocStore(DocFieldProcessor.java:47)
at
org.apache.lucene.index.DocumentsWriter.closeDocStore(DocumentsWriter.java:367)
at
org.apache.lucene.index.DocumentsWriter.flush(DocumentsWriter.java:567)
at
org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3540)
at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3450)
at
org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1638)
at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1602)
at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1578)
at
org.apache.solr.update.SolrIndexWriter.close(SolrIndexWriter.java:153)
Will now run with assertions enabled and see how that affects the behaviour!
Thanks,
James
-- Forwarded message --
From: James X hello.nigerian.spamm...@gmail.com
Date: Thu, May 21, 2009 at 2:24 PM
Subject: Re: java.lang.RuntimeException: after flush: fdx size mismatch
To: solr-user@lucene.apache.org
Hi Mike,Documents are web pages, about 20 fields, mostly strings, a couple
of integers, booleans and one html field (for document body content).
I do have a multi-threaded client pushing docs to Solr, so yes, I suppose
that would mean I have several active Solr worker threads.
The only exceptions I have are the RuntimeException flush errors, followed
by a handful (normally 10-20) of LockObtainFailedExceptions, which i
presumed were being caused by the faulty threads dying and failing to
release locks.
Oh wait, I am getting WstxUnexpectedCharException exceptions every now and
then:
SEVERE: com.ctc.wstx.exc.WstxUnexpectedCharException: Illegal character
((CTRL-CHAR, code 8))
at [row,col {unknown-source}]: [1,26070]
at
com.ctc.wstx.sr.StreamScanner.throwInvalidSpace(StreamScanner.java:675)
at
com.ctc.wstx.sr.BasicStreamReader.readTextSecondary(BasicStreamReader.java:4668)
at
com.ctc.wstx.sr.BasicStreamReader.readCoalescedText(BasicStreamReader.java:4126)
at
com.ctc.wstx.sr.BasicStreamReader.finishToken(BasicStreamReader.java:3701)
at
com.ctc.wstx.sr.BasicStreamReader.safeFinishToken(BasicStreamReader.java:3649)
at
com.ctc.wstx.sr.BasicStreamReader.getText(BasicStreamReader.java:809)
at
org.apache.solr.handler.XmlUpdateRequestHandler.readDoc(XmlUpdateRequestHandler.java:327)
I presumed these were caused by character encoding issues, but haven't
looked into them at all yet.
Thanks again for your help! I'll make some time this afternoon to build some
patched Lucene jars and get the results
On Thu, May 21, 2009 at 5:06 AM, Michael McCandless
luc...@mikemccandless.com wrote:
Another question: are there any other exceptions in your logs? Eg
problems adding certain documents, or anything?
Mike
On Wed, May 20, 2009 at 11:18 AM, James X
hello.nigerian.spamm...@gmail.com wrote:
Hi Mike, thanks for the quick response:
$ java -version
java version 1.6.0_11
Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
Java HotSpot(TM) 64-Bit Server VM (build 11.0-b16, mixed mode)
I hadn't noticed the 268m trigger for LUCENE-1521 - I'm definitely not
hitting that yet!
The exception always reports 0 length, but the number of of docs varies,
heavily weighted towards 1 or two docs. Of the last 130 or so exceptions:
89 1 docs vs 0 length
20 2 docs vs 0 length
9 3 docs vs 0 length
1 4 docs vs 0 length
3 5 docs vs 0 length
2 6 docs vs 0 length
1 7 docs vs 0 length
1 9 docs vs 0 length
1 10 docs vs 0 length
The only unusual thing I can think of that we're doing with Solr is
aggressively CREATE-ing and UNLOAD-ing cores. I've not been able to spot
a
pattern between core
Avoid duplicates in MoreLikeThis using field collapsing
Hey there,
I am testing MoreLikeThis feaure (with MoreLikeThis component and with
MoreLikeThis handler) and I am getting lots of duplicates. I have noticed
that lots of the similar documents returned are duplicates. To avoid that I
have tried to use the field collapsing patch but it's not taking effect.
In case of MoreLikeThis handler I think it's normal has I have seen it
extends directly from RequestHandlerBase.java and not from
SearchHandler.java that is the one that in the function handleRequestBody
will deal with components:
for( SearchComponent c : components ) {
rb.setTimer( subt.sub( c.getName() ) );
c.prepare(rb);
rb.getTimer().stop();
}
To sort it out I have embbed the collapseFilter in the getMoreLikeThis
method of the MoreLikeThisHandler.java
This is working alrite but would like to know if is there any more polite
way to make MoreLikeThisHandler able to deal with components. I mean via
solrconfig.xml or pluging something instead of hacking it.
Thanks in advance
--
View this message in context:
http://www.nabble.com/Avoid-duplicates-in-MoreLikeThis-using-field-collapsing-tp23778054p23778054.html
Sent from the Solr - User mailing list archive at Nabble.com.
Re: Solrits - Problem with facing after restart yetty
Jorg - the rest of that exception would be mighty handy! Please share the entire details. Erik On May 29, 2009, at 7:38 AM, Jörg Agatz wrote: also, i have after using the Nightly bUILD FROM tODY, 29.05.2009 BUT THE sAME ERROR... HTTP ERROR 500 null java.lang.NullPointerException ... ... ... The url is: .../solr/itas?fq=cat:test when i tryed .../solr/itas?q=SEARCHWORDcat:test ir worket, links dosent work
Re: Solrits - Problem with facing after restart yetty
HTTP ERROR: 500 null java.lang.NullPointerException at java.io.StringReader.init(StringReader.java:33) at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:169) at org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:78) at org.apache.solr.search.QParser.getQuery(QParser.java:131) at org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:91) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:174) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1328) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:244) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:285) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378) at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) RequestURI=/solr/itas *Powered by Jetty:// http://jetty.mortbay.org/* goog_1243600484811 My Conf: requestHandler name=/itas class=solr.SearchHandler lst name=defaults str name=v.templatebrowse/str str name=v.propertiesvelocity.properties/str str name=titleSolritas/str str name=wtvelocity/str str name=q.alt*:*/str str name=rows10/str str name=fl*,score/str str name=faceton/str str name=facet.fieldextension/str str name=facet.mincount1/str str name=qf/str /lst * http://jetty.mortbay.org/*
Re: Java OutOfmemory error during autowarming
It's probably not the size of the query cache, but the size of the FieldCache entries that are used for sorting and function queries (that's the only thing that should be allocating huge arrays like that). What fields do you sort on or use function queries on? There may be a way to decrease the memory consumption. -Yonik http://www.lucidimagination.com On Fri, May 29, 2009 at 1:02 AM, Francis Yakin fya...@liquid.com wrote: During auto-warming of solr search on QueryResultKey, Our Production solrslaves errors throw OutOfMemory error and application need to be bounced. Here is the error logs: SEVERE: Error during auto-warming of key:org.apache.solr.search.queryresult...@9acd5d67mailto:org.apache.solr.search.queryresult...@9acd5d67:java.lang.OutOfMemoryError: allocLargeObject OrArray - Object size: 25291544, Num elements: 6322881 SEVERE: Error during auto-warming of key:org.apache.solr.search.queryresult...@84554284mailto:org.apache.solr.search.queryresult...@84554284:java.lang.OutOfMemoryError: allocLargeObject OrArray - Object size: 579368, Num elements: 144837 SEVERE: Error during auto-warming of key:org.apache.solr.search.queryresult...@8c1e63e4mailto:org.apache.solr.search.queryresult...@8c1e63e4:java.lang.OutOfMemoryError: allocLargeObject OrArray - Object size: 4280976, Num elements: 1070240 I read some suggestions from google that increasing the size of queryResultCache in the solrconfig.xml file will help, here is the suggestion: This is not directly related to the jvm heap size. During slave replication the current Searcher is used as the source of auto-warming. When a new searcher is opened, its caches may be prepopulated or autowarmed using data from caches in the old searcher. It sounds like caching configuration problem to me as is evident from the error message Error during auto-warming of key. I suggest increasing the size of the query cache on one of the slave servers and monitor it over next week or so and then incrementally roll this change to rest of the slave boxes. This is the change that you need to make in solrconfig.xml Right now this what I have: queryResultCache class=solr.LRUCache size=512 initialSize=512 autowarmCount=256/ Should I increase size to 1024 will help? Any input? Thanks Francis
Re: Custom sort
I have been able to create my custom field. The problem is that I have laoded in the solr core a couple of HashMapsid_doc,value_influence_sort from a DB with values that will influence in the sort. My problem is that I don't know how to let my custom sort have access to this HashMaps. I am a bit confused now. I think that would be easy to reach my goal using: CustomSortComponent extends SearchComponent implements SolrCoreAware This way, I would load the HashMaps in the inform method and would create de custom sort using the HashMaps in the preprare method. Don't know how to do that with the CustomField (similar to the RandomField)... any advice? Yonik Seeley-2 wrote: The custom Field type similar to RandomSortField is definitely the way to go over a custom component since it's much less invasive - then everything else like distributed search should work. But see SOLR-... I'm in the process of converting Solr to use the new FieldComparatorSource. -Yonik http://www.lucidimagination.com On Tue, May 26, 2009 at 9:25 AM, Marc Sturlese marc.sturl...@gmail.com wrote: Hey there, I want to implement a custom sort coding my own SortComparatorSource. The sorter would sort the results doing some calculations of some document attributes witch I have loaded previously from a DB at the solr core init. I mean, I have a preloaded hash with some attributes per doc id and I want to use them to implement the sorting. I have considered two options: First would be to implement a custom field similar to the solr RandomSortField and when search requests are done I would tell solr to sort using this custom field. The other option would be to plug a component (wich would extend from SearchComponent) and do the custom sort in the prepare method. Any advice witch is the most optimal way to do that? Thanks in advance. -- View this message in context: http://www.nabble.com/Custom-sort-tp23722921p23722921.html Sent from the Solr - User mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/Custom-sort-tp23722921p23783579.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: index time boosting on multivalued fields
What are you really trying to accomplish here? Because index time boostingis a way of saying I care about matches in this field of this document X times more than other documents whereas search time boosting expresses elevate the relevance of any document where this term matches From your example, it looks like you're really thinking about search-time boosting rather than index time. If I'm out in left field, perhaps an explanation of the problem you're trying to solve would help me clarify... Best Erick On Wed, May 27, 2009 at 3:14 PM, Brian Whitman br...@echonest.com wrote: I can set the boost of a field or doc at index time using the boost attr in the update message, e.g. field name=type boost=2.0pet/field But that won't work for multivalued fields according to the RelevancyFAQ field name=type boost=2.0pet/field field name=type boost=1.0animal/field ( I assume it applies the last boost parsed to all terms? ) Now, say I'd like to do index-time boosting of a multivalued field with each value having a unique boost. I could simply index the field multiple times: field name=typepet/field field name=typepet/field field name=typeanimal/field But is there a more exact way?
RE: Java OutOfmemory error during autowarming
There is no FieldCache entries in solrconfig.xml ( BTW we are running version 1.2.0) -Original Message- From: Yonik Seeley [mailto:ysee...@gmail.com] Sent: Friday, May 29, 2009 9:12 AM To: solr-user@lucene.apache.org Subject: Re: Java OutOfmemory error during autowarming It's probably not the size of the query cache, but the size of the FieldCache entries that are used for sorting and function queries (that's the only thing that should be allocating huge arrays like that). What fields do you sort on or use function queries on? There may be a way to decrease the memory consumption. -Yonik http://www.lucidimagination.com On Fri, May 29, 2009 at 1:02 AM, Francis Yakin fya...@liquid.com wrote: During auto-warming of solr search on QueryResultKey, Our Production solrslaves errors throw OutOfMemory error and application need to be bounced. Here is the error logs: SEVERE: Error during auto-warming of key:org.apache.solr.search.queryresult...@9acd5d67mailto:org.apache.s olr.search.queryresult...@9acd5d67:java.lang.OutOfMemoryError: allocLargeObject OrArray - Object size: 25291544, Num elements: 6322881 SEVERE: Error during auto-warming of key:org.apache.solr.search.queryresult...@84554284mailto:org.apache.s olr.search.queryresult...@84554284:java.lang.OutOfMemoryError: allocLargeObject OrArray - Object size: 579368, Num elements: 144837 SEVERE: Error during auto-warming of key:org.apache.solr.search.queryresult...@8c1e63e4mailto:org.apache.s olr.search.queryresult...@8c1e63e4:java.lang.OutOfMemoryError: allocLargeObject OrArray - Object size: 4280976, Num elements: 1070240 I read some suggestions from google that increasing the size of queryResultCache in the solrconfig.xml file will help, here is the suggestion: This is not directly related to the jvm heap size. During slave replication the current Searcher is used as the source of auto-warming. When a new searcher is opened, its caches may be prepopulated or autowarmed using data from caches in the old searcher. It sounds like caching configuration problem to me as is evident from the error message Error during auto-warming of key. I suggest increasing the size of the query cache on one of the slave servers and monitor it over next week or so and then incrementally roll this change to rest of the slave boxes. This is the change that you need to make in solrconfig.xml Right now this what I have: queryResultCache class=solr.LRUCache size=512 initialSize=512 autowarmCount=256/ Should I increase size to 1024 will help? Any input? Thanks Francis
Re: Java OutOfmemory error during autowarming
On Fri, May 29, 2009 at 1:44 PM, Francis Yakin fya...@liquid.com wrote: There is no FieldCache entries in solrconfig.xml ( BTW we are running version 1.2.0) Lucene FieldCache entries are created when you sort on a field or when you use a field in a function query. -Yonik
RE: Java OutOfmemory error during autowarming
I know, but the FieldCache is not in the solrconfig.xml -Original Message- From: Yonik Seeley [mailto:ysee...@gmail.com] Sent: Friday, May 29, 2009 10:47 AM To: solr-user@lucene.apache.org Subject: Re: Java OutOfmemory error during autowarming On Fri, May 29, 2009 at 1:44 PM, Francis Yakin fya...@liquid.com wrote: There is no FieldCache entries in solrconfig.xml ( BTW we are running version 1.2.0) Lucene FieldCache entries are created when you sort on a field or when you use a field in a function query. -Yonik
Re: java.lang.RuntimeException: after flush: fdx size mismatch
Hi Mike,I don't see a patch file here?
Could another explanation be that the fdx file doesn't exist yet / has been
deleted from underneath Lucene?
I'm constantly CREATE-ing and UNLOAD-ing Solr cores, and more importantly,
moving the bundled cores around between machines. I find it much more likely
that there's something wrong with my core admin code than there is with the
Lucene internals :) It's possible that I'm occasionally removing files which
are currently in use by a live core...
I'm using an ext3 filesystem on a large EC2 instance's own hard disk. I'm
not sure how Amazon implement the local hard disk, but I assume it's a real
hard disk exposed by the hypervisor.
Thanks,
James
On Fri, May 29, 2009 at 3:41 AM, Michael McCandless
luc...@mikemccandless.com wrote:
Very interesting: FieldsWriter thinks it's written 12 bytes to the fdx
file, yet the directory says the file does not exist.
Can you re-run with this new patch? I'm suspecting that FieldsWriter
wrote to one segment, but somehow we are then looking at the wrong
segment. The attached patch prints out which segment FieldsWriter
actually wrote to.
What filesystem underlying IO system/device are you using?
Mike
On Thu, May 28, 2009 at 10:53 PM, James X
hello.nigerian.spamm...@gmail.com wrote:
My apologies for the delay in running this patched Lucene build - I was
temporarily pulled onto another piece of work.
Here is a sample 'fdx size mismatch' exception using the patch Mike
supplied:
SEVERE: java.lang.RuntimeException: after flush: fdx size mismatch: 1
docs
vs 0 length in bytes of _1i.fdx exists=false didInit=false inc=0 dSO=1
fieldsWriter.doClose=true fieldsWriter.indexFilePointer=12
fieldsWriter.fieldsFilePointer=2395
at
org.apache.lucene.index.StoredFieldsWriter.closeDocStore(StoredFieldsWriter.java:96)
at
org.apache.lucene.index.DocFieldConsumers.closeDocStore(DocFieldConsumers.java:83)
at
org.apache.lucene.index.DocFieldProcessor.closeDocStore(DocFieldProcessor.java:47)
at
org.apache.lucene.index.DocumentsWriter.closeDocStore(DocumentsWriter.java:367)
at
org.apache.lucene.index.DocumentsWriter.flush(DocumentsWriter.java:567)
at
org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3540)
at
org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3450)
at
org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1638)
at
org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1602)
at
org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1578)
at
org.apache.solr.update.SolrIndexWriter.close(SolrIndexWriter.java:153)
Will now run with assertions enabled and see how that affects the
behaviour!
Thanks,
James
-- Forwarded message --
From: James X hello.nigerian.spamm...@gmail.com
Date: Thu, May 21, 2009 at 2:24 PM
Subject: Re: java.lang.RuntimeException: after flush: fdx size mismatch
To: solr-user@lucene.apache.org
Hi Mike,Documents are web pages, about 20 fields, mostly strings, a
couple
of integers, booleans and one html field (for document body content).
I do have a multi-threaded client pushing docs to Solr, so yes, I suppose
that would mean I have several active Solr worker threads.
The only exceptions I have are the RuntimeException flush errors,
followed
by a handful (normally 10-20) of LockObtainFailedExceptions, which i
presumed were being caused by the faulty threads dying and failing to
release locks.
Oh wait, I am getting WstxUnexpectedCharException exceptions every now
and
then:
SEVERE: com.ctc.wstx.exc.WstxUnexpectedCharException: Illegal character
((CTRL-CHAR, code 8))
at [row,col {unknown-source}]: [1,26070]
at
com.ctc.wstx.sr.StreamScanner.throwInvalidSpace(StreamScanner.java:675)
at
com.ctc.wstx.sr.BasicStreamReader.readTextSecondary(BasicStreamReader.java:4668)
at
com.ctc.wstx.sr.BasicStreamReader.readCoalescedText(BasicStreamReader.java:4126)
at
com.ctc.wstx.sr.BasicStreamReader.finishToken(BasicStreamReader.java:3701)
at
com.ctc.wstx.sr.BasicStreamReader.safeFinishToken(BasicStreamReader.java:3649)
at
com.ctc.wstx.sr.BasicStreamReader.getText(BasicStreamReader.java:809)
at
org.apache.solr.handler.XmlUpdateRequestHandler.readDoc(XmlUpdateRequestHandler.java:327)
I presumed these were caused by character encoding issues, but haven't
looked into them at all yet.
Thanks again for your help! I'll make some time this afternoon to build
some
patched Lucene jars and get the results
On Thu, May 21, 2009 at 5:06 AM, Michael McCandless
luc...@mikemccandless.com wrote:
Another question: are there any other exceptions in your logs? Eg
problems adding certain documents, or anything?
Mike
On Wed, May 20, 2009 at 11:18 AM, James X
Refresh synonyms.txt file via replication
Hi All, I would like to provide an admin interface (in a different system) that would update the synonyms.txt file and automatically inform a set of Solr instances that are being replicated to update their synonyms.txt file too. This discussion shows a possible solution: http://www.nabble.com/Refresh-of-synonyms.txt-without-reload-td19629361.html Namely use the CoreAdmin system to do a RELOAD, rather than forcing tomcat to reload the webapp. Here is my setup: 1) I made these instances (both are separate webapps running one core named core, this allows me to use the CoreAdmin): http://localhost:8080/solr_rep_master/core/admin/ http://localhost:8080/solr_rep_slave1/core/admin/ 2) the master's config looks like this: lst name=master str name=replicateAfterstartup/str str name=replicateAftercommit/str str name=snapshotstartup/str str name=snapshotcommit/str str name=confFilesschema.xml,stopwords.txt,synonyms.txt/str /lst 3) the slave's config looks like this: lst name=slave str name=masterUrlhttp://localhost:8080/solr_rep_master/core/replication/str str name=pollInterval00:00:20/str str name=compressioninternal/str /lst First Question: If i update the solr_rep_master's conf/synonyms.txt file and GET http://localhost:8080/solr_rep_master/admin/cores?action=RELOADcore=core, the config is not replicated to the slave. Isn't a RELOAD considered a startup in regards to the master's replicateAfter setting? Second Question: If i force an empty commit, like this: curl http://localhost:8080/solr_rep_master/core/update?stream.body=%3Ccommit/%3E Then the changed synonym.txt config file are replicated to the slave. Unfortunately now I need to do a core RELOAD on both the master and slave to get them to see the updated synonym.txt file. Is there any way to circumvent this reload? (this is what was effectively asked in the nabble link at the top) Thanks --Matthias -- View this message in context: http://www.nabble.com/Refresh-synonyms.txt-file-via-replication-tp23789187p23789187.html Sent from the Solr - User mailing list archive at Nabble.com.
query issue /special character and case
Hi , When i give a query like the following ,why does it become a phrase query as shown below? The field type is the default text field in the schema. str name=querystringvolker-blanz/str str name=parsedqueryPhraseQuery(content:volker blanz)/str Also when i have special characters in the query as SCHÖLKOPF , i am not able to convert the o with spl character to lower case on my unix os/it works fine on windows xp OS .Also if i have a spl character in my query ,i would like to search for it wihtout the special character as SCHOLKOPF ,this works fine in windows with strtr (string translate php fucntion) ,but again not in windows OS. Any pointers Regards Revas
