Hello
According to release notes from 4.0.0-ALPHA, SOLR-2396, I replaced
ICUCollationKeyFilterFactory with ICUCollationField in our schema. But this throws an
exception, see the following excerpt from the log:
Jul 16, 2012 5:27:48 PM
I'll consider using the other methods, but I'd like to know which would be
faster among the two approaches mentioned in my opening post.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Wildcard-query-vs-facet-prefix-for-autocomplete-tp3995199p3995458.html
Sent from the Solr -
Hello
According to release notes from 4.0.0-ALPHA, SOLR-2396, I replaced
ICUCollationKeyFilterFactory with ICUCollationField in our schema. But this throws an
exception, see the following excerpt from the log:
Jul 16, 2012 5:27:48 PM
Any ideas on this?
We're running Apache Solr v3.1 and SolrJ is our client.
We're passing multiple Arbitrary Faceting Query (facet.query) to get the
number of matching documents (the facet count) evaluated over the search
results in a *single* Solr query. My use case demands the actual
Hey Guys,
I'm trying to get solr running. I got it installed and I can access the admin
dashboard, but if I try to index some docs, i always get a 404 Error.
I tried it with the following URLs:
http://mydomain/solr/update/json
http://mydomain/solr/mycore/update/json
http://mydomain/update/json
On Tue, Jul 17, 2012 at 6:01 AM, Nils Abegg nils.ab...@ffuf.de wrote:
I have installed the 4.0 Alpha with the build-in Jetty Server on Ubuntu
Server 12.04…i followed this tutorial to set it up:
http://kingstonlabs.blogspot.de/2012/06/installing-solr-36-on-ubuntu-1204.html
Instead of trying to
Same issue with the stock server….i followed the steps of the wiki.
XML via post.jar its working, JSON via Curl is not.
Am 17.07.2012 um 12:05 schrieb Yonik Seeley:
On Tue, Jul 17, 2012 at 6:01 AM, Nils Abegg nils.ab...@ffuf.de wrote:
I have installed the 4.0 Alpha with the build-in Jetty
Ok, i got it working with path /update not /update/json
But it feels somewhat fishy to have solr sitting in my home dir.
Hi
There is one more approach using the property mechanism.
You could specify the datasource like this:
dataSource name=database driver=${sqlDriver} url=${sqlURL}/
And you can specifiy the properties in the solr.xml in your core configuration
like this:
core instanceDir=core1 name=core1
/update/json was removed from the example configuration in 4.0 because /update
now handles content based on content-type internally. It may not be spelled
out as clearly as it should be, but here's the CHANGES entry for it:
* SOLR-2857: Support XML,CSV,JSON, and javabin in a single
OK, maybe I'm finally getting it. When you do a facet.field=blahblah, you're
telling Solr to take all the documents that match the query, look in field
blahblah, and tally the documents that match _any_ value in the field. There's
no restriction at all on the _values_ that that tally is made for.
not really. It's a matter of when your system starts to bog down, and
unfortunately
there's no good way to give general guidance, especially on a number
like size of
the index. 90% of the index size could be stored data (*.fdt and *.fdx
files) that have
no bearing on search requirements.
My
Two things:
1 did you re-index after you got your stopwords file set up? And I'd
blow away the index directory before re-indexing.
2 If you _store_ your field, the stopwords will be in your results
lists, but _not_ in your index. As a secondary
check, try going into your admin/schema browser
In that case, I think your best option is to re-index the entire document
when you have the text available, metadata and all. Which actually
begs the question whether you want to index the bare metadata at
all. Is it the use-case that the user actually gets value when there's no
text? If not,
What you're seeing is the replication of the changed segments (new
segments actually). Replication only moves new or merged
segments and they will be a varying portion of the total index. If you
optimized, you'd see the entire index be moved (but you don't
need to do that!).
You should be able to
I had the same problem as the original poster did two years ago (!), but
with Solr 3.4.0:
I cannot get hits back and do not get a correct total number of records
when using shard searching.
When performing a sharded query, I would get empty / missing results - no
documents at all. Querying each
Hi ,
I am trying to index data in csv format. But while indexing I get this
following message -
body
HTTP ERROR 404
pProblem accessing /solr/update/csv. Reason:
preNOT_FOUND/pre/phr //smallPowered by Jetty:///small/br/
solrconfig.xml has the following entries for CSVRequestHandler
Hi Solr Users,
I would like for my test disable the cache fonction, so I modified all
information concerning cache in solrconfig.xml
but after restarting my Tomcat cache is always here.
Do you think I forgot something?
Requests are done with QTime=1 or QTime=0
and with this rapidity my
I think you could disable Solr caches by setting their size to 0 (deleting
them won't work, as for example, the FieldValueCache will take default
values, not sure about the other ones). I don't think you'll be able to
disable Lucene's Field Cache.
What's the test that you want to run? Why do you
Hi Bruno,
don't forget the OS disk cache.
On linux you can clear it with this tiny script :
#!/bin/bash
sync echo 3 /proc/sys/vm/drop_caches
Ludovic.
-
Jouve
France.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Disable-cache-tp3995575p3995589.html
Sent from
On 07/14/2012 05:32 PM, Erick Erickson wrote:
Really hard to say. Try executing your query on the cores with
debugQuery=on and compare the parsed results (for this you
can probably just ignore the explain bits of the output, concentrate
on the parsed query).
Okay, for the example core from
Hi,
I'd like to bundle up a jar file, with a complete solr home and index.
This jar file is a dependency for another application, which uses an
instance of embedded solr, multi-core. Is there any way to have the
application's embedded solr, read the configs/index data from jar
dependency?
I
Hello,
(Please excuse cross-posting, my problem is with a solr component, but
the underlying issue is inside the lucene test-framework)
I am porting 3x unittests to the solr/lucene trunk. My unittests are
OK and pass, but in the end fail because the new rule checks for
modifier properties. I
Thank you,
Re-index does look like a real option then. I am looking now at
storing text/files in MongoDB or like and indexing into SOLR from
that. Initially, I was going to skip the DB part for as long as
possible.
Regarding the use case, yes it does make sense to have just metadata.
It is rich,
Brian,
Thanks again.
swappiness is set to 60 and from vmstat , I can see no swapping is going on.
Also I am using fusion IO SSD for storing my index.
I also used the visualVM and it shows me that it is blocked on
lock=org.apache.lucene.index.SegmentCoreReaders@299172a7.
Any clue?
On Mon, Jul
Hi,
We have an application where we index data into many different directories
(each directory
is corresponding to a different lucene IndexSearcher).
Looking at Solr config it seems that Solr expects there is only one indexed
data directory,
can we use Solr for our application?
Thanks very
After trying a number of things, I am successful in allowing the server to
auto commit and without having it hit thread/memory errors. I have isolated
the required client change to replacing ConcurrentUpdateSolrServer with
HttpSolrServer. I am able to maintain index rates of 3,000 documents/sec
Hi,
I have been developing extensions to SOLR code using 4.0 truck. For JUnit
testing I am extending AbstractSolrTestCase which in the ALPHA release is
located in JAR apache-solr-test-framework-4.0.0-ALPHA.jar. However, this
class extends LuceneTestCase which comes from JAR
Look up multicore solr. Another choice could be ElasticSearch - which
is more straightforward in managing multiple indexes IMO.
On Tue, Jul 17, 2012 at 7:53 PM, Zhang, Lisheng
lisheng.zh...@broadvision.com wrote:
Hi,
We have an application where we index data into many different directories
Thanks very much for quick help! Multicore sounds interesting,
I roughly read the doc, so we need to put each core name into
Solr config XML, if we add another core and change XML, do we
need to restart Solr?
Best regards, Lisheng
-Original Message-
From: shashi@gmail.com
My suggestion would be to look into Multi Tenancy http://www.elasticsearch.org/.
It is easy to setup and use for multiple indexes.
On Tue, Jul 17, 2012 at 9:26 PM, Zhang, Lisheng
lisheng.zh...@broadvision.com wrote:
Thanks very much for quick help! Multicore sounds interesting,
I roughly read
On Jul 17, 2012, at 8:08 PM, Nick Koton wrote:
So could there be something amiss in the server side implementation of
ConcurrentUpdateSolrServer?
See my earlier email. Once we decide on the appropriate change, we will address
it.
- Mark Miller
lucidimagination.com
On 7/17/2012 9:26 PM, Zhang, Lisheng wrote:
Thanks very much for quick help! Multicore sounds interesting,
I roughly read the doc, so we need to put each core name into
Solr config XML, if we add another core and change XML, do we
need to restart Solr?
You can add/create cores on the fly,
FWIW, when asked at what point one would want to split JVMs and shard,
on the same machine, Grant Ingersoll mentioned 16GB, and precisely for
GC cost reasons. You're way above that.
- his index is 75G, and Grant mentioned RAM heap size; we can use terabytes
of index with 16Gb memory.
-Dfile.encoding=UTF-8... Is this usually recommended for SOLR indexes?
Or is the encoding usually just handled by the servlet container like Jetty?
--
Bill Bell
billnb...@gmail.com
cell 720-256-8076
Hi Users,
Any reply for the query below?
On Mon, Jul 16, 2012 at 6:27 PM, Rajani Maski rajinima...@gmail.com wrote:
In this URL - https://issues.apache.org/jira/browse/SOLR-247
there are *patches *and one patch with name *SOLR-247-FacetAllFields*
Will that help me to fix this problem?
1) In SolrConfig.xml, find ramBufferSizeMB and change to:
ramBufferSizeMB1024/ramBufferSizeMB
2) Also, try decrease the mergefactor to see if it will give you less
segments. In my experiment, it does.
--
View this message in context:
My experience is that this property has made a whole lot of a difference. At
least till solr 3.1.
The servlet container has not been the only bit.
paul
Le 18 juil. 2012 à 05:12, William Bell a écrit :
-Dfile.encoding=UTF-8... Is this usually recommended for SOLR indexes?
Or is the
38 matches
Mail list logo
