Erick Erickson wrote:
> DocValues was designed to support unanalyzed types
> originally. I don't know that code, but given my respect
> for the people who wrote I'd be amazed if there weren't
> very good reasons this is true. I suspect your work-around
> is going to be "surprising".
Hoss talked a
Hi,
I apologize for connecting to this thread but I'm interested in this topic
as well. I think we have a similar configuration: solr 4.8, standard
master/slave replication, data is indexed on master and then replicated to
slave. I'm investigating how to migrate to solr 5.*.
Erick, you say that the
Hi guys
I have a document index with title:#7654321.
Then when I query it with q=title:#7654321, it works
When I query it with q=title:#7654321*, it cannot work,it cannot hit any
result.
Then I remove # and query it with q=title:7654321*, it works again.
I tried q=title:76
Hi Diyun,
Willard queries are not analysed. Probably your index time analyzer is
stripping # character.
Please see : https://wiki.apache.org/solr/MultitermQueryAnalysis
Ahmet
On Wednesday, January 27, 2016 12:02 PM, diyun2008 wrote:
Hi guys
I have a document index with title:#7654321.
As for the subject, which version of java is preferrable to install to run
Solr 5.3.1 on RHEL 7?
I remember in old doc (https://wiki.apache.org/solr/SolrInstall) that for
full international charset support there is the need to install full IDK, it
is still true or is preferable to install stan
I don't have any custom ShardHandler
Regarding the cache, I reduced it to zero, and checking performance now
Thanks,
--
View this message in context:
http://lucene.472066.n3.nabble.com/Read-time-out-exception-exactly-10-minutes-after-starting-committing-tp4252287p4253568.html
Sent from the So
On 1/27/2016 2:00 AM, Zaccheo Bagnati wrote:
> I apologize for connecting to this thread but I'm interested in this topic
> as well. I think we have a similar configuration: solr 4.8, standard
> master/slave replication, data is indexed on master and then replicated to
> slave. I'm investigating ho
This on the surface appears to be similar to an earlier thread by me: "Query
results change"
On Tue, Jan 26, 2016 at 4:32 PM, Jeff Wartes wrote:
>
> Ah, perhaps you fell into something like this then?
> https://issues.apache.org/jira/browse/SOLR-7844
>
> That says it’s fixed in 5.4, but that wou
On 1/27/2016 5:34 AM, Gian Maria Ricci - aka Alkampfer wrote:
>
> As for the subject, which version of java is preferrable to install to
> run Solr 5.3.1 on RHEL 7?
>
>
>
> I remember in old doc (https://wiki.apache.org/solr/SolrInstall) that
> for full international charset support there is the
Jeff, again, very much appreciate your feedback.
It is interesting — the article you linked to by Shalin is exactly why we
picked SolrCloud over ES, because (eventual) consistency is critical for our
application and we will sacrifice availability for it. To be clear, after the
outage, NONE o
On 1/27/2016 8:59 AM, David Smith wrote:
> So we definitely don’t have CP yet — our very first network outage resulted
> in multiple overlapped lost updates. As a result, I can’t pick one replica
> and make it the new “master”. I must rebuild this collection from scratch,
> which I can do, but
The admin/analysis page is your friend here, it'll show you
exactly what happens to your terms as they go through various
stages of your analysis chain. And Ahmet's comment is also
spot on, wildcards are tricky
On Wed, Jan 27, 2016 at 2:25 AM, Ahmet Arslan wrote:
> Hi Diyun,
>
> Willard queri
Well, a Solr index is just a bunch of files. So what I'd do is grab two
machines that are lying around (or even just one with two Solrs)
and try it.
You could just copy the whole Solr tree from your master to machine 1,
from your slave to machine 2. You'd have to change solrconfig on machine 2
to
Hi,
I have created one solrcloud collection with this
`curl
"http://localhost:8983/solr/admin/collections?action=CREATE&name=card&numShards=2&replicationFactor=2&maxShardsPerNode=2&createNodeSet=localhost:8983,localhost:8984,localhost:8985&collection.configName=igp";
It gave me success. An
Hi guys,
I have some code using SolrInstance#queryAndStreamResponse and since I
moved to Solr 5.3.1 (from 4.10.4) my StreamingResponseCallback is
called with a SolrDocument filled with Field instead of the String it
used to receive when calling #get('myfield').
Is this expected ? Should I change
Hello,
Could you please add me to the Contributor Group. Here are my account info :
- Name: Saïd Radhouani
- User name: radhouani
- email: said.radhou...@gmail.com
For more info about myself, please visit my linked page:
https://www.linkedin.com/in/radhouani
Thanks,
-Saïd
2015-12-30 20:36 GMT-
Saïd:
Do you want to ability to edit the Wiki or add code? If the former, we
can add you immediately. The latter is a somewhat longer process you
can start by contributing to the codebase, see:
http://wiki.apache.org/solr/HowToContribute. Note for
adding/commenting on JIRAs, all that's necessary i
On 1/27/16, 8:28 AM, "Shawn Heisey" wrote:
>
>I don't think any documentation states this, but it seems like a good
>idea to me use an alias from day one, so that you always have the option
>of swapping the "real" collection that you are using without needing to
>change anything else. I'll
If you can identify the problem documents, you can just re-index those after
forcing a sync. Might save a full rebuild and downtime.
You might describe your cluster setup, including ZK. it sounds like you’ve done
your research, but improper ZK node distribution could certainly invalidate
some
Sure. Here is our SolrCloud cluster:
+ Three (3) instances of Zookeeper on three separate (physical) servers.
The ZK servers are beefy and fairly recently built, with 2x10 GigE (bonded)
Ethernet connectivity to the rest of the data center. We recognize importance
of the stability and resp
I am actually using one such component to take in the partial dates like
2015-10 and create full UTC dates out of it and query using that. But since
I was checking on that wiki about partial date search and since I couldn't
find that it is available only from 5.x, I was curious to know if by some
w
Hi,
I haven't seen this error before but which version of Solr you are using &
assume zookeeper is configured correctly. Do you see nodes
down/active/leader etc. under Cloud in Admin UI?
Thanks,
Susheel
On Wed, Jan 27, 2016 at 11:51 AM, Pranaya Behera
wrote:
> Hi,
> I have created one sol
Hi Eric
Thank you for your reply.
I saw the admin/analyze page before.
The string "titile:#7654321" for index analysis hit ST with "7654321"
.(That means # is not indexed)
The string "title:#7654321*" for query analysis hit ST(Standard
Tokenizer) with "7654321" as well.
What
Hi,
I would like to find out, is the cache in the Solr cleared when I shut down
the Solr instant and restart it?
I am suspecting that the cache is not entirely cleared, because when I try
to do a search on the same query as I did before the search, it still has a
return QTime that is much faster
Are you sure the query is getting through unadulterated to Solr?
For example:
/opt/code/lusolr$ curl 'http://localhost:8983/solr/techproducts/query?q=id:#foo'
{
"responseHeader":{
"status":400,
"QTime":2,
"params":{
"q":"id:"}},
"error":{
"msg":"org.apache.solr.search.Sy
Hi Ahmet
Thank you for your reply.
The title type is "text_general" and it uses Standard Tokenizer.
The string "titile:#7654321" by index analysis hit ST with "7654321"
.(That means # is not indexed)
The string "title:#7654321*" by query analysis hit ST(Standard
Tokenizer) with "7
Hi Yonik
I do actually encode it like q=titile:%237654321* (which is :
q=titile:#7654321*)
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-cannot-return-result-when-query-with-like-title-7654321-tp4253541p4253734.html
Sent from the Solr - User mailing list archiv
On Wed, Jan 27, 2016 at 10:47 PM, diyun2008 wrote:
> Hi Yonik
>
>I do actually encode it like q=titile:%237654321* (which is :
> q=titile:#7654321*)
Yes, if you *need* to encode it yourself (i.e. if you're using curl,
or a browser URL bar). It really depends on the client you are using.
-Yo
Just be to sure, please post the lines of code or command line that you are
using to issue the query.
-- Jack Krupansky
On Wed, Jan 27, 2016 at 10:50 PM, Yonik Seeley wrote:
> On Wed, Jan 27, 2016 at 10:47 PM, diyun2008 wrote:
> > Hi Yonik
> >
> >I do actually encode it like q=titile:%2376
Caches are in-memory structures, there's no provision in Solr
to try to preserve them across a shutdown, they'd have to be written
to disk then re-read.
Any intermediate cached pages, i.e. something in you app server is
another story however. Solr has no control over that.
Best,
Erick
On Wed, Ja
Hi,
I am using solr 5.4.0. In the admin ui i can see for each node
there are 2 shards with leader color. zookeeper is configured correctly
as in the using the example config only on standalone server.
On Thursday 28 January 2016 03:16 AM, Susheel Kumar wrote:
Hi,
I haven't seen this err
On 1/27/2016 8:11 PM, Zheng Lin Edwin Yeo wrote:
> I would like to find out, is the cache in the Solr cleared when I shut down
> the Solr instant and restart it?
>
> I am suspecting that the cache is not entirely cleared, because when I try
> to do a search on the same query as I did before the sea
On 1/27/2016 8:00 PM, diyun2008 wrote:
> What I was rather confused is if they all hit same string "7654321", why
> it cannot return the hit result by query(q=#7654321*)?
When a wildcard is present in the query, the terms in the query are NOT
analyzed. I'm not sure exactly why this is the ca
Thanks Erick and Shawn for your reply.
We have recently upgraded the server RAM from 64MB to 192MB, and I noticed
that this caching occurs after we upgraded the RAM. Previously, the cache
may not even be preserved in the same Solr session.
So is it true that the upgrading of the server RAM creates
The query is rather simple:
http://127.0.0.1:8080/solr/collection1/select?q=title:#7654321*
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-cannot-return-result-when-query-with-like-title-7654321-tp4253541p4253760.html
Sent from the Solr - User mailing list archive at
Hi Sriram,
Add the tag 'propertyWriter' directly under the 'dataConfig' tag. The
property "last_index_time" is converted to text and stored in the
properties file and is available for the next import as the variable
'${dih.last_index_time}' . This tag gives control over how this properties
file is
Hi Sriram,
Add the tag 'propertyWriter' directly under the 'dataConfig' tag. The
property "last_index_time" is converted to text and stored in the
properties file and is available for the next import as the variable
'${dih.last_index_time}' . This tag gives control over how this properties
file is
Hi Shawn
Thank you for you reply.
But The weird place is why it can return result by condition
(q=title:#7654321) and condition (q=title:7654321*) or (q=title:7654321).
From your assumption, the condition (q=title:#7654321) should not return
result as well.(But it does return hit result)
On 1/27/2016 11:31 PM, diyun2008 wrote:
>Thank you for you reply.
>But The weird place is why it can return result by condition
> (q=title:#7654321) and condition (q=title:7654321*) or (q=title:7654321).
>
>From your assumption, the condition (q=title:#7654321) should not return
> resul
Hi Shawn
Your information is very important. It can explain the phenomena I met.
Do you know from where I can get the related document Or subject about
what you said?
I want to have a deep understand to this.
Thank you Very much!
Diyun
--
View this message in context:
Hi,
I have checked in the admin UI and now I have created 3 shards 2
replicas for each shard and 1 shard per node. This is what I get:
{"card":{ "replicationFactor":"2", "router":{"name":"compositeId"},
"maxShardsPerNode":"1", "autoAddReplicas":"false", "shards":{ "shard1":{
"range":"8000
Its only happening when I specify the createNodeSet (list of nodes comma
separated). If I remove this then it works as expected.
On Thursday 28 January 2016 12:45 PM, Pranaya Behera wrote:
Hi,
I have checked in the admin UI and now I have created 3 shards 2
replicas for each shard and 1 sh
43 matches
Mail list logo