Re: How can I set the defaultOperator to be AND?

[Bastien Latard - MDPI AG]

Thank you Shawn, Jan and Georg for your answers.

Yes, it seems that if I simply remove the defaultOperator it works well 
for "composed queries" like '(a:x AND b:y) OR c:z'.

But I think that the default Operator should/could be the AND.

Because when I add an extra search word, I expect that the results get 
more accurate...

(It seems to be what google is also doing now)
   ||

Otherwise, if you make a search and apply another filter (e.g.: sort by 
publication date, facets, ...) , user can get the less relevant item 
(only 1 word in 4 matches) in first position only because of its date...


What do you think?


Kind regards,
Bastien


On 25/04/2016 14:53, Shawn Heisey wrote:

On 4/25/2016 6:39 AM, Bastien Latard - MDPI AG wrote:

Remember:
If I add the following line to the schema.xml, even if I do a search
'title:"test" OR author:"me"', it will returns documents matching
'title:"test" AND author:"me"':


The settings in the schema for default field and default operator were
deprecated a long time ago.  I actually have no idea whether they are
even supported in newer Solr versions.

The q.op parameter controls the default operator, and the df parameter
controls the default field.  These can be set in the request handler
definition in solrconfig.xml -- usually in "defaults" but there might be
reason to put them in "invariants" instead.

If you're using edismax, you'd be better off using the mm parameter
rather than the q.op parameter.  The behavior you have described above
sounds like a change in behavior (some call it a bug) introduced in the
5.5 version:

https://issues.apache.org/jira/browse/SOLR-8812

If you are using edismax, I suspect that if you set mm=100% instead of
q.op=AND (or the schema default operator) that the problem might go away
... but I am not sure.  Someone who is more familiar with SOLR-8812
probably should comment.

Thanks,
Shawn




Kind regards,
Bastien Latard
Web engineer
--
MDPI AG
Postfach, CH-4005 Basel, Switzerland
Office: Klybeckstrasse 64, CH-4057
Tel. +41 61 683 77 35
Fax: +41 61 302 89 18
E-mail:
lat...@mdpi.com
http://www.mdpi.com/

Re: measuring query performance & qps per node

[Jay Potharaju]

Thanks for the response Erick. I knew that it would depend on the number of
factors like you mentioned.I just wanted to know whether a  good
combination of queries, facets & filters should be a good estimate of how
solr might behave.

what did you mean by "Add stats to pivots in Cloud mode."

Thanks

On Mon, Apr 25, 2016 at 5:05 PM, Erick Erickson 
wrote:

>  Impossible to answer. For instance, a facet query can be very
> heavy-duty. Add stats
> to pivots in Cloud mode.
>
> As for using a bunch of fq clauses, It Depends (tm). If your expected usage
> pattern is all queries like 'q=*:*&fq=clause1&fq=clause2" then it's
> fine. It totally
> falls down if, for instance, you have a bunch of facets. Or grouping.
> Or.
>
> Best,
> Erick
>
> On Mon, Apr 25, 2016 at 3:48 PM, Jay Potharaju 
> wrote:
> > Hi,
> > I am trying to measure how will are queries performing ie how long are
> they
> > taking. In order to measure query speed I am using solrmeter with 50k
> > unique filter queries. And then checking if any of the queries are slower
> > than 50ms. Is this a good approach to measure query performance?
> >
> > Are there any guidelines on how to measure if a given instance can
> handle a
> > given number of qps(query per sec)? For example if my doc size is 30
> > million docs and index size is 40 GB of data and the RAM on the instance
> is
> > 60 GB, then how many qps can it handle? Or is this a hard question to
> > answer and it depends on the load and type of query running at a given
> time.
> >
> > --
> > Thanks
> > Jay
>



-- 
Thanks
Jay Potharaju

Re: regarding filter on spell checker

[Reth RM]

Could you please the requirement with an example? Its not clear as to what
you mean by index property.

On Tue, Apr 26, 2016 at 8:54 AM, Adrita G  wrote:

> Hi
>
>I want to whether we can apply any filters on spell checker.My
> requirement is like that I need to filter the suggestions based on one
> indexed property.I am trying to trying to filter queries,but the result is
> not getting filtered.Please help on this.
>
>
> Thaks & regards
> Adrita Goswami
> Tata Consultancy Services
> MARG Square No 16,
> Rajiv Gandhi Salai(IT Express Way),
> Karapakkam,
> Chennai - 600097,Tamilnadu
> India
> Ph:-   919874168068
> Mailto: adrit...@tcs.com
> Website: http://www.tcs.com
> 
> Experience certainty.   IT Services
> Business Solutions
> Consulting
> 
> =-=-=
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>

regarding filter on spell checker

[Adrita G]

Hi 

       I want to whether we can apply any filters on spell checker.My 
requirement is like that I need to filter the suggestions based on one indexed 
property.I am trying to trying to filter queries,but the result is not getting 
filtered.Please help on this.


Thaks & regards
Adrita Goswami
Tata Consultancy Services
MARG Square No 16,
Rajiv Gandhi Salai(IT Express Way),
Karapakkam,
Chennai - 600097,Tamilnadu
India
Ph:-   919874168068
Mailto: adrit...@tcs.com
Website: http://www.tcs.com

Experience certainty.   IT Services
Business Solutions
Consulting

=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

Re: measuring query performance & qps per node

[Erick Erickson]

 Impossible to answer. For instance, a facet query can be very
heavy-duty. Add stats
to pivots in Cloud mode.

As for using a bunch of fq clauses, It Depends (tm). If your expected usage
pattern is all queries like 'q=*:*&fq=clause1&fq=clause2" then it's
fine. It totally
falls down if, for instance, you have a bunch of facets. Or grouping. Or.

Best,
Erick

On Mon, Apr 25, 2016 at 3:48 PM, Jay Potharaju  wrote:
> Hi,
> I am trying to measure how will are queries performing ie how long are they
> taking. In order to measure query speed I am using solrmeter with 50k
> unique filter queries. And then checking if any of the queries are slower
> than 50ms. Is this a good approach to measure query performance?
>
> Are there any guidelines on how to measure if a given instance can handle a
> given number of qps(query per sec)? For example if my doc size is 30
> million docs and index size is 40 GB of data and the RAM on the instance is
> 60 GB, then how many qps can it handle? Or is this a hard question to
> answer and it depends on the load and type of query running at a given time.
>
> --
> Thanks
> Jay

measuring query performance & qps per node

[Jay Potharaju]

Hi,
I am trying to measure how will are queries performing ie how long are they
taking. In order to measure query speed I am using solrmeter with 50k
unique filter queries. And then checking if any of the queries are slower
than 50ms. Is this a good approach to measure query performance?

Are there any guidelines on how to measure if a given instance can handle a
given number of qps(query per sec)? For example if my doc size is 30
million docs and index size is 40 GB of data and the RAM on the instance is
60 GB, then how many qps can it handle? Or is this a hard question to
answer and it depends on the load and type of query running at a given time.

-- 
Thanks
Jay

Re: Replicas for same shard not in sync

[Erick Erickson]

Ted:
Yes, deleting and re-adding the replica will be fine.

Having commits happen from the client when you _also_ have
autocommits that frequently (10 seconds and 1 second are pretty
aggressive BTW) is usually not recommended or necessary.

David:

bq: if one or more replicas are down, updates presented to the leader
still succeed, right?  If so, tedsolr is correct that the Solr client
app needs to re-issue update

Absolutely not the case. When the replicas are down, they're marked as
down by Zookeeper. When then come back up they find the leader through
Zookeeper magic and ask, essentially "Did I miss any updates"? If the
replica did miss any updates it gets them from the leader either
through the leader replaying the updates from its transaction log to
the replica or by replicating the entire index from the leader. Which
path is followed is a function of how far behind the replica is.

In this latter case, any updates that come in to the leader while the
replication is happening are buffered and replayed on top of the index
when the full replication finishes.

The net-net here is that you should not have to track whether updates
got to all the replicas or not. One of the major advantages of
SolrCloud is to remove that worry from the indexing client...

Best,
Erick

On Mon, Apr 25, 2016 at 11:39 AM, David Smith
 wrote:
> Erick,
>
> So that my understanding is correct, let me ask, if one or more replicas are 
> down, updates presented to the leader still succeed, right?  If so, tedsolr 
> is correct that the Solr client app needs to re-issue updates, if it wants 
> stronger guarantees on replica consistency than what Solr provides.
>
> The “Write Fault Tolerance” section of the Solr Wiki makes what I believe is 
> the same point:
>
> "On the client side, if the achieved replication factor is less than the 
> acceptable level, then the client application can take additional measures to 
> handle the degraded state. For instance, a client application may want to 
> keep a log of which update requests were sent while the state of the 
> collection was degraded and then resend the updates once the problem has been 
> resolved."
>
>
> https://cwiki.apache.org/confluence/display/solr/Read+and+Write+Side+Fault+Tolerance
>
>
> Kind Regards,
>
> David
>
>
>
>
> On 4/25/16, 11:57 AM, "Erick Erickson"  wrote:
>
>>bq: I also read that it's up to the
>>client to keep track of updates in case commits don't happen on all the
>>replicas.
>>
>>This is not true. Or if it is it's a bug.
>>
>>The update cycle is this:
>>1> updates get to the leader
>>2> updates are sent to all followers and indexed on the leader as well
>>3> each replica writes the updates to the local transaction log
>>4> all the replicas ack back to the leader
>>5> the leader responds to the client.
>>
>>At this point, all the replicas for the shard have the docs locally
>>and can take over as leader.
>>
>>You may be confusing indexing in batches and having errors with
>>updates getting to replicas. When you send a batch of docs to Solr,
>>if one of them fails indexing some of the rest of the docs may not
>>be indexed. See SOLR-445 for some work on this front.
>>
>>That said, bouncing servers willy-nilly during heavy indexing, especially
>>if the indexer doesn't know enough to retry if an indexing attempt fails may
>>be the root cause here. Have you verified that your indexing program
>>retries in the event of failure?
>>
>>Best,
>>Erick
>>
>>On Mon, Apr 25, 2016 at 6:13 AM, tedsolr  wrote:
>>> I've done a bit of reading - found some other posts with similar questions.
>>> So I gather "Optimizing" a collection is rarely a good idea. It does not
>>> need to be condensed to a single segment. I also read that it's up to the
>>> client to keep track of updates in case commits don't happen on all the
>>> replicas. Solr will commit and return success as long as one replica gets
>>> the update.
>>>
>>> I have a state where the two replicas for one collection are out of sync.
>>> One has some updates that the other does not. And I don't have log data to
>>> tell me what the differences are. This happened during a maintenance window
>>> when the servers got restarted while a large index job was running. Normally
>>> this doesn't cause a problem, but it did last Thursday.
>>>
>>> What I plan to do is select the replica I believe is incomplete and delete
>>> it. Then add a new one. I was just hoping Solr had a solution for this -
>>> maybe using the ZK transaction logs to replay some updates, or force a
>>> resync between the replicas.
>>>
>>> I will also implement a fix to prevent Solr from restarting unless one of
>>> its config files has changed. No need to bounce Solr just for kicks.
>>>
>>>
>>>
>>> --
>>> View this message in context: 
>>> http://lucene.472066.n3.nabble.com/Replicas-for-same-shard-not-in-sync-tp4272236p4272602.html
>>> Sent from the Solr - User mailing list archive at Nabble.com.
>

Re: Replicas for same shard not in sync

[David Smith]

Erick,

So that my understanding is correct, let me ask, if one or more replicas are 
down, updates presented to the leader still succeed, right?  If so, tedsolr is 
correct that the Solr client app needs to re-issue updates, if it wants 
stronger guarantees on replica consistency than what Solr provides.

The “Write Fault Tolerance” section of the Solr Wiki makes what I believe is 
the same point:

"On the client side, if the achieved replication factor is less than the 
acceptable level, then the client application can take additional measures to 
handle the degraded state. For instance, a client application may want to keep 
a log of which update requests were sent while the state of the collection was 
degraded and then resend the updates once the problem has been resolved."


https://cwiki.apache.org/confluence/display/solr/Read+and+Write+Side+Fault+Tolerance


Kind Regards,

David




On 4/25/16, 11:57 AM, "Erick Erickson"  wrote:

>bq: I also read that it's up to the
>client to keep track of updates in case commits don't happen on all the
>replicas.
>
>This is not true. Or if it is it's a bug.
>
>The update cycle is this:
>1> updates get to the leader
>2> updates are sent to all followers and indexed on the leader as well
>3> each replica writes the updates to the local transaction log
>4> all the replicas ack back to the leader
>5> the leader responds to the client.
>
>At this point, all the replicas for the shard have the docs locally
>and can take over as leader.
>
>You may be confusing indexing in batches and having errors with
>updates getting to replicas. When you send a batch of docs to Solr,
>if one of them fails indexing some of the rest of the docs may not
>be indexed. See SOLR-445 for some work on this front.
>
>That said, bouncing servers willy-nilly during heavy indexing, especially
>if the indexer doesn't know enough to retry if an indexing attempt fails may
>be the root cause here. Have you verified that your indexing program
>retries in the event of failure?
>
>Best,
>Erick
>
>On Mon, Apr 25, 2016 at 6:13 AM, tedsolr  wrote:
>> I've done a bit of reading - found some other posts with similar questions.
>> So I gather "Optimizing" a collection is rarely a good idea. It does not
>> need to be condensed to a single segment. I also read that it's up to the
>> client to keep track of updates in case commits don't happen on all the
>> replicas. Solr will commit and return success as long as one replica gets
>> the update.
>>
>> I have a state where the two replicas for one collection are out of sync.
>> One has some updates that the other does not. And I don't have log data to
>> tell me what the differences are. This happened during a maintenance window
>> when the servers got restarted while a large index job was running. Normally
>> this doesn't cause a problem, but it did last Thursday.
>>
>> What I plan to do is select the replica I believe is incomplete and delete
>> it. Then add a new one. I was just hoping Solr had a solution for this -
>> maybe using the ZK transaction logs to replay some updates, or force a
>> resync between the replicas.
>>
>> I will also implement a fix to prevent Solr from restarting unless one of
>> its config files has changed. No need to bounce Solr just for kicks.
>>
>>
>>
>> --
>> View this message in context: 
>> http://lucene.472066.n3.nabble.com/Replicas-for-same-shard-not-in-sync-tp4272236p4272602.html
>> Sent from the Solr - User mailing list archive at Nabble.com.

Re: Getting duplicate output while doing auto suggestion based on multiple filed using copy filed in solr 5.5

[Tejas Bhanushali]

Hi Team ,

Please follow the below steps to reproduce this issue.for that  you to
change the existing config file under the
directory solr-5.5.0\server\solr\configsets\sample_techproducts_configs\conf
.

Note:- if you see the config i have used the "AnalyzingInfixLookupFactory"
instead of "FuzzyLookupFactory" for infix search .

Step 1:- First replace the existing "Suggest" component in solrconfig.xml
as mention below.

  

  mySuggester
 
   AnalyzingInfixLookupFactory
  suggester_infix_dir
   DocumentDictionaryFactory
  suggest_text
   price
  text_auto
  text_auto
  false
   false

  

  

  true
  10
  
  true
   true


  suggest

  

Step2:- Add new field  into managed-schema for auto suggetion .



Step3:- i have provided suggestion  based on multiple fields i.e. on
cat,name and manu




Step4:- add below field type into solrconfig.xml. please note that i have
used NgramTokenizer to provide suggetion based on user type character into
search box.
   eg. suppose user type "compu" then it should get suggetion like
 "electronics and computer1"













Step 5:- run the solr by using existing techproducts example
bin\solr -e techproducts

Step5:- Run the below command to build the schema
curl "http://localhost:8983/solr/techproducts/suggest?suggest.dic
tionary=mySuggester&suggest=true&suggest.build=true&wt=json"

Step6:- finally run the url like:-
curl "http://localhost:8983/solr/techproducts/suggest?wt=json&ind
ent=true&suggest.dictionary=mySuggester&suggest=true&avoidDuplicate=0&suggest.q=
electro"

Step 7:- you will get below response:-

{
  "responseHeader":{
"status":0,
"QTime":15},
  "suggest":{"mySuggester":{
  "elec":{
"numFound":10,
"suggestions":[{
"term":"electronics and computer1",
"weight":2199,
"payload":""},
  {
"term":"electronics",
"weight":649,
"payload":""},
  {
"term":"electronics",
"weight":479,
"payload":""},
  {
"term":"electronics",
"weight":399,
"payload":""},
  {
"term":"electronics",
"weight":350,
"payload":""},
  {
"term":"electronics",
"weight":329,
"payload":""},
  {
"term":"electronics and stuff2",
"weight":279,
"payload":""},
  {
"term":"electronics",
"weight":185,
"payload":""},
  {
"term":"electronics",
"weight":179,
"payload":""},
  {
"term":"Samsung Electronics Co. Ltd.",
"weight":92,
"payload":""}]

if you see the response then you will find the word "electronics" getting
repeating by 7 times.

PFA file for your reference if you unable to config as i mention above.

Please advice how to resolve this issue .

Thanks & Regards,
Tejas

On Mon, Apr 18, 2016 at 11:12 PM, Tejas Bhanushali <
contact.tejasbhanush...@gmail.com> wrote:

> HI Team,
>
> I tried to run the same example as suggested by Chris Hostetter and i get
> to know it's working fine for single field, but my requirement is it should
> suggest based on multiple fields .i.e not only on "cat" field but it should
> suggest based on few other fields like 'name','manu' etc. and due to
> fuzzylookupfactory it's give suggestion based on starting characters, not
> if users type any middle character of phrase eg. i tried with searching by
> 'stuff2' of 'electronics and stuff2' cat .
>
> curl 'http://localhost:8983/solr/techproducts/suggest?wt=json&ind
> ent=true&suggest.dictionary=mySuggester&suggest=true&suggest.q=stuff'
> {
>   "responseHeader":{
> "status":0,
> "QTime":2},
>   "suggest":{"mySuggester":{
>   "stuff":{
> "numFound":0,
> "suggestions":[]
>
> On Fri, Apr 15, 2016 at 11:18 PM, Tejas Bhanushali <
> contact.tejasbhanush...@gmail.com> wrote:
>
>> Hi Team,
>>
>> Im getting the duplicate result when i do auto suggestion based on
>> multiple filed by using copy filed . i have below table configuration .
>>
>> Segment -- have multiple category -- have multiple sub category -- have
>> multiple products.
>>
>> suggestion are given based on
>> segment name, category name, sub category name and product name.
>>
>> below is output .
>>
>> ---
>>
>> {
>>   "responseHeader": {
>> "status": 0,
>> "QTime": 1375
>>   },
>>   "command": "build",
>>   "suggest": {
>> "mySuggester": {
>>   "Fruit": {
>> "numFound": 10,
>> "suggestions": [
>>   {
>> "term": "Fruits & Vegetables",
>> "weight": 1000,
>> "payload": ""
>>   },
>>   {
>> "term": "Fruits & Vegetables",
>> "weight": 1000,
>> "payload": ""
>>   }

Re: Replicas for same shard not in sync

[tedsolr]

Erick,

I was referring to the Achieved Replication Factor section of the  Solr
reference guide

  
Maybe I'm misreading it. If an update succeeds on the leader but fails on
the replica, it's a success for the client - the replica should get updated
when its on line again later. For whatever reason one or more updates never
got synced - certainly the root cause was the server being bounced.

I don't retry failed attempts because the app is supposed to record a
failure so it can be rerun later. I may need to revisit my error handling.

In my case updates are made in batches of up to 5000 docs. An explicit
commit is issued at logical completion locations between batches that may be
after just one doc, or 2. Auto commit is at 10 seconds, and auto soft
commit 1 second.

But to fix the current situation, deleting a replica is the way to go? It
happens to be very small - lucky me.



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Replicas-for-same-shard-not-in-sync-tp4272236p4272721.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: ConcurrentUpdateSolrClient Invalid version (expected 2, but 60) or the data in not in 'javabin' format

[Joe Lawson]

Yes they are both 6.0.
On Apr 25, 2016 1:07 PM, "Anshum Gupta"  wrote:

> Hi Joe,
>
> Can you confirm if the version of Solr and SolrJ are in sync ?
>
> On Mon, Apr 25, 2016 at 10:05 AM, Joe Lawson <
> jlaw...@opensourceconnections.com> wrote:
>
> > This appear to be a bug that'll be fixed in 6.1:
> > https://issues.apache.org/jira/browse/SOLR-7729
> >
> > On Fri, Apr 22, 2016 at 8:07 PM, Doug Turnbull <
> > dturnb...@opensourceconnections.com> wrote:
> >
> > > Joe this might be _version_ as in Solr's optimistic concurrency used in
> > > atomic updates, etc
> > >
> > > http://yonik.com/solr/optimistic-concurrency/
> > >
> > > On Fri, Apr 22, 2016 at 5:24 PM Joe Lawson <
> > > jlaw...@opensourceconnections.com> wrote:
> > >
> > > > I'm updating from a basic Solr Client to the
> ConcurrentUpdateSolrClient
> > > and
> > > > I'm hitting a really strange error. I cannot share the code but the
> > > snippet
> > > > is like:
> > > >
> > > > try (ConcurrentUpdateSolrClient solrUpdateClient =
> > > > >  new ConcurrentUpdateSolrClient("
> > > > > http://localhost:8983/solr";, 1000, 1)) {
> > > > > String _core = "lots";
> > > > > List batch = docs.subList(batch_start,
> > > > > batch_end);
> > > > > response = solrUpdateClient.add(_core,batch);
> > > > > solrUpdateClient.commit(_core);
> > > > > ...
> > > > > }
> > > >
> > > >
> > > >
> > > > Once the commit is called I get the following error:
> > > >
> > > > 17:17:22.585 [concurrentUpdateScheduler-1-thread-1-processing-http://
> > > > //localhost:8983//solr]
> > > > >> WARN  o.a.s.c.s.i.ConcurrentUpdateSolrClient - Failed to parse
> error
> > > > >> response from http://localhost:8983/solr due to:
> > > > >> java.lang.RuntimeException: Invalid version (expected 2, but 60)
> or
> > > the
> > > > >> data in not in 'javabin' format
> > > > >
> > > > > 17:17:22.588
> [concurrentUpdateScheduler-1-thread-1-processing-http://
> > > > //localhost:8983//solr]
> > > > >> ERROR o.a.s.c.s.i.ConcurrentUpdateSolrClient - error
> > > > >
> > > > > org.apache.solr.common.SolrException: Not Found
> > > > >
> > > > >
> > > > >>
> > > > >>
> > > > >> request: http://localhost:8983/solr/update?wt=javabin&version=2
> > > > >
> > > > > at
> > > > >>
> > > >
> > >
> >
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.sendUpdateStream(ConcurrentUpdateSolrClient.java:290)
> > > > >> [solr-solrj-6.0.0.jar:6.0.0
> > 48c80f91b8e5cd9b3a9b48e6184bd53e7619e7e3 -
> > > > >> nknize - 2016-04-01 14:41:50]
> > > > >
> > > > > at
> > > > >>
> > > >
> > >
> >
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.run(ConcurrentUpdateSolrClient.java:161)
> > > > >> [solr-solrj-6.0.0.jar:6.0.0
> > 48c80f91b8e5cd9b3a9b48e6184bd53e7619e7e3 -
> > > > >> nknize - 2016-04-01 14:41:50]
> > > > >
> > > > > at
> > > > >>
> > > >
> > >
> >
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> > > > >> [solr-solrj-6.0.0.jar:6.0.0
> > 48c80f91b8e5cd9b3a9b48e6184bd53e7619e7e3 -
> > > > >> nknize - 2016-04-01 14:41:50]
> > > > >
> > > > > at
> > > > >>
> > > >
> > >
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> > > > >> ~[na:1.8.0_92]
> > > > >
> > > > > at
> > > > >>
> > > >
> > >
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> > > > >> ~[na:1.8.0_92]
> > > > >
> > > > > at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_92]
> > > > >
> > > > >
> > > > Any help suggestions is appreciated.
> > > >
> > > > Cheers,
> > > >
> > > > Joe Lawson
> > > >
> > >
> >
>
>
>
> --
> Anshum Gupta
>

Re: The Streaming API (Solrj.io) : id must have DocValues?

[Joel Bernstein]

Can you describe how you're planning on using Streaming? I can provide some
feedback on how it will perform for your use use.

When scaling out Streaming you'll get large performance boosts when you
increase the number of shards, replicas and workers. This is particularly
true if you're doing parallel relational algebra or map/reduce operations.

As far a DocValues being expensive with unique fields, you'll want to do a
sizing exercise to see how many documents per-shard work best for your use
case. There are different docValues implementations that will allow you to
trade off memory for performance.

Joel Bernstein
http://joelsolr.blogspot.com/

On Mon, Apr 25, 2016 at 3:30 AM, Reth RM  wrote:

> Hi,
>
> So, is the concern related to same field value being stored twice: with
> stored=true and docValues=true? If that is the case, there is a jira
> relevant to this, fixed[1]. If you upgrade to 5.5/6.0 version, it is
> possible to read non-stored fields from docValues index., check out.
>
>
> [1] https://issues.apache.org/jira/browse/SOLR-8220
>
> On Mon, Apr 25, 2016 at 9:44 AM, sudsport s  wrote:
>
> > Thanks Erik for reply,
> >
> > Since I was storing Id (its stored field) and after enabling docValues my
> > guess is it will be stored in 2 places. also as per my understanding
> > docValues are great when you have values which repeat. I am not sure how
> > beneficial it would be for uniqueId field.
> > I am looking at collection of few hundred billion documents , that is
> > reason I really want to care about expense from design phase.
> >
> >
> >
> >
> > On Sun, Apr 24, 2016 at 7:24 PM, Erick Erickson  >
> > wrote:
> >
> > > In a word, "yes".
> > >
> > > DocValues aren't particularly expensive, or expensive at all. The idea
> > > is that when you sort by a field or facet, the field has to be
> > > "uninverted" which builds the entire structure in Java's JVM (this is
> > > when the field is _not_ DocValues).
> > >
> > > DocValues essentially serialize this structure to disk. So your
> > > on-disk index size is larger, but that size is MMaped rather than
> > > stored on Java's heap.
> > >
> > > Really, the question I'd have to ask though is "why do you care about
> > > the expense?". If you have a functional requirement that has to be
> > > served by returning the id via the /export handler, you really have no
> > > choice.
> > >
> > > Best,
> > > Erick
> > >
> > >
> > > On Sun, Apr 24, 2016 at 9:55 AM, sudsport s 
> > wrote:
> > > > I was trying to use Streaming for reading basic tuple stream. I am
> > using
> > > > sort by id asc ,
> > > > I am getting following exception
> > > >
> > > > I am using export search handler as per
> > > >
> https://cwiki.apache.org/confluence/display/solr/Exporting+Result+Sets
> > > >
> > > > null:java.io.IOException: id must have DocValues to use this feature.
> > > > at
> > >
> >
> org.apache.solr.response.SortingResponseWriter.getFieldWriters(SortingResponseWriter.java:241)
> > > > at
> > >
> >
> org.apache.solr.response.SortingResponseWriter.write(SortingResponseWriter.java:120)
> > > > at
> > >
> >
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:53)
> > > > at
> > >
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:742)
> > > > at
> > > org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:471)
> > > > at
> > >
> >
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:214)
> > > > at
> > >
> >
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> > > > at
> > >
> >
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> > > > at
> > >
> >
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> > > > at
> > >
> >
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> > > > at
> > >
> >
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> > > > at
> > >
> >
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> > > > at
> > >
> >
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> > > > at
> > >
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> > > > at org.eclipse.jetty.server.session.SessionHandler.doScope(
> > > >
> > > >
> > > > does it make sense to enable docValues for unique field? How
> expensive
> > > is it?
> > > >
> > > >
> > > > if I have existing collection can I update schema and optimize
> > > > collection to get docvalues enabled for id?
> > > >
> > > >
> > > > --
> > > >
> > > > Thanks
> > >
> >
>

Re: how to retrieve json facet using solrj

[Georg Sorst]

Hi Yangrui,

from what I've gathered the JSON Facets are not supported in SolrJ yet, so
you need to manually work with the response, ie.:
response.getResponse().get("facets")

Best,
Georg

Yangrui Guo  schrieb am So., 24. Apr. 2016 um
22:13 Uhr:

> Hello
>
> I use json facet api to get facets. The response returned with facets and
> counts However, when I called the getFacetFields method in SolrJ client, I
> got null results. How can I get the facet results from solrj? I set my
> query as query.setParam("json.facet", "{entities : {type: terms,field:
> class2} }" Am I missing something? Thanks.
>
> Yangrui
>
-- 
*Georg M. Sorst I CTO*
FINDOLOGIC GmbH



Jakob-Haringer-Str. 5a | 5020 Salzburg I T.: +43 662 456708
E.: g.so...@findologic.com
www.findologic.com Folgen Sie uns auf: XING
facebook
 Twitter


Wir sehen uns auf dem *Shopware Community Day in Ahaus am 20.05.2016!* Hier
 Termin
vereinbaren!
Wir sehen uns auf der* dmexco in Köln am 14.09. und 15.09.2016!* Hier
 Termin
vereinbaren!

Re: How can I set the defaultOperator to be AND?

[Georg Sorst]

With Solr 6.0 I've had to set mm=100% & q.op=AND for a full AND query (and
mm=1 & q.op=OR for a full OR query).

Jan Høydahl  schrieb am Mo., 25. Apr. 2016 um
16:04 Uhr:

> I think a workaround for your specific case could be to set mm=100% &
> q.op=OR (although it used to work for q.op=AND before)
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> > 25. apr. 2016 kl. 14.53 skrev Shawn Heisey :
> >
> > On 4/25/2016 6:39 AM, Bastien Latard - MDPI AG wrote:
> >> Remember:
> >> If I add the following line to the schema.xml, even if I do a search
> >> 'title:"test" OR author:"me"', it will returns documents matching
> >> 'title:"test" AND author:"me"':
> >> 
> >
> > The settings in the schema for default field and default operator were
> > deprecated a long time ago.  I actually have no idea whether they are
> > even supported in newer Solr versions.
> >
> > The q.op parameter controls the default operator, and the df parameter
> > controls the default field.  These can be set in the request handler
> > definition in solrconfig.xml -- usually in "defaults" but there might be
> > reason to put them in "invariants" instead.
> >
> > If you're using edismax, you'd be better off using the mm parameter
> > rather than the q.op parameter.  The behavior you have described above
> > sounds like a change in behavior (some call it a bug) introduced in the
> > 5.5 version:
> >
> > https://issues.apache.org/jira/browse/SOLR-8812
> >
> > If you are using edismax, I suspect that if you set mm=100% instead of
> > q.op=AND (or the schema default operator) that the problem might go away
> > ... but I am not sure.  Someone who is more familiar with SOLR-8812
> > probably should comment.
> >
> > Thanks,
> > Shawn
> >
>
> --
*Georg M. Sorst I CTO*
FINDOLOGIC GmbH



Jakob-Haringer-Str. 5a | 5020 Salzburg I T.: +43 662 456708
E.: g.so...@findologic.com
www.findologic.com Folgen Sie uns auf: XING
facebook
 Twitter


Wir sehen uns auf dem *Shopware Community Day in Ahaus am 20.05.2016!* Hier
 Termin
vereinbaren!
Wir sehen uns auf der* dmexco in Köln am 14.09. und 15.09.2016!* Hier
 Termin
vereinbaren!

Re: ConcurrentUpdateSolrClient Invalid version (expected 2, but 60) or the data in not in 'javabin' format

[Anshum Gupta]

Hi Joe,

Can you confirm if the version of Solr and SolrJ are in sync ?

On Mon, Apr 25, 2016 at 10:05 AM, Joe Lawson <
jlaw...@opensourceconnections.com> wrote:

> This appear to be a bug that'll be fixed in 6.1:
> https://issues.apache.org/jira/browse/SOLR-7729
>
> On Fri, Apr 22, 2016 at 8:07 PM, Doug Turnbull <
> dturnb...@opensourceconnections.com> wrote:
>
> > Joe this might be _version_ as in Solr's optimistic concurrency used in
> > atomic updates, etc
> >
> > http://yonik.com/solr/optimistic-concurrency/
> >
> > On Fri, Apr 22, 2016 at 5:24 PM Joe Lawson <
> > jlaw...@opensourceconnections.com> wrote:
> >
> > > I'm updating from a basic Solr Client to the ConcurrentUpdateSolrClient
> > and
> > > I'm hitting a really strange error. I cannot share the code but the
> > snippet
> > > is like:
> > >
> > > try (ConcurrentUpdateSolrClient solrUpdateClient =
> > > >  new ConcurrentUpdateSolrClient("
> > > > http://localhost:8983/solr";, 1000, 1)) {
> > > > String _core = "lots";
> > > > List batch = docs.subList(batch_start,
> > > > batch_end);
> > > > response = solrUpdateClient.add(_core,batch);
> > > > solrUpdateClient.commit(_core);
> > > > ...
> > > > }
> > >
> > >
> > >
> > > Once the commit is called I get the following error:
> > >
> > > 17:17:22.585 [concurrentUpdateScheduler-1-thread-1-processing-http://
> > > //localhost:8983//solr]
> > > >> WARN  o.a.s.c.s.i.ConcurrentUpdateSolrClient - Failed to parse error
> > > >> response from http://localhost:8983/solr due to:
> > > >> java.lang.RuntimeException: Invalid version (expected 2, but 60) or
> > the
> > > >> data in not in 'javabin' format
> > > >
> > > > 17:17:22.588 [concurrentUpdateScheduler-1-thread-1-processing-http://
> > > //localhost:8983//solr]
> > > >> ERROR o.a.s.c.s.i.ConcurrentUpdateSolrClient - error
> > > >
> > > > org.apache.solr.common.SolrException: Not Found
> > > >
> > > >
> > > >>
> > > >>
> > > >> request: http://localhost:8983/solr/update?wt=javabin&version=2
> > > >
> > > > at
> > > >>
> > >
> >
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.sendUpdateStream(ConcurrentUpdateSolrClient.java:290)
> > > >> [solr-solrj-6.0.0.jar:6.0.0
> 48c80f91b8e5cd9b3a9b48e6184bd53e7619e7e3 -
> > > >> nknize - 2016-04-01 14:41:50]
> > > >
> > > > at
> > > >>
> > >
> >
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.run(ConcurrentUpdateSolrClient.java:161)
> > > >> [solr-solrj-6.0.0.jar:6.0.0
> 48c80f91b8e5cd9b3a9b48e6184bd53e7619e7e3 -
> > > >> nknize - 2016-04-01 14:41:50]
> > > >
> > > > at
> > > >>
> > >
> >
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> > > >> [solr-solrj-6.0.0.jar:6.0.0
> 48c80f91b8e5cd9b3a9b48e6184bd53e7619e7e3 -
> > > >> nknize - 2016-04-01 14:41:50]
> > > >
> > > > at
> > > >>
> > >
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> > > >> ~[na:1.8.0_92]
> > > >
> > > > at
> > > >>
> > >
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> > > >> ~[na:1.8.0_92]
> > > >
> > > > at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_92]
> > > >
> > > >
> > > Any help suggestions is appreciated.
> > >
> > > Cheers,
> > >
> > > Joe Lawson
> > >
> >
>



-- 
Anshum Gupta

Re: ConcurrentUpdateSolrClient Invalid version (expected 2, but 60) or the data in not in 'javabin' format

[Joe Lawson]

This appear to be a bug that'll be fixed in 6.1:
https://issues.apache.org/jira/browse/SOLR-7729

On Fri, Apr 22, 2016 at 8:07 PM, Doug Turnbull <
dturnb...@opensourceconnections.com> wrote:

> Joe this might be _version_ as in Solr's optimistic concurrency used in
> atomic updates, etc
>
> http://yonik.com/solr/optimistic-concurrency/
>
> On Fri, Apr 22, 2016 at 5:24 PM Joe Lawson <
> jlaw...@opensourceconnections.com> wrote:
>
> > I'm updating from a basic Solr Client to the ConcurrentUpdateSolrClient
> and
> > I'm hitting a really strange error. I cannot share the code but the
> snippet
> > is like:
> >
> > try (ConcurrentUpdateSolrClient solrUpdateClient =
> > >  new ConcurrentUpdateSolrClient("
> > > http://localhost:8983/solr";, 1000, 1)) {
> > > String _core = "lots";
> > > List batch = docs.subList(batch_start,
> > > batch_end);
> > > response = solrUpdateClient.add(_core,batch);
> > > solrUpdateClient.commit(_core);
> > > ...
> > > }
> >
> >
> >
> > Once the commit is called I get the following error:
> >
> > 17:17:22.585 [concurrentUpdateScheduler-1-thread-1-processing-http://
> > //localhost:8983//solr]
> > >> WARN  o.a.s.c.s.i.ConcurrentUpdateSolrClient - Failed to parse error
> > >> response from http://localhost:8983/solr due to:
> > >> java.lang.RuntimeException: Invalid version (expected 2, but 60) or
> the
> > >> data in not in 'javabin' format
> > >
> > > 17:17:22.588 [concurrentUpdateScheduler-1-thread-1-processing-http://
> > //localhost:8983//solr]
> > >> ERROR o.a.s.c.s.i.ConcurrentUpdateSolrClient - error
> > >
> > > org.apache.solr.common.SolrException: Not Found
> > >
> > >
> > >>
> > >>
> > >> request: http://localhost:8983/solr/update?wt=javabin&version=2
> > >
> > > at
> > >>
> >
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.sendUpdateStream(ConcurrentUpdateSolrClient.java:290)
> > >> [solr-solrj-6.0.0.jar:6.0.0 48c80f91b8e5cd9b3a9b48e6184bd53e7619e7e3 -
> > >> nknize - 2016-04-01 14:41:50]
> > >
> > > at
> > >>
> >
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.run(ConcurrentUpdateSolrClient.java:161)
> > >> [solr-solrj-6.0.0.jar:6.0.0 48c80f91b8e5cd9b3a9b48e6184bd53e7619e7e3 -
> > >> nknize - 2016-04-01 14:41:50]
> > >
> > > at
> > >>
> >
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> > >> [solr-solrj-6.0.0.jar:6.0.0 48c80f91b8e5cd9b3a9b48e6184bd53e7619e7e3 -
> > >> nknize - 2016-04-01 14:41:50]
> > >
> > > at
> > >>
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> > >> ~[na:1.8.0_92]
> > >
> > > at
> > >>
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> > >> ~[na:1.8.0_92]
> > >
> > > at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_92]
> > >
> > >
> > Any help suggestions is appreciated.
> >
> > Cheers,
> >
> > Joe Lawson
> >
>

Re: Replicas for same shard not in sync

[Erick Erickson]

bq: I also read that it's up to the
client to keep track of updates in case commits don't happen on all the
replicas.

This is not true. Or if it is it's a bug.

The update cycle is this:
1> updates get to the leader
2> updates are sent to all followers and indexed on the leader as well
3> each replica writes the updates to the local transaction log
4> all the replicas ack back to the leader
5> the leader responds to the client.

At this point, all the replicas for the shard have the docs locally
and can take over as leader.

You may be confusing indexing in batches and having errors with
updates getting to replicas. When you send a batch of docs to Solr,
if one of them fails indexing some of the rest of the docs may not
be indexed. See SOLR-445 for some work on this front.

That said, bouncing servers willy-nilly during heavy indexing, especially
if the indexer doesn't know enough to retry if an indexing attempt fails may
be the root cause here. Have you verified that your indexing program
retries in the event of failure?

Best,
Erick

On Mon, Apr 25, 2016 at 6:13 AM, tedsolr  wrote:
> I've done a bit of reading - found some other posts with similar questions.
> So I gather "Optimizing" a collection is rarely a good idea. It does not
> need to be condensed to a single segment. I also read that it's up to the
> client to keep track of updates in case commits don't happen on all the
> replicas. Solr will commit and return success as long as one replica gets
> the update.
>
> I have a state where the two replicas for one collection are out of sync.
> One has some updates that the other does not. And I don't have log data to
> tell me what the differences are. This happened during a maintenance window
> when the servers got restarted while a large index job was running. Normally
> this doesn't cause a problem, but it did last Thursday.
>
> What I plan to do is select the replica I believe is incomplete and delete
> it. Then add a new one. I was just hoping Solr had a solution for this -
> maybe using the ZK transaction logs to replay some updates, or force a
> resync between the replicas.
>
> I will also implement a fix to prevent Solr from restarting unless one of
> its config files has changed. No need to bounce Solr just for kicks.
>
>
>
> --
> View this message in context: 
> http://lucene.472066.n3.nabble.com/Replicas-for-same-shard-not-in-sync-tp4272236p4272602.html
> Sent from the Solr - User mailing list archive at Nabble.com.

Re: Solr slave is doing full replication (entire index) of index after master restart

[Erick Erickson]

You should follow the unsubscribe instructions here:

http://lucene.apache.org/solr/resources.html

Under the "mailing list" section. You must use the exact
same e-mail addresss you used to subscribe.

If you still have problems, let us know.

Erick

On Mon, Apr 25, 2016 at 9:33 AM, Pla Gong  wrote:
> All,
>
> I am getting tons of email per day from this newsgroup.  Does anyone know how 
> to remove ones self from the newsgroup.
>
> Thanks in advance,
>
> Pla
>
> 
> From: Pla Gong 
> Sent: Monday, April 25, 2016 9:27 AM
> To: solr-user@lucene.apache.org
> Subject: Re: Solr slave is doing full replication (entire index) of index 
> after master restart
>
> Please remove me from the newsgroup.
>
> Thanks,
>
> Pla
>
> 
> From: Shalin Shekhar Mangar 
> Sent: Monday, April 25, 2016 8:20 AM
> To: solr-user@lucene.apache.org
> Cc: lior.sa...@gmail.com
> Subject: Re: Solr slave is doing full replication (entire index) of index 
> after master restart
>
> Hi Lior,
>
> Sorry for the late reply. I am able to successfully reproduce this problem
> on Solr 5.3.1 and on Solr 6.0.0 as well.
>
> The interesting thing is that if the master is restarted before the poll
> interval (1 minute in your case) then the index is not downloaded again.
> But if the slave makes even one failed poll attempt then on restart it
> downloads the entire index again from the master.
>
> I have opened https://issues.apache.org/jira/browse/SOLR-9036
>
> On Wed, Apr 13, 2016 at 12:01 AM, Lior Sapir  wrote:
>
>> So what do you say:
>> Is it a problem in my environment + confs
>> OR
>> That's how the replication is working
>>
>>  (if a slave fails to locate the master when polling then next time the
>> master is available it will replicate the entire index even if no document
>> was added to the master and no optimization was performed)
>>
>> ?
>>
>>
>>
>> On Sat, Apr 9, 2016 at 9:24 PM, Lior Sapir  wrote:
>>
>> > Thanks for the reply.
>> >
>> > 00:00:60 - Is valid
>> > But I tried 00:01:00 anyway.
>> > I also checked the clocks and they are synced:
>> > ntpdate -q solr01-isrl01
>> >
>> > server 192.168.103.112, stratum 11, offset 0.003648, delay 0.02589
>> >  9 Apr 18:09:20 ntpdate[23921]: adjust time server 192.168.103.112 offset
>> > 0.003648 sec
>> >
>> > So these are not the reasons for the full replication. In addition the
>> > replication is working perfectly until I restart the master
>> > Regarding the issue of 60 seconds being too fast, I can consider raising
>> > it to 5 minutes even though my configuration is based on the data-driven
>> > example contained in the solr package.
>> >
>> > But still, this will just make the probability of full replication lower.
>> > I don't want to rely on that in production. if I have any network issue
>> or
>> > the master server will restart from any reason. All of his slaves will
>> > start replicating when the master will be available again and the service
>> > will be harmed dramatically or even be down.
>> >
>> > Anyway,
>> >
>> > Can anyone with solr version 5.3.1 or above test this scenario? I want to
>> > understand if its something specific in my environment or that's just how
>> > the replication is behaving.
>> >
>> > I added another step to be more clear:
>> >
>> > 1. Setup a master
>> > 2. Setup a slave in a different server
>> > 3. The slave replicated the master index
>> > 4. From now on not even a single document is added. No optimization or
>> > what so ever is done on the master or slave
>> > 5. I stop the master
>> > 6. wait for the slave to replicate or initiate a replication via the UI
>> or
>> > script
>> > 7. I start the master
>> > 8. I see the slave is replicating/copying the entire index
>> >
>> >
>> > Lior.
>> >
>> >
>> >
>> >
>> > On Sat, Apr 9, 2016 at 6:15 PM, Walter Underwood 
>> > wrote:
>> >
>> >> I’m not sure this is a legal polling interval:
>> >>
>> >> 00:00:60
>> >>
>> >> Try:
>> >>
>> >> 00:01:00
>> >>
>> >> Also, polling every minute is very fast. Try a longer period.
>> >>
>> >> Check the clocks on the two systems. If the clocks are not synchronized,
>> >> that could cause problem.
>> >>
>> >> wunder
>> >> Walter Underwood
>> >> wun...@wunderwood.org
>> >> http://observer.wunderwood.org/  (my blog)
>> >>
>> >>
>> >> > On Apr 9, 2016, at 8:10 AM, Lior Sapir  wrote:
>> >> >
>> >> > Anyone can tell me what was I doing wrong ?
>> >> > Is that the expected behavior (slave replicate entire index if on
>> >> previous replication attempt the master was not available ) ?
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Thu, Apr 7, 2016 at 9:12 PM, Lior Sapir > >> > wrote:
>> >> > Thanks for the reply.
>> >> >
>> >> > I easily re produced it in my "sandbox" env.  Steps to re produce
>> >> > 1. Setup a master
>> >> > 2. Setup a slave in a different server
>> >> > 3. The slave replicated the master index
>> >> > 4. From now on not even a single docum

Re: Solr slave is doing full replication (entire index) of index after master restart

[Pla Gong]

All,

I am getting tons of email per day from this newsgroup.  Does anyone know how 
to remove ones self from the newsgroup.

Thanks in advance,

Pla


From: Pla Gong 
Sent: Monday, April 25, 2016 9:27 AM
To: solr-user@lucene.apache.org
Subject: Re: Solr slave is doing full replication (entire index) of index after 
master restart

Please remove me from the newsgroup.

Thanks,

Pla


From: Shalin Shekhar Mangar 
Sent: Monday, April 25, 2016 8:20 AM
To: solr-user@lucene.apache.org
Cc: lior.sa...@gmail.com
Subject: Re: Solr slave is doing full replication (entire index) of index after 
master restart

Hi Lior,

Sorry for the late reply. I am able to successfully reproduce this problem
on Solr 5.3.1 and on Solr 6.0.0 as well.

The interesting thing is that if the master is restarted before the poll
interval (1 minute in your case) then the index is not downloaded again.
But if the slave makes even one failed poll attempt then on restart it
downloads the entire index again from the master.

I have opened https://issues.apache.org/jira/browse/SOLR-9036

On Wed, Apr 13, 2016 at 12:01 AM, Lior Sapir  wrote:

> So what do you say:
> Is it a problem in my environment + confs
> OR
> That's how the replication is working
>
>  (if a slave fails to locate the master when polling then next time the
> master is available it will replicate the entire index even if no document
> was added to the master and no optimization was performed)
>
> ?
>
>
>
> On Sat, Apr 9, 2016 at 9:24 PM, Lior Sapir  wrote:
>
> > Thanks for the reply.
> >
> > 00:00:60 - Is valid
> > But I tried 00:01:00 anyway.
> > I also checked the clocks and they are synced:
> > ntpdate -q solr01-isrl01
> >
> > server 192.168.103.112, stratum 11, offset 0.003648, delay 0.02589
> >  9 Apr 18:09:20 ntpdate[23921]: adjust time server 192.168.103.112 offset
> > 0.003648 sec
> >
> > So these are not the reasons for the full replication. In addition the
> > replication is working perfectly until I restart the master
> > Regarding the issue of 60 seconds being too fast, I can consider raising
> > it to 5 minutes even though my configuration is based on the data-driven
> > example contained in the solr package.
> >
> > But still, this will just make the probability of full replication lower.
> > I don't want to rely on that in production. if I have any network issue
> or
> > the master server will restart from any reason. All of his slaves will
> > start replicating when the master will be available again and the service
> > will be harmed dramatically or even be down.
> >
> > Anyway,
> >
> > Can anyone with solr version 5.3.1 or above test this scenario? I want to
> > understand if its something specific in my environment or that's just how
> > the replication is behaving.
> >
> > I added another step to be more clear:
> >
> > 1. Setup a master
> > 2. Setup a slave in a different server
> > 3. The slave replicated the master index
> > 4. From now on not even a single document is added. No optimization or
> > what so ever is done on the master or slave
> > 5. I stop the master
> > 6. wait for the slave to replicate or initiate a replication via the UI
> or
> > script
> > 7. I start the master
> > 8. I see the slave is replicating/copying the entire index
> >
> >
> > Lior.
> >
> >
> >
> >
> > On Sat, Apr 9, 2016 at 6:15 PM, Walter Underwood 
> > wrote:
> >
> >> I’m not sure this is a legal polling interval:
> >>
> >> 00:00:60
> >>
> >> Try:
> >>
> >> 00:01:00
> >>
> >> Also, polling every minute is very fast. Try a longer period.
> >>
> >> Check the clocks on the two systems. If the clocks are not synchronized,
> >> that could cause problem.
> >>
> >> wunder
> >> Walter Underwood
> >> wun...@wunderwood.org
> >> http://observer.wunderwood.org/  (my blog)
> >>
> >>
> >> > On Apr 9, 2016, at 8:10 AM, Lior Sapir  wrote:
> >> >
> >> > Anyone can tell me what was I doing wrong ?
> >> > Is that the expected behavior (slave replicate entire index if on
> >> previous replication attempt the master was not available ) ?
> >> >
> >> >
> >> >
> >> >
> >> > On Thu, Apr 7, 2016 at 9:12 PM, Lior Sapir  >> > wrote:
> >> > Thanks for the reply.
> >> >
> >> > I easily re produced it in my "sandbox" env.  Steps to re produce
> >> > 1. Setup a master
> >> > 2. Setup a slave in a different server
> >> > 3. The slave replicated the master index
> >> > 4. From now on not even a single document is added. No optimization or
> >> what so ever is done on the master or slave
> >> > 5. I stop the master
> >> > 6. I start the master
> >> > 7. I see the slave is replicating/copying the entire index
> >> >
> >> > This is exactly what happened  in production when I restarted the
> >> master.
> >> >
> >> > I attached the configurations files.
> >> >
> >> > Replication section:
> >> >
> >> > Master:
> >> >
> >> > 
> >> >   
> >> > commit
> >> >   
> >> > 
> >> >
> >> >

Re: Solr slave is doing full replication (entire index) of index after master restart

[Pla Gong]

Please remove me from the newsgroup.

Thanks,

Pla


From: Shalin Shekhar Mangar 
Sent: Monday, April 25, 2016 8:20 AM
To: solr-user@lucene.apache.org
Cc: lior.sa...@gmail.com
Subject: Re: Solr slave is doing full replication (entire index) of index after 
master restart

Hi Lior,

Sorry for the late reply. I am able to successfully reproduce this problem
on Solr 5.3.1 and on Solr 6.0.0 as well.

The interesting thing is that if the master is restarted before the poll
interval (1 minute in your case) then the index is not downloaded again.
But if the slave makes even one failed poll attempt then on restart it
downloads the entire index again from the master.

I have opened https://issues.apache.org/jira/browse/SOLR-9036

On Wed, Apr 13, 2016 at 12:01 AM, Lior Sapir  wrote:

> So what do you say:
> Is it a problem in my environment + confs
> OR
> That's how the replication is working
>
>  (if a slave fails to locate the master when polling then next time the
> master is available it will replicate the entire index even if no document
> was added to the master and no optimization was performed)
>
> ?
>
>
>
> On Sat, Apr 9, 2016 at 9:24 PM, Lior Sapir  wrote:
>
> > Thanks for the reply.
> >
> > 00:00:60 - Is valid
> > But I tried 00:01:00 anyway.
> > I also checked the clocks and they are synced:
> > ntpdate -q solr01-isrl01
> >
> > server 192.168.103.112, stratum 11, offset 0.003648, delay 0.02589
> >  9 Apr 18:09:20 ntpdate[23921]: adjust time server 192.168.103.112 offset
> > 0.003648 sec
> >
> > So these are not the reasons for the full replication. In addition the
> > replication is working perfectly until I restart the master
> > Regarding the issue of 60 seconds being too fast, I can consider raising
> > it to 5 minutes even though my configuration is based on the data-driven
> > example contained in the solr package.
> >
> > But still, this will just make the probability of full replication lower.
> > I don't want to rely on that in production. if I have any network issue
> or
> > the master server will restart from any reason. All of his slaves will
> > start replicating when the master will be available again and the service
> > will be harmed dramatically or even be down.
> >
> > Anyway,
> >
> > Can anyone with solr version 5.3.1 or above test this scenario? I want to
> > understand if its something specific in my environment or that's just how
> > the replication is behaving.
> >
> > I added another step to be more clear:
> >
> > 1. Setup a master
> > 2. Setup a slave in a different server
> > 3. The slave replicated the master index
> > 4. From now on not even a single document is added. No optimization or
> > what so ever is done on the master or slave
> > 5. I stop the master
> > 6. wait for the slave to replicate or initiate a replication via the UI
> or
> > script
> > 7. I start the master
> > 8. I see the slave is replicating/copying the entire index
> >
> >
> > Lior.
> >
> >
> >
> >
> > On Sat, Apr 9, 2016 at 6:15 PM, Walter Underwood 
> > wrote:
> >
> >> I’m not sure this is a legal polling interval:
> >>
> >> 00:00:60
> >>
> >> Try:
> >>
> >> 00:01:00
> >>
> >> Also, polling every minute is very fast. Try a longer period.
> >>
> >> Check the clocks on the two systems. If the clocks are not synchronized,
> >> that could cause problem.
> >>
> >> wunder
> >> Walter Underwood
> >> wun...@wunderwood.org
> >> http://observer.wunderwood.org/  (my blog)
> >>
> >>
> >> > On Apr 9, 2016, at 8:10 AM, Lior Sapir  wrote:
> >> >
> >> > Anyone can tell me what was I doing wrong ?
> >> > Is that the expected behavior (slave replicate entire index if on
> >> previous replication attempt the master was not available ) ?
> >> >
> >> >
> >> >
> >> >
> >> > On Thu, Apr 7, 2016 at 9:12 PM, Lior Sapir  >> > wrote:
> >> > Thanks for the reply.
> >> >
> >> > I easily re produced it in my "sandbox" env.  Steps to re produce
> >> > 1. Setup a master
> >> > 2. Setup a slave in a different server
> >> > 3. The slave replicated the master index
> >> > 4. From now on not even a single document is added. No optimization or
> >> what so ever is done on the master or slave
> >> > 5. I stop the master
> >> > 6. I start the master
> >> > 7. I see the slave is replicating/copying the entire index
> >> >
> >> > This is exactly what happened  in production when I restarted the
> >> master.
> >> >
> >> > I attached the configurations files.
> >> >
> >> > Replication section:
> >> >
> >> > Master:
> >> >
> >> > 
> >> >   
> >> > commit
> >> >   
> >> > 
> >> >
> >> > Slave:
> >> >
> >> >>
> >> > 
> >> > 
> >> http://solr01-isrl01.flr.local:8983/solr/replication-master/replication
> <
> >> http://solr01-isrl01.flr.local:8983/solr/replication-master/replication
> >> >
> >> > 00:00:60
> >> > 
> >> > 
> >> >
> >> >
> >> >
> >> > Best,
> >> > Lior
> >> >
> >> > On Thu, Apr 7, 2016 at 6:56 PM

Re: Solr slave is doing full replication (entire index) of index after master restart

[Shalin Shekhar Mangar]

Hi Lior,

Sorry for the late reply. I am able to successfully reproduce this problem
on Solr 5.3.1 and on Solr 6.0.0 as well.

The interesting thing is that if the master is restarted before the poll
interval (1 minute in your case) then the index is not downloaded again.
But if the slave makes even one failed poll attempt then on restart it
downloads the entire index again from the master.

I have opened https://issues.apache.org/jira/browse/SOLR-9036

On Wed, Apr 13, 2016 at 12:01 AM, Lior Sapir  wrote:

> So what do you say:
> Is it a problem in my environment + confs
> OR
> That's how the replication is working
>
>  (if a slave fails to locate the master when polling then next time the
> master is available it will replicate the entire index even if no document
> was added to the master and no optimization was performed)
>
> ?
>
>
>
> On Sat, Apr 9, 2016 at 9:24 PM, Lior Sapir  wrote:
>
> > Thanks for the reply.
> >
> > 00:00:60 - Is valid
> > But I tried 00:01:00 anyway.
> > I also checked the clocks and they are synced:
> > ntpdate -q solr01-isrl01
> >
> > server 192.168.103.112, stratum 11, offset 0.003648, delay 0.02589
> >  9 Apr 18:09:20 ntpdate[23921]: adjust time server 192.168.103.112 offset
> > 0.003648 sec
> >
> > So these are not the reasons for the full replication. In addition the
> > replication is working perfectly until I restart the master
> > Regarding the issue of 60 seconds being too fast, I can consider raising
> > it to 5 minutes even though my configuration is based on the data-driven
> > example contained in the solr package.
> >
> > But still, this will just make the probability of full replication lower.
> > I don't want to rely on that in production. if I have any network issue
> or
> > the master server will restart from any reason. All of his slaves will
> > start replicating when the master will be available again and the service
> > will be harmed dramatically or even be down.
> >
> > Anyway,
> >
> > Can anyone with solr version 5.3.1 or above test this scenario? I want to
> > understand if its something specific in my environment or that's just how
> > the replication is behaving.
> >
> > I added another step to be more clear:
> >
> > 1. Setup a master
> > 2. Setup a slave in a different server
> > 3. The slave replicated the master index
> > 4. From now on not even a single document is added. No optimization or
> > what so ever is done on the master or slave
> > 5. I stop the master
> > 6. wait for the slave to replicate or initiate a replication via the UI
> or
> > script
> > 7. I start the master
> > 8. I see the slave is replicating/copying the entire index
> >
> >
> > Lior.
> >
> >
> >
> >
> > On Sat, Apr 9, 2016 at 6:15 PM, Walter Underwood 
> > wrote:
> >
> >> I’m not sure this is a legal polling interval:
> >>
> >> 00:00:60
> >>
> >> Try:
> >>
> >> 00:01:00
> >>
> >> Also, polling every minute is very fast. Try a longer period.
> >>
> >> Check the clocks on the two systems. If the clocks are not synchronized,
> >> that could cause problem.
> >>
> >> wunder
> >> Walter Underwood
> >> wun...@wunderwood.org
> >> http://observer.wunderwood.org/  (my blog)
> >>
> >>
> >> > On Apr 9, 2016, at 8:10 AM, Lior Sapir  wrote:
> >> >
> >> > Anyone can tell me what was I doing wrong ?
> >> > Is that the expected behavior (slave replicate entire index if on
> >> previous replication attempt the master was not available ) ?
> >> >
> >> >
> >> >
> >> >
> >> > On Thu, Apr 7, 2016 at 9:12 PM, Lior Sapir  >> > wrote:
> >> > Thanks for the reply.
> >> >
> >> > I easily re produced it in my "sandbox" env.  Steps to re produce
> >> > 1. Setup a master
> >> > 2. Setup a slave in a different server
> >> > 3. The slave replicated the master index
> >> > 4. From now on not even a single document is added. No optimization or
> >> what so ever is done on the master or slave
> >> > 5. I stop the master
> >> > 6. I start the master
> >> > 7. I see the slave is replicating/copying the entire index
> >> >
> >> > This is exactly what happened  in production when I restarted the
> >> master.
> >> >
> >> > I attached the configurations files.
> >> >
> >> > Replication section:
> >> >
> >> > Master:
> >> >
> >> > 
> >> >   
> >> > commit
> >> >   
> >> > 
> >> >
> >> > Slave:
> >> >
> >> >>
> >> > 
> >> > 
> >> http://solr01-isrl01.flr.local:8983/solr/replication-master/replication
> <
> >> http://solr01-isrl01.flr.local:8983/solr/replication-master/replication
> >> >
> >> > 00:00:60
> >> > 
> >> > 
> >> >
> >> >
> >> >
> >> > Best,
> >> > Lior
> >> >
> >> > On Thu, Apr 7, 2016 at 6:56 PM, Erick Erickson <
> erickerick...@gmail.com
> >> > wrote:
> >> > What does your configuration file look like for the replication
> >> > handler? Does this happen whenever you restart a slave even if
> >> > _nothing_ has changed on the master?
> >> >
> >> > And this will certainly

Re: How can I set the defaultOperator to be AND?

[Jan Høydahl]

I think a workaround for your specific case could be to set mm=100% & q.op=OR 
(although it used to work for q.op=AND before)

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 25. apr. 2016 kl. 14.53 skrev Shawn Heisey :
> 
> On 4/25/2016 6:39 AM, Bastien Latard - MDPI AG wrote:
>> Remember:
>> If I add the following line to the schema.xml, even if I do a search
>> 'title:"test" OR author:"me"', it will returns documents matching
>> 'title:"test" AND author:"me"':
>>  
> 
> The settings in the schema for default field and default operator were
> deprecated a long time ago.  I actually have no idea whether they are
> even supported in newer Solr versions.
> 
> The q.op parameter controls the default operator, and the df parameter
> controls the default field.  These can be set in the request handler
> definition in solrconfig.xml -- usually in "defaults" but there might be
> reason to put them in "invariants" instead.
> 
> If you're using edismax, you'd be better off using the mm parameter
> rather than the q.op parameter.  The behavior you have described above
> sounds like a change in behavior (some call it a bug) introduced in the
> 5.5 version:
> 
> https://issues.apache.org/jira/browse/SOLR-8812
> 
> If you are using edismax, I suspect that if you set mm=100% instead of
> q.op=AND (or the schema default operator) that the problem might go away
> ... but I am not sure.  Someone who is more familiar with SOLR-8812
> probably should comment.
> 
> Thanks,
> Shawn
> 

Solr Reference Guide for 6.0 Released

[Cassandra Targett]

The Lucene PMC is pleased to announce that the Apache Solr Reference
Guide for 6.0 has been released. The Guide has been updated
extensively for 6.0, with new sections for Parallel SQL and Cross Data
Center Replication.

This 660 page PDF is the definitive guide to Solr and can be
downloaded from:
https://www.apache.org/dyn/closer.cgi/lucene/solr/ref-guide/apache-solr-ref-guide-6.0.pdf

-- Cassandra

Re: Replicas for same shard not in sync

[tedsolr]

I've done a bit of reading - found some other posts with similar questions.
So I gather "Optimizing" a collection is rarely a good idea. It does not
need to be condensed to a single segment. I also read that it's up to the
client to keep track of updates in case commits don't happen on all the
replicas. Solr will commit and return success as long as one replica gets
the update.

I have a state where the two replicas for one collection are out of sync.
One has some updates that the other does not. And I don't have log data to
tell me what the differences are. This happened during a maintenance window
when the servers got restarted while a large index job was running. Normally
this doesn't cause a problem, but it did last Thursday.

What I plan to do is select the replica I believe is incomplete and delete
it. Then add a new one. I was just hoping Solr had a solution for this -
maybe using the ZK transaction logs to replay some updates, or force a
resync between the replicas.

I will also implement a fix to prevent Solr from restarting unless one of
its config files has changed. No need to bounce Solr just for kicks.



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Replicas-for-same-shard-not-in-sync-tp4272236p4272602.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: How can I set the defaultOperator to be AND?

[Shawn Heisey]

On 4/25/2016 6:39 AM, Bastien Latard - MDPI AG wrote:
> Remember:
> If I add the following line to the schema.xml, even if I do a search
> 'title:"test" OR author:"me"', it will returns documents matching
> 'title:"test" AND author:"me"':
>  

The settings in the schema for default field and default operator were
deprecated a long time ago.  I actually have no idea whether they are
even supported in newer Solr versions.

The q.op parameter controls the default operator, and the df parameter
controls the default field.  These can be set in the request handler
definition in solrconfig.xml -- usually in "defaults" but there might be
reason to put them in "invariants" instead.

If you're using edismax, you'd be better off using the mm parameter
rather than the q.op parameter.  The behavior you have described above
sounds like a change in behavior (some call it a bug) introduced in the
5.5 version:

https://issues.apache.org/jira/browse/SOLR-8812

If you are using edismax, I suspect that if you set mm=100% instead of
q.op=AND (or the schema default operator) that the problem might go away
... but I am not sure.  Someone who is more familiar with SOLR-8812
probably should comment.

Thanks,
Shawn

Re: How can I set the defaultOperator to be AND?

[Bastien Latard - MDPI AG]

Any news?

Remember:
If I add the following line to the schema.xml, even if I do a search 
'title:"test" OR author:"me"', it will returns documents matching 
'title:"test" AND author:"me"':



kr,
Bast

On 22/04/2016 13:22, Bastien Latard - MDPI AG wrote:

Yes Jan, I'm using edismax.

This is (a part of) my requestHandler:


 
false
   explicit
   10
   title,abstract,authors,doi
   edismax
   title^1.0  author^1.0
[...]

Is there anything I should do to improve/fix it?

Kind regards,
Bastien

On 22/04/2016 12:42, Jan Høydahl wrote:

Hi

Which query parser are you using? If using edismax yo may be hitting 
a recent bug concerning default operator and explicit boolean operators.


--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

22. apr. 2016 kl. 11.26 skrev Bastien Latard - MDPI AG 
:


Hi guys,

How can I set the defaultOperator to be AND?
If I add the following line to the schema.xml, even if I do a search 
'title:"test" OR author:"me"', it will returns documents matching 
'title:"test" AND author:"me"':



solr version: 6.0

I know that I can overwrite the query with q.op, but this is not 
that convenient...
I would need to write a complex query for a simple search '(a:x AND 
b:y) OR c:z'


Kind regards,
Bastien Latard
Web engineer
--
MDPI AG
Postfach, CH-4005 Basel, Switzerland
Office: Klybeckstrasse 64, CH-4057
Tel. +41 61 683 77 35
Fax: +41 61 302 89 18
E-mail:
lat...@mdpi.com
http://www.mdpi.com/





Kind regards,
Bastien Latard
Web engineer


Kind regards,
Bastien Latard
Web engineer
--
MDPI AG
Postfach, CH-4005 Basel, Switzerland
Office: Klybeckstrasse 64, CH-4057
Tel. +41 61 683 77 35
Fax: +41 61 302 89 18
E-mail:
lat...@mdpi.com
http://www.mdpi.com/

Solr Cloud Indexing Performance degrades suddenly

[preeti kumari]

Hi,

I have 2 solr cloud setups : Primary and secondary.
Both are importing data from same DB . I am using DIH to index data.

I was previously getting speed of 700docs/sec .
Now suddenly primary cluster is giving me a speed of 20docs/sec.
Same configs in Secondary is still giving 700 docs/sec speed.
Both cluster servers are having same server specifications.


I am looking for pointers where i can look for the reason for this degrade
in indexing speed.

Please help me out.

Thanks
Preeti

Re: The Streaming API (Solrj.io) : id must have DocValues?

[Reth RM]

Hi,

So, is the concern related to same field value being stored twice: with
stored=true and docValues=true? If that is the case, there is a jira
relevant to this, fixed[1]. If you upgrade to 5.5/6.0 version, it is
possible to read non-stored fields from docValues index., check out.


[1] https://issues.apache.org/jira/browse/SOLR-8220

On Mon, Apr 25, 2016 at 9:44 AM, sudsport s  wrote:

> Thanks Erik for reply,
>
> Since I was storing Id (its stored field) and after enabling docValues my
> guess is it will be stored in 2 places. also as per my understanding
> docValues are great when you have values which repeat. I am not sure how
> beneficial it would be for uniqueId field.
> I am looking at collection of few hundred billion documents , that is
> reason I really want to care about expense from design phase.
>
>
>
>
> On Sun, Apr 24, 2016 at 7:24 PM, Erick Erickson 
> wrote:
>
> > In a word, "yes".
> >
> > DocValues aren't particularly expensive, or expensive at all. The idea
> > is that when you sort by a field or facet, the field has to be
> > "uninverted" which builds the entire structure in Java's JVM (this is
> > when the field is _not_ DocValues).
> >
> > DocValues essentially serialize this structure to disk. So your
> > on-disk index size is larger, but that size is MMaped rather than
> > stored on Java's heap.
> >
> > Really, the question I'd have to ask though is "why do you care about
> > the expense?". If you have a functional requirement that has to be
> > served by returning the id via the /export handler, you really have no
> > choice.
> >
> > Best,
> > Erick
> >
> >
> > On Sun, Apr 24, 2016 at 9:55 AM, sudsport s 
> wrote:
> > > I was trying to use Streaming for reading basic tuple stream. I am
> using
> > > sort by id asc ,
> > > I am getting following exception
> > >
> > > I am using export search handler as per
> > > https://cwiki.apache.org/confluence/display/solr/Exporting+Result+Sets
> > >
> > > null:java.io.IOException: id must have DocValues to use this feature.
> > > at
> >
> org.apache.solr.response.SortingResponseWriter.getFieldWriters(SortingResponseWriter.java:241)
> > > at
> >
> org.apache.solr.response.SortingResponseWriter.write(SortingResponseWriter.java:120)
> > > at
> >
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:53)
> > > at
> > org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:742)
> > > at
> > org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:471)
> > > at
> >
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:214)
> > > at
> >
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> > > at
> >
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> > > at
> >
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> > > at
> >
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> > > at
> >
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> > > at
> >
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> > > at
> >
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> > > at
> > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> > > at org.eclipse.jetty.server.session.SessionHandler.doScope(
> > >
> > >
> > > does it make sense to enable docValues for unique field? How expensive
> > is it?
> > >
> > >
> > > if I have existing collection can I update schema and optimize
> > > collection to get docvalues enabled for id?
> > >
> > >
> > > --
> > >
> > > Thanks
> >
>

Re: concat 2 fields

[Reth RM]

It should be added to /update request handler. All the others that you have
listed here are search request handlers, you should add this one to /update
RH.

On Mon, Apr 25, 2016 at 12:12 PM, vrajesh  wrote:

> in my solr config there are many requestHandler so i am confused in which
> requestHandler i should add it. i have some requestHandlers with names
> "/select", "/export","/query","/browse" and much more.
> i want to use this new processor chain for all type of file formats.
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/concat-2-fields-tp4271760p4272564.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>

Re: concat 2 fields

[vrajesh]

in my solr config there are many requestHandler so i am confused in which
requestHandler i should add it. i have some requestHandlers with names
"/select", "/export","/query","/browse" and much more.
i want to use this new processor chain for all type of file formats.



--
View this message in context: 
http://lucene.472066.n3.nabble.com/concat-2-fields-tp4271760p4272564.html
Sent from the Solr - User mailing list archive at Nabble.com.