Re: How to use DocValues with TextField

[Toke Eskildsen]

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 about this at the last Lucene/Solr Revolution and has opened
https://issues.apache.org/jira/browse/SOLR-8362

Harry: Maybe you could follow up on that JIRA issue?

- Toke Eskildsen

Re: migrating solr 4.2.1 to 5.X

[Zaccheo Bagnati]

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 there is a full backward compatibility between 4.* and
5.* so, for example, we could migrate the slave (and it will continue to
read old indexes), then migrate the master (and it could could even update
old indexes without need for full reindex). It seems too simple... and I
hope it will be so, but my experience of migrations is not so painless as
you say...(I'm not referring to SOLR)
Is there anyone who tried this approach on a production environment? What I
should be more careful of? Is there any incompatibility in REST calls and
responses?
Thank you

Il giorno mar 26 gen 2016 alle ore 18:31 Erick Erickson <
erickerick...@gmail.com> ha scritto:

> Yes and Yes. The developers try very hard to make Solr
> one major release backwards compatible. So 5x should be
> able to read 4x just fine.
>
> Nothing has really changed in replication, so 5x supports
> master/slave. It's just becoming less popular as SolrCloud
> is significantly easier to operationalize.
>
> Note that as segments get written they will be transformed from 4x
> format to 5x. And you can also use the index upgrade tool here:
>
> https://lucene.apache.org/core/5_0_0/core/org/apache/lucene/index/IndexUpgrader.html
>
> to transform your 4x to 5x
>
> Best,
> Erick
>
> On Tue, Jan 26, 2016 at 7:51 AM, Midas A  wrote:
> > I want migrate from solr 4.2.1 to 5.X version hten my question is
> >
> > - can i use same snapshot of 4.2.1 in 5.x.x
> >
> > Actually Indexing will take long time in my case then it would be
> possible
> > to do
> > or we should not do this.
> >
> >
> > next similar question is
> >
> > - can we replicate 4.2.1 master to slave 5.x.x solr
>

Solr cannot return result when query with # * like title:#7654321*

[diyun2008]

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:76543*, it works!

 So I suspect there's a bug in lucene when using query with symbol # and
*.

 Who had ever met this ?or does anyone can help try it.

Thank you for your help.
 



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Solr-cannot-return-result-when-query-with-like-title-7654321-tp4253541.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Solr cannot return result when query with # * like title:#7654321*

[Ahmet Arslan]

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.
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:76543*, it works!

 So I suspect there's a bug in lucene when using query with symbol # and
*.

 Who had ever met this ?or does anyone can help try it.

Thank you for your help.




--
View this message in context: 
http://lucene.472066.n3.nabble.com/Solr-cannot-return-result-when-query-with-like-title-7654321-tp4253541.html
Sent from the Solr - User mailing list archive at Nabble.com.

Which version of java is preferrable to install on a Red Hat Enterprise Linux 7?

[Gian Maria Ricci - aka Alkampfer]

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 standard JRE as for the official
documentation
(https://cwiki.apache.org/confluence/display/solr/Installing+Solr )

 

Thanks.

 

--
Gian Maria Ricci
Cell: +39 320 0136949

 

   


 

Re: Read time out exception - exactly 10 minutes after starting committing

[adfel70]

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 Solr - User mailing list archive at Nabble.com.

Re: migrating solr 4.2.1 to 5.X

[Shawn Heisey]

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 how to migrate to solr 5.*.
> Erick, you say that there is a full backward compatibility between 4.* and
> 5.* so, for example, we could migrate the slave (and it will continue to
> read old indexes), then migrate the master (and it could could even update
> old indexes without need for full reindex). It seems too simple... and I
> hope it will be so, but my experience of migrations is not so painless as
> you say...(I'm not referring to SOLR)
> Is there anyone who tried this approach on a production environment? What I
> should be more careful of? Is there any incompatibility in REST calls and
> responses?

Upgrading slaves first and then the master is the recommended way to do
upgrades in a master/slave installation.  Many people have done upgrades
in this exact way with success.

I personally would completely rebuild the index once I had the masters
upgraded, so Solr will perform best.

Thanks,
Shawn

Re: SolrCloud replicas out of sync

[Brian Narsi]

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 would be an example of a split-brain
> type incident, where different documents were accepted by different
> replicas who each thought they were the leader. If this is the case, and
> you actually have different data on each replica, I’m not aware of any way
> to fix the problem short of reindexing those documents. Before that, you’ll
> probably need to choose a replica and just force the others to get in sync
> with it. I’d choose the current leader, since that’s slightly easier.
>
> Typically, a leader writes an update to it’s transaction log, then sends
> the request to all replicas, and when those all finish it acknowledges the
> update. If a replica gets restarted, and is less than N documents behind,
> the leader will only replay that transaction log. (Where N is the
> numRecordsToKeep configured in the updateLog section of solrconfig.xml)
>
> What you want is to provoke the heavy-duty process normally invoked if a
> replica has missed more than N docs, which essentially does a checksum and
> file copy on all the raw index files. FetchIndex would probably work, but
> it’s a replication handler API originally designed for master/slave
> replication, so take care:
> https://wiki.apache.org/solr/SolrReplication#HTTP_API
> Probably a lot easier would be to just delete the replica and re-create
> it. That will also trigger a full file copy of the index from the leader
> onto the new replica.
>
> I think design decisions around Solr generally use CP as a goal. (I
> sometimes wish I could get more AP behavior!) See posts like this:
> http://lucidworks.com/blog/2014/12/10/call-maybe-solrcloud-jepsen-flaky-networks/
> So the fact that you encountered this sounds like a bug to me.
> That said, another general recommendation (of mine) is that you not use
> Solr as your primary data source, so you can rebuild your index from
> scratch if you really need to.
>
>
>
>
>
>
> On 1/26/16, 1:10 PM, "David Smith"  wrote:
>
> >Thanks Jeff!  A few comments
> >
> >>>
> >>> Although you could probably bounce a node and get your document counts
> back in sync (by provoking a check)
> >>>
> >
> >
> >If the check is a simple doc count, that will not work. We have found
> that replica1 and replica3, although they contain the same doc count, don’t
> have the SAME docs.  They each missed at least one update, but of different
> docs.  This also means none of our three replicas are complete.
> >
> >>>
> >>>it’s interesting that you’re in this situation. It implies to me that
> at some point the leader couldn’t write a doc to one of the replicas,
> >>>
> >
> >That is our belief as well. We experienced a datacenter-wide network
> disruption of a few seconds, and user complaints started the first workday
> after that event.
> >
> >The most interesting log entry during the outage is this:
> >
> >"1/19/2016, 5:08:07 PM ERROR null DistributedUpdateProcessorRequest says
> it is coming from leader,​ but we are the leader:
> update.distrib=FROMLEADER&distrib.from=
> http://dot.dot.dot.dot:8983/solr/blah_blah_shard1_replica3/&wt=javabin&version=2
> "
> >
> >>>
> >>> You might watch the achieved replication factor of your updates and
> see if it ever changes
> >>>
> >
> >This is a good tip. I’m not sure I like the implication that any failure
> to write all 3 of our replicas must be retried at the app layer.  Is this
> really how SolrCloud applications must be built to survive network
> partitions without data loss?
> >
> >Regards,
> >
> >David
> >
> >
> >On 1/26/16, 12:20 PM, "Jeff Wartes"  wrote:
> >
> >>
> >>My understanding is that the "version" represents the timestamp the
> searcher was opened, so it doesn’t really offer any assurances about your
> data.
> >>
> >>Although you could probably bounce a node and get your document counts
> back in sync (by provoking a check), it’s interesting that you’re in this
> situation. It implies to me that at some point the leader couldn’t write a
> doc to one of the replicas, but that the replica didn’t consider itself
> down enough to check itself.
> >>
> >>You might watch the achieved replication factor of your updates and see
> if it ever changes:
> >>
> https://cwiki.apache.org/confluence/display/solr/Read+and+Write+Side+Fault+Tolerance
> (See Achieved Replication Factor/min_rf)
> >>
> >>If it does, that might give you clues about how this is happening. Also,
> it might allow you to work around the issue by trying the write again.
> >>
> >>
> >>
> >>
> >>
> >>
> >>On 1/22/16, 10:52 AM, "David Smith" 
> wrote:
> >>
> >>>I have a SolrCloud v5.4 collection with 3 replicas that appear to have
> fallen permanently out of sync.  Users started to complain that the same
> search, executed twice, sometimes returned

Re: Which version of java is preferrable to install on a Red Hat Enterprise Linux 7?

[Shawn Heisey]

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 need to install
> full IDK, it is still true or is preferable to install standard JRE as
> for the official documentation
> (https://cwiki.apache.org/confluence/display/solr/Installing+Solr )
>

The full JDK is not required, the JRE is sufficient.

The java version I would personally recommend the most is the latest
version of Oracle Java 8.  Next would be the latest version of OpenJDK
8, followed by the latest version of Oracle Java 7, then the latest
OpenJDK 7.  I am pretty sure that you can easily install openjdk8 with
yum on RHEL7, without adding any extra yum repositories or downloading
anything from Oracle.

Whatever major Java version you choose, you should obtain the latest
update version.  IBM Java should be avoided, because there are known
bugs running under that implementation.

I'm not sure there is an actual official recommendation, but the
*minimum* requirement would be Java 7 Update 1.

Thanks,
Shawn

Re: SolrCloud replicas out of sync

[David Smith]

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 of our three replicas are correct or complete.

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 that requires downtime which is a problem in our app (24/7 High 
Availability with few maintenance windows).


So, I definitely need to “fix” this somehow.  I wish I could outline a 
reproducible test case, but as the root cause is likely very tight timing 
issues and complicated interactions with Zookeeper, that is not really an 
option.  I’m happy to share the full logs of all 3 replicas though if that 
helps.

I am curious though if the thoughts have changed since 
https://issues.apache.org/jira/browse/SOLR-5468 of seriously considering a 
“majority quorum” model, with rollback?  Done properly, this should be free of 
all lost update problems, at the cost of availability.  Some SolrCloud users 
(like us!!!) would gladly accept that tradeoff.  

Regards

David


On 1/26/16, 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 would be an example of a split-brain 
>type incident, where different documents were accepted by different replicas 
>who each thought they were the leader. If this is the case, and you actually 
>have different data on each replica, I’m not aware of any way to fix the 
>problem short of reindexing those documents. Before that, you’ll probably need 
>to choose a replica and just force the others to get in sync with it. I’d 
>choose the current leader, since that’s slightly easier.
>
>Typically, a leader writes an update to it’s transaction log, then sends the 
>request to all replicas, and when those all finish it acknowledges the update. 
>If a replica gets restarted, and is less than N documents behind, the leader 
>will only replay that transaction log. (Where N is the numRecordsToKeep 
>configured in the updateLog section of solrconfig.xml)
>
>What you want is to provoke the heavy-duty process normally invoked if a 
>replica has missed more than N docs, which essentially does a checksum and 
>file copy on all the raw index files. FetchIndex would probably work, but it’s 
>a replication handler API originally designed for master/slave replication, so 
>take care: https://wiki.apache.org/solr/SolrReplication#HTTP_API
>Probably a lot easier would be to just delete the replica and re-create it. 
>That will also trigger a full file copy of the index from the leader onto the 
>new replica.
>
>I think design decisions around Solr generally use CP as a goal. (I sometimes 
>wish I could get more AP behavior!) See posts like this: 
>http://lucidworks.com/blog/2014/12/10/call-maybe-solrcloud-jepsen-flaky-networks/
> 
>So the fact that you encountered this sounds like a bug to me.
>That said, another general recommendation (of mine) is that you not use Solr 
>as your primary data source, so you can rebuild your index from scratch if you 
>really need to. 
>
>
>
>
>
>
>On 1/26/16, 1:10 PM, "David Smith"  wrote:
>
>>Thanks Jeff!  A few comments
>>

 Although you could probably bounce a node and get your document counts 
 back in sync (by provoking a check)

>> 
>>
>>If the check is a simple doc count, that will not work. We have found that 
>>replica1 and replica3, although they contain the same doc count, don’t have 
>>the SAME docs.  They each missed at least one update, but of different docs.  
>>This also means none of our three replicas are complete.
>>

it’s interesting that you’re in this situation. It implies to me that at 
some point the leader couldn’t write a doc to one of the replicas,

>>
>>That is our belief as well. We experienced a datacenter-wide network 
>>disruption of a few seconds, and user complaints started the first workday 
>>after that event.  
>>
>>The most interesting log entry during the outage is this:
>>
>>"1/19/2016, 5:08:07 PM ERROR null DistributedUpdateProcessorRequest says it 
>>is coming from leader,​ but we are the leader: 
>>update.distrib=FROMLEADER&distrib.from=http://dot.dot.dot.dot:8983/solr/blah_blah_shard1_replica3/&wt=javabin&version=2";
>>

 You might watch the achieved replication factor of your updates and see if 
 it ever changes

>>
>>This is a good tip. I’m not sure I like the implication that any failure to 
>>write all 3 of our replicas must be retried at the app layer.  Is this really 
>>how SolrCloud applications must be built to survive network partitions 
>>without data loss? 
>>

Re: SolrCloud replicas out of sync

[Shawn Heisey]

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 that requires downtime which is a problem in our app 
> (24/7 High Availability with few maintenance windows).

I don't have anything to add regarding the initial problem or how you
can prevent it from happening again.  You're already on the latest minor
Solr version (5.4), though I think you could probably upgrade to 5.4.1. 
The list of bugfixes for 5.4.1 does not seem to include anything that
could explain the problem you have described.  There is SOLR-8496, but
that only affects multi-select faceting, not the numDoc counts on the
core summary screen.

For the specific issue mentioned above (rebuilding without downtime),
what I would recommend that you do is build an entirely new collection,
then delete the old one and create an alias to the new collection using
the old collection's name.  Deleting the old collection and making the
alias should happen very quickly.

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 need to ask some people if they think this
is a good documentation addition, and think of a good place to mention
it in the reference guide.

Thanks,
Shawn

Re: Solr cannot return result when query with # * like title:#7654321*

[Erick Erickson]

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 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.
> 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:76543*, it works!
>
>  So I suspect there's a bug in lucene when using query with symbol # and
> *.
>
>  Who had ever met this ?or does anyone can help try it.
>
> Thank you for your help.
>
>
>
>
> --
> View this message in context: 
> http://lucene.472066.n3.nabble.com/Solr-cannot-return-result-when-query-with-like-title-7654321-tp4253541.html
> Sent from the Solr - User mailing list archive at Nabble.com.

Re: migrating solr 4.2.1 to 5.X

[Erick Erickson]

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 point to machine1, but otherwise that's pretty much it.

Now you can freely try it without endangering your production system.

If the indexes are too big, just set up your test machines and index a few (say
10,000 docs) to each _then_ try the upgrade.

Yeah, upgrading is always "interesting", I shudder every time  I have to...

Best,
Erick

On Wed, Jan 27, 2016 at 5:54 AM, Shawn Heisey  wrote:
> 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 how to migrate to solr 5.*.
>> Erick, you say that there is a full backward compatibility between 4.* and
>> 5.* so, for example, we could migrate the slave (and it will continue to
>> read old indexes), then migrate the master (and it could could even update
>> old indexes without need for full reindex). It seems too simple... and I
>> hope it will be so, but my experience of migrations is not so painless as
>> you say...(I'm not referring to SOLR)
>> Is there anyone who tried this approach on a production environment? What I
>> should be more careful of? Is there any incompatibility in REST calls and
>> responses?
>
> Upgrading slaves first and then the master is the recommended way to do
> upgrades in a master/slave installation.  Many people have done upgrades
> in this exact way with success.
>
> I personally would completely rebuild the index once I had the masters
> upgraded, so Solr will perform best.
>
> Thanks,
> Shawn
>

Solrcloud error on finding active nodes.

[Pranaya Behera]

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. And when I saw in solr admin ui: i got  to see the 
collection name as card and pointing to two shards in the radial graph 
but nothing on the graph tab.  Both shards are in leader color.


When I tried to index data to this collection it gave me this error:

Indexing cardERROR StatusLogger No log4j2 configuration file found. 
Using default configuration: logging only errors to the console.
16:49:21.899 [main] ERROR 
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to 
collection card failed due to (510) 
org.apache.solr.common.SolrException: Could not find a healthy node to 
handle the request., retry? 0
16:49:21.911 [main] ERROR 
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to 
collection card failed due to (510) 
org.apache.solr.common.SolrException: Could not find a healthy node to 
handle the request., retry? 1
16:49:21.915 [main] ERROR 
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to 
collection card failed due to (510) 
org.apache.solr.common.SolrException: Could not find a healthy node to 
handle the request., retry? 2
16:49:21.925 [main] ERROR 
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to 
collection card failed due to (510) 
org.apache.solr.common.SolrException: Could not find a healthy node to 
handle the request., retry? 3
16:49:21.928 [main] ERROR 
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to 
collection card failed due to (510) 
org.apache.solr.common.SolrException: Could not find a healthy node to 
handle the request., retry? 4
16:49:21.931 [main] ERROR 
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to 
collection card failed due to (510) 
org.apache.solr.common.SolrException: Could not find a healthy node to 
handle the request., retry? 5
org.apache.solr.common.SolrException: Could not find a healthy node to 
handle the request.
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1085)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:871)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:807)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)

at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:107)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:72)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:86)
at com.igp.solrindex.CardIndex.index(CardIndex.java:75)
at com.igp.solrindex.App.main(App.java:19)


Why I am getting error ?

--
Thanks & Regards
Pranaya Behera

Getting org.apache.lucene.document.Field instead of String in SolrDocument#get

[Thomas Mortagne]

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 all my code dealing with
SolrDocument to be carefull about that ? From what I could see those
Fields are put in SolrDocument by DocsStreamer which seems to be new
in 5.3 but did not digged much more.

It looks a bit weird to me given the javadoc of #getFieldValue which
is implemented exactly like #get. Also it's not consistent with
SolrInstance#query behavior which return me SolrDocument containing
values and not Fields.

Sorry if I missed it in the releases notes.

Thanks for your time !
-- 
Thomas

Re: Add me to the Solr ContributorsGroup

[Saïd Radhouani]

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-05:00 Saïd Radhouani :

> Hi - I'd appreciate if you could add me to the Contributor Group. Here are
> my account info :
>
> - Name: Saïd Radhouani
> - User name: radhouani
> - email: said.radhou...@gmail.com
>
> Thanks,
> -Saïd
>

Re: Add me to the Solr ContributorsGroup

[Erick Erickson]

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 is for you to create
a login.


Best,
Erick

On Wed, Jan 27, 2016 at 8:51 AM, Saïd Radhouani
 wrote:
> 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-05:00 Saïd Radhouani :
>
>> Hi - I'd appreciate if you could add me to the Contributor Group. Here are
>> my account info :
>>
>> - Name: Saïd Radhouani
>> - User name: radhouani
>> - email: said.radhou...@gmail.com
>>
>> Thanks,
>> -Saïd
>>

Re: SolrCloud replicas out of sync

[Jeff Wartes]

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 need to ask some people if they think this
>is a good documentation addition, and think of a good place to mention
>it in the reference guide.


+1 - I recommend this at every opportunity. 

I’ve even considered creating 10 aliases for a single collection and having the 
client select one of the aliases randomly per query. This would allow 
transparently shifting traffic between collections in 10% increments.

Re: SolrCloud replicas out of sync

[Jeff Wartes]

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 of Solr’s assumptions.




On 1/27/16, 7:59 AM, "David Smith"  wrote:

>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 of our three replicas are correct or complete.
>
>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 that requires downtime which is a problem in our app (24/7 High 
>Availability with few maintenance windows).
>
>
>So, I definitely need to “fix” this somehow.  I wish I could outline a 
>reproducible test case, but as the root cause is likely very tight timing 
>issues and complicated interactions with Zookeeper, that is not really an 
>option.  I’m happy to share the full logs of all 3 replicas though if that 
>helps.
>
>I am curious though if the thoughts have changed since 
>https://issues.apache.org/jira/browse/SOLR-5468 of seriously considering a 
>“majority quorum” model, with rollback?  Done properly, this should be free of 
>all lost update problems, at the cost of availability.  Some SolrCloud users 
>(like us!!!) would gladly accept that tradeoff.  
>
>Regards
>
>David
>
>

Re: SolrCloud replicas out of sync

[David Smith]

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 responsiveness of ZK to the stability of SolrCloud as a 
whole.

   + 364 collections, all with single shards and a replication factor of 3.  
Currently housing only 100,000,000 documents in aggregate.  Expected to grow to 
25 billion+.  The size of a single document would be considered “large”, by the 
standards of what I’ve seen posted elsewhere on this mailing list. 

We are always open to ZK recommendations from you or anyone else, particularly 
for running a SolrCloud cluster of this size.

Kind Regards,

David



On 1/27/16, 12:46 PM, "Jeff Wartes"  wrote:

>
>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 of Solr’s assumptions.
>
>
>
>
>On 1/27/16, 7:59 AM, "David Smith"  wrote:
>
>>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 of our three replicas are correct or complete.
>>
>>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 that requires downtime which is a problem in our app 
>>(24/7 High Availability with few maintenance windows).
>>
>>
>>So, I definitely need to “fix” this somehow.  I wish I could outline a 
>>reproducible test case, but as the root cause is likely very tight timing 
>>issues and complicated interactions with Zookeeper, that is not really an 
>>option.  I’m happy to share the full logs of all 3 replicas though if that 
>>helps.
>>
>>I am curious though if the thoughts have changed since 
>>https://issues.apache.org/jira/browse/SOLR-5468 of seriously considering a 
>>“majority quorum” model, with rollback?  Done properly, this should be free 
>>of all lost update problems, at the cost of availability.  Some SolrCloud 
>>users (like us!!!) would gladly accept that tradeoff.  
>>
>>Regards
>>
>>David
>>
>>

Re: Solr partial date range search

[vsriram30]

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
way I can make it work in 4.6.1 without need of my custom component.

Thanks,
Sriram



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Solr-partial-date-range-search-tp4253226p4253649.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Solrcloud error on finding active nodes.

[Susheel Kumar]

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 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. And when I saw in solr admin ui: i got  to see the
> collection name as card and pointing to two shards in the radial graph but
> nothing on the graph tab.  Both shards are in leader color.
>
> When I tried to index data to this collection it gave me this error:
>
> Indexing cardERROR StatusLogger No log4j2 configuration file found.
> Using default configuration: logging only errors to the console.
> 16:49:21.899 [main] ERROR
> org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
> card failed due to (510) org.apache.solr.common.SolrException: Could not
> find a healthy node to handle the request., retry? 0
> 16:49:21.911 [main] ERROR
> org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
> card failed due to (510) org.apache.solr.common.SolrException: Could not
> find a healthy node to handle the request., retry? 1
> 16:49:21.915 [main] ERROR
> org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
> card failed due to (510) org.apache.solr.common.SolrException: Could not
> find a healthy node to handle the request., retry? 2
> 16:49:21.925 [main] ERROR
> org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
> card failed due to (510) org.apache.solr.common.SolrException: Could not
> find a healthy node to handle the request., retry? 3
> 16:49:21.928 [main] ERROR
> org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
> card failed due to (510) org.apache.solr.common.SolrException: Could not
> find a healthy node to handle the request., retry? 4
> 16:49:21.931 [main] ERROR
> org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
> card failed due to (510) org.apache.solr.common.SolrException: Could not
> find a healthy node to handle the request., retry? 5
> org.apache.solr.common.SolrException: Could not find a healthy node to
> handle the request.
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1085)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:871)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:807)
> at
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
> at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:107)
> at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:72)
> at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:86)
> at com.igp.solrindex.CardIndex.index(CardIndex.java:75)
> at com.igp.solrindex.App.main(App.java:19)
>
>
> Why I am getting error ?
>
> --
> Thanks & Regards
> Pranaya Behera
>
>

Re: Solr cannot return result when query with # * like title:#7654321*

[diyun2008]

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 I was rather confused is if they all hit same string "7654321", why
it cannot return the hit result by query(q=#7654321*)? 

BTW, The title type is "text_general" and it uses Standard Tokenizer.  



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Solr-cannot-return-result-when-query-with-like-title-7654321-tp4253541p4253727.html
Sent from the Solr - User mailing list archive at Nabble.com.

Is Solr cache cleared when I restart Solr?

[Zheng Lin Edwin Yeo]

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 than the initial search. However, when I
do a search on a new query, the return QTime is the original speed.

I am using Solr 5.4.0, and this is my setting for the queryResultCache.



Regards,
Edwin

Re: Solr cannot return result when query with # * like title:#7654321*

[Yonik Seeley]

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.SyntaxError: Cannot parse 'id:':
Encountered \"\" at line 1, column 3.\nWas expecting one of:\n
 ...\n\"(\" ...\n\"*\" ...\n ...\n
 ...\n ...\n ...\n
...\n\"[\" ...\n\"{\" ...\n ...\n\"filter(\"
...\n ...\n",
"code":400}}


Look at the echoed params, and how they were cut off at the "#" which
is special for URLs (and needs to be URL encoded).
Whether *you* need to URL encode it depends on exactly how you are
sending the request to Solr.  With a browser or with curl, you will
need to do it yourself... but other types of clients like SolrJ should
do it for you.

-Yonik


On Wed, Jan 27, 2016 at 10:00 PM, diyun2008  wrote:
> 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 I was rather confused is if they all hit same string "7654321", why
> it cannot return the hit result by query(q=#7654321*)?
>
> BTW, The title type is "text_general" and it uses Standard Tokenizer.

Re: Solr cannot return result when query with # * like title:#7654321*

[diyun2008]

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 "7654321" as well.

What I was rather confused is if they all hit same string "7654321", why
it cannot return the hit result by query(q=#7654321*)?

   



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Solr-cannot-return-result-when-query-with-like-title-7654321-tp4253541p4253733.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Solr cannot return result when query with # * like title:#7654321*

[diyun2008]

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 archive at Nabble.com.

Re: Solr cannot return result when query with # * like title:#7654321*

[Yonik Seeley]

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.

-Yonik

Re: Solr cannot return result when query with # * like title:#7654321*

[Jack Krupansky]

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:%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.
>
> -Yonik
>

Re: Is Solr cache cleared when I restart Solr?

[Erick Erickson]

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, Jan 27, 2016 at 7:11 PM, Zheng Lin Edwin Yeo
 wrote:
> 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 than the initial search. However, when I
> do a search on a new query, the return QTime is the original speed.
>
> I am using Solr 5.4.0, and this is my setting for the queryResultCache.
>
>   size="1024"
>  initialSize="512"
>  autowarmCount="0"/>
>
> Regards,
> Edwin

Re: Solrcloud error on finding active nodes.

[Pranaya Behera]

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 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 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. And when I saw in solr admin ui: i got  to see the
collection name as card and pointing to two shards in the radial graph but
nothing on the graph tab.  Both shards are in leader color.

When I tried to index data to this collection it gave me this error:

Indexing cardERROR StatusLogger No log4j2 configuration file found.
Using default configuration: logging only errors to the console.
16:49:21.899 [main] ERROR
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
card failed due to (510) org.apache.solr.common.SolrException: Could not
find a healthy node to handle the request., retry? 0
16:49:21.911 [main] ERROR
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
card failed due to (510) org.apache.solr.common.SolrException: Could not
find a healthy node to handle the request., retry? 1
16:49:21.915 [main] ERROR
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
card failed due to (510) org.apache.solr.common.SolrException: Could not
find a healthy node to handle the request., retry? 2
16:49:21.925 [main] ERROR
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
card failed due to (510) org.apache.solr.common.SolrException: Could not
find a healthy node to handle the request., retry? 3
16:49:21.928 [main] ERROR
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
card failed due to (510) org.apache.solr.common.SolrException: Could not
find a healthy node to handle the request., retry? 4
16:49:21.931 [main] ERROR
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
card failed due to (510) org.apache.solr.common.SolrException: Could not
find a healthy node to handle the request., retry? 5
org.apache.solr.common.SolrException: Could not find a healthy node to
handle the request.
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1085)
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:871)
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:807)
 at
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
 at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:107)
 at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:72)
 at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:86)
 at com.igp.solrindex.CardIndex.index(CardIndex.java:75)
 at com.igp.solrindex.App.main(App.java:19)


Why I am getting error ?

--
Thanks & Regards
Pranaya Behera




--
Thanks & Regards
Pranaya Behera

Re: Is Solr cache cleared when I restart Solr?

[Shawn Heisey]

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 search, it still has a
> return QTime that is much faster than the initial search. However, when I
> do a search on a new query, the return QTime is the original speed.
>
> I am using Solr 5.4.0, and this is my setting for the queryResultCache.
>
>   size="1024"
>  initialSize="512"
>  autowarmCount="0"/>

The Solr caches are maintained in the Java heap, which is lost when Java
stops.

Although the Solr caches are not preserved across a restart, the
operating system does cache actual index data in main memory, so when
Solr asks for the same index data off of the disk again, it is pulled
directly from RAM, which is a LOT faster than the disk.  In order to
deliver good performance, Solr is extremely reliant on this built-in
feature of all modern operating systems, so there must be enough spare
memory for good caching.

Here are a couple of pages with some more detail:

https://wiki.apache.org/solr/SolrPerformanceProblems
https://en.wikipedia.org/wiki/Page_cache

Thanks,
Shawn

Re: Solr cannot return result when query with # * like title:#7654321*

[Shawn Heisey]

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 case, but it is how
Lucene behaves.

If the # character is correctly encoded (which it appears to be, based
on subsequent messages), it will still be in the query when wildcards
are present, and will not match what is indexed.

Thanks,
Shawn

PLease Unsubscribe Me. Thanks

[jon1736]

Re: Is Solr cache cleared when I restart Solr?

[Zheng Lin Edwin Yeo]

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 enough spare
memory for good caching?

Regards,
Edwin


On 28 January 2016 at 12:27, Shawn Heisey  wrote:

> 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 search, it still
> has a
> > return QTime that is much faster than the initial search. However, when I
> > do a search on a new query, the return QTime is the original speed.
> >
> > I am using Solr 5.4.0, and this is my setting for the queryResultCache.
> >
> >  >  size="1024"
> >  initialSize="512"
> >  autowarmCount="0"/>
>
> The Solr caches are maintained in the Java heap, which is lost when Java
> stops.
>
> Although the Solr caches are not preserved across a restart, the
> operating system does cache actual index data in main memory, so when
> Solr asks for the same index data off of the disk again, it is pulled
> directly from RAM, which is a LOT faster than the disk.  In order to
> deliver good performance, Solr is extremely reliant on this built-in
> feature of all modern operating systems, so there must be enough spare
> memory for good caching.
>
> Here are a couple of pages with some more detail:
>
> https://wiki.apache.org/solr/SolrPerformanceProblems
> https://en.wikipedia.org/wiki/Page_cache
>
> Thanks,
> Shawn
>
>

Re: Solr cannot return result when query with # * like title:#7654321*

[diyun2008]

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 Nabble.com.

Re: Solr partial date range search

[Jeyaprakash Singarayar]

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 written.

Its available in all 4.X versions.

Hope it helps.

On Thu, Jan 28, 2016 at 1:41 AM, vsriram30  wrote:

> 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
> way I can make it work in 4.6.1 without need of my custom component.
>
> Thanks,
> Sriram
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Solr-partial-date-range-search-tp4253226p4253649.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>

Re: Solr partial date range search

[Jeyaprakash Singarayar]

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 written.

Its available in all 4.X versions.

Hope it helps.

On Thu, Jan 28, 2016 at 1:41 AM, vsriram30  wrote:

> 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
> way I can make it work in 4.6.1 without need of my custom component.
>
> Thanks,
> Sriram
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Solr-partial-date-range-search-tp4253226p4253649.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>

Re: Solr cannot return result when query with # * like title:#7654321*

[diyun2008]

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).

Thanks




--
View this message in context: 
http://lucene.472066.n3.nabble.com/Solr-cannot-return-result-when-query-with-like-title-7654321-tp4253541p4253763.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Solr cannot return result when query with # * like title:#7654321*

[Shawn Heisey]

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
> result as well.(But it does return hit result).

When the query does NOT have a wildcard, the defined query analysis on
the field is used.  The query analysis for this particular field
includes a tokenizer or a filter that strips # characters, so the query
matches.

When the query DOES have a wildcard (* or ? characters), any defined
query analysis is completely skipped, so the # character is not stripped
from the query.  It will not match what's in the index.

The example of q=title:7654321* matches because it does not contain the
# character.

Thanks,
Shawn

Re: Solr cannot return result when query with # * like title:#7654321*

[diyun2008]

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: 
http://lucene.472066.n3.nabble.com/Solr-cannot-return-result-when-query-with-like-title-7654321-tp4253541p4253769.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Solrcloud error on finding active nodes.

[Pranaya Behera]

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-d554", "state":"active", "replicas":{}}, 
"shard2":{ "range":"d555-2aa9", "state":"active", 
"replicas":{}}, "shard3":{ "range":"2aaa-7fff", 
"state":"active", "replicas":{} There is no replica. How is this 
possible? This is what I used to create the collection: curl 
"http://localhost:8983/solr/admin/collections?action=CREATE&name=card&numShards=3&replicationFactor=2&maxShardsPerNode=1&createNodeSet=localhost:8983_solr,localhost:8984_solr,localhost:8985_solr&createNodeSet.shuffle=true&collection.configName=igp"; 





On Thursday 28 January 2016 03:16 AM, Susheel Kumar wrote:

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 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. And when I saw in solr admin ui: i got  to see the
collection name as card and pointing to two shards in the radial graph but
nothing on the graph tab.  Both shards are in leader color.

When I tried to index data to this collection it gave me this error:

Indexing cardERROR StatusLogger No log4j2 configuration file found.
Using default configuration: logging only errors to the console.
16:49:21.899 [main] ERROR
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
card failed due to (510) org.apache.solr.common.SolrException: Could not
find a healthy node to handle the request., retry? 0
16:49:21.911 [main] ERROR
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
card failed due to (510) org.apache.solr.common.SolrException: Could not
find a healthy node to handle the request., retry? 1
16:49:21.915 [main] ERROR
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
card failed due to (510) org.apache.solr.common.SolrException: Could not
find a healthy node to handle the request., retry? 2
16:49:21.925 [main] ERROR
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
card failed due to (510) org.apache.solr.common.SolrException: Could not
find a healthy node to handle the request., retry? 3
16:49:21.928 [main] ERROR
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
card failed due to (510) org.apache.solr.common.SolrException: Could not
find a healthy node to handle the request., retry? 4
16:49:21.931 [main] ERROR
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
card failed due to (510) org.apache.solr.common.SolrException: Could not
find a healthy node to handle the request., retry? 5
org.apache.solr.common.SolrException: Could not find a healthy node to
handle the request.
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1085)
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:871)
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:807)
 at
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
 at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:107)
 at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:72)
 at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:86)
 at com.igp.solrindex.CardIndex.index(CardIndex.java:75)
 at com.igp.solrindex.App.main(App.java:19)


Why I am getting error ?

--
Thanks & Regards
Pranaya Behera




--
Thanks & Regards
Pranaya Behera

Re: Solrcloud error on finding active nodes.

[Pranaya Behera]

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 shard per node. This is what I get:
{"card":{ "replicationFactor":"2", "router":{"name":"compositeId"}, 
"maxShardsPerNode":"1", "autoAddReplicas":"false", "shards":{ 
"shard1":{ "range":"8000-d554", "state":"active", 
"replicas":{}}, "shard2":{ "range":"d555-2aa9", 
"state":"active", "replicas":{}}, "shard3":{ 
"range":"2aaa-7fff", "state":"active", "replicas":{} There 
is no replica. How is this possible? This is what I used to create the 
collection: curl 
"http://localhost:8983/solr/admin/collections?action=CREATE&name=card&numShards=3&replicationFactor=2&maxShardsPerNode=1&createNodeSet=localhost:8983_solr,localhost:8984_solr,localhost:8985_solr&createNodeSet.shuffle=true&collection.configName=igp"; 




On Thursday 28 January 2016 03:16 AM, Susheel Kumar wrote:

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 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. And when I saw in solr admin ui: i got  to see the
collection name as card and pointing to two shards in the radial graph but
nothing on the graph tab.  Both shards are in leader color.

When I tried to index data to this collection it gave me this error:

Indexing cardERROR StatusLogger No log4j2 configuration file found.
Using default configuration: logging only errors to the console.
16:49:21.899 [main] ERROR
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
card failed due to (510) org.apache.solr.common.SolrException: Could not
find a healthy node to handle the request., retry? 0
16:49:21.911 [main] ERROR
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
card failed due to (510) org.apache.solr.common.SolrException: Could not
find a healthy node to handle the request., retry? 1
16:49:21.915 [main] ERROR
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
card failed due to (510) org.apache.solr.common.SolrException: Could not
find a healthy node to handle the request., retry? 2
16:49:21.925 [main] ERROR
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
card failed due to (510) org.apache.solr.common.SolrException: Could not
find a healthy node to handle the request., retry? 3
16:49:21.928 [main] ERROR
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
card failed due to (510) org.apache.solr.common.SolrException: Could not
find a healthy node to handle the request., retry? 4
16:49:21.931 [main] ERROR
org.apache.solr.client.solrj.impl.CloudSolrClient - Request to collection
card failed due to (510) org.apache.solr.common.SolrException: Could not
find a healthy node to handle the request., retry? 5
org.apache.solr.common.SolrException: Could not find a healthy node to
handle the request.
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1085)
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:871)
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:954)
 at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:807)
 at
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
 at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:107)
 at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:72)
 at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:86)
 at com.igp.solrindex.CardIndex.index(CardIndex.java:75)
 at com.igp.solrindex.App.main(App.java:19)


Why I am getting error ?

--
Thanks & Regards
Pranaya Behera




--
Thanks & Regards
Pranaya Behera


--
Thanks & Regards
Pranaya Behera