Re: Solr range search queries

[Paras Lehana]

Hi Niharika,

Range queries for string fields would work lexicographically and not
numeric I think. Read:
https://lucene.apache.org/solr/guide/6_6/the-standard-query-parser.html#TheStandardQueryParser-RangeSearches
.

If this is the case, [2 TO 5] will include 200 and [2 TO 20] will not
include 19.

On Tue, 10 Mar 2020 at 15:09, Niharika  wrote:

> hello,
>
> I have  two field declared in schema xml as
>
> * required='false' multiValued='true' 
>  required='false' multiValued='true'>
> *
>
> I want to generate a query to find all the result in specific range for
> longitude and latitude
>
> My query looks like
>
> *latitude:[47.010225655683485 TO 52.40241887397332] AND
> longitude:[-2.021484375004 TO 14.63378906252]*
>
> the problem here is:- i am not getting all the result i except, can anyone
> suggest me what I can do here and why it is wrong?
>
> PS:- I have already tried rounding of the decimals, I cannot change the
> type
> from string in schema.xml.
>
> Thanks & Regards
> Niharika
>
>
>
>
> --
> Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html
>


-- 
-- 
Regards,

*Paras Lehana* [65871]
Development Engineer, *Auto-Suggest*,
IndiaMART InterMESH Ltd,

11th Floor, Tower 2, Assotech Business Cresterra,
Plot No. 22, Sector 135, Noida, Uttar Pradesh, India 201305

Mob.: +91-9560911996
Work: 0120-4056700 | Extn:
*1196*

-- 
*
*

 

Re: Fw: SolrException in Solr 6.1.0

[Paras Lehana]

Hi Vishal,

Let's have a quick look into your logs.

org.apache.solr.common.SolrException: Exception writing document id
> WF204878828_42970103 to the index; possible analysis error.


If you were indexing something, check the documents syntax.


 Caused by: java.nio.file.FileSystemException:
> E:\SolrCloud\solr1\server\solr\workflows\data\index\_8suj.fdx: Insufficient
> system resources exist to complete the requested service.


Resource issues? Increase heap, check RAM and HDD utilization?



On Mon, 9 Mar 2020 at 10:54, vishal patel 
wrote:

> Anyone is looking my issue?
>
> Sent from Outlook
>
> 
> From: vishal patel 
> Sent: Friday, March 6, 2020 12:02 PM
> To: solr-user@lucene.apache.org
> Subject: SolrException in Solr 6.1.0
>
> I got below ERROR in Solr 6.1.0 log
>
> 2020-03-05 16:54:09.508 ERROR (qtp1239731077-468949) [c:workflows s:shard1
> r:core_node1 x:workflows] o.a.s.h.RequestHandlerBase
> org.apache.solr.common.SolrException: Exception writing document id
> WF204878828_42970103 to the index; possible analysis error.
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:181)
> at
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:68)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:939)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1094)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:720)
> at
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
> at
> org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:97)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:179)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:135)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:274)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:121)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:239)
> at
> org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:157)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:186)
> at
> org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:107)
> at org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:54)
> at
> org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:69)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2036)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:657)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:464)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:518)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
> at org.eclipse.jetty.io
> .AbstractConnection$ReadCallback.succeeded(AbstractConne

JSP support not configured in Solr 8.3.0

[vishal patel]

I put the JSP in \server\solr-webapp\webapp\test.jsp. When I hit in browser 
using http://172.178.170.175:7999/solr/test.jsp, I got HTTP ERROR 500 Problem 
accessing /solr/mem.jsp. Reason:JSP support not configured.

Is any jar required in \server\lib\? OR any configuration for that?

Regards,
Vishal

Sent from Outlook

Re: JSP support not configured in Solr 8.3.0

[Jörn Franke]

It is better to have a dedicated frontend for Solr on a dedicated server. For 
security reasons, Solr becomes more and more locked up and it is also 
discouraged to put own web applications on it. 

> Am 11.03.2020 um 10:03 schrieb vishal patel :
> 
> 
> I put the JSP in \server\solr-webapp\webapp\test.jsp. When I hit in browser 
> using http://172.178.170.175:7999/solr/test.jsp, I got HTTP ERROR 500 Problem 
> accessing /solr/mem.jsp. Reason:JSP support not configured.
> 
> Is any jar required in \server\lib\? OR any configuration for that?
> 
> Regards,
> Vishal
> 
> Sent from Outlook

Where fq, field sort and rerank query, the score of rerank is not correct

[Dawn]

GetDocListNC method in the SolrIndexSearcher class, Query is converted to 
BooleanQuery when fq queries are available.

Has a call query instanceof RankQuery below, which will never be true.

The score of rerank is not correct.

Do you need to add a loop to the query type?


ProcessedFilter pf = getProcessedFilter(cmd.getFilter(), cmd.getFilterList());
if (pf.filter != null) {
  query = new BooleanQuery.Builder().add(query, Occur.MUST).add(pf.filter, 
Occur.FILTER).build();
}
if (cmd.getSort() != null && query instanceof RankQuery == false && 
(cmd.getFlags() & GET_SCORES) != 0) {
  TopFieldCollector.populateScores(topDocs.scoreDocs, this, query);
}



Thanks

Re: Atomic Update and Optimization and segments

[Erick Erickson]

ExpungeDelete only deletes segments with > 10% deleted documents. Since you’re 
using Solr 8.4, you can use an optimize and that’ll get rid of all your 
documents.

However, none of this is really relevant if you only change a single doc. 
Deleting a field only affects that single document, actually the new copy of 
that doc. The old copy is still there in an old segment until it’s merged away.

All that said, I’d strongly urge you to consider more sharding. A 1T index on a 
single replica is pushing the bounds of operational stability. Solr will handle 
this, and I’ve seen larger indexes. But consider a full recovery. To copy the 
entire index, you’ll have to push 1T to the new replica, which will just take 
time and consume bandwidth.

FWIW,
Erick

> On Mar 10, 2020, at 07:28, Kayak28  wrote:
> 
> Hello, Community:
> 
> Currently, my index grows up to almost 1T, and I would like to minimize my
> index.
> 
> I know I have a few fields that are not used or rarely used, so I want to
> delete them.
> I have tried to delete these fields by the atomic update, sending the
> following JSON for example.
> {
> "id":"1",
> "text":{"set": null }
> }
> As a result, it generated a new segment, so segment count increased +1,
> index size became bigger, and mac doc is increased +1.
> I have expected this result, but my goal is to minimize my index, so I sent
> an expungeDeleted request and optimize request, expecting to reduce the
> index size and segment count.
> But, the segment did not reduce, the index size did not change, and max doc
> did not change.
> 
> As of Solr 8.4.1, is there any way to minimize segment count, index size
> and max doc after atomic-updating?
> 
> Sincerely,
> Kaya Ota

Index-performance degrade when using NestPathField

[Marvin Bredal Lillehaug]

Hi!
We have a index with about fifty million documents with five child
documents in average.
The schema has been a _root_-only schema for some time, but we now tried
changing to _nest_path_/NestPathField.
When reindexing the data with the new schema it takes almost twice as long
to index all documents.

I tried looking at the code for NestPathField, and don't really understand
what could be the cause of this. Does anyone have any experience with this?

Our document structure has only one level and one type of child, so we do
not really need _nest_path_, I guess? Any input on this would also be
appreciated.

-- 
Kind regards,
Marvin B. Lillehaug

Re: Sorting on an empty filter

[Stephen Lewis Bianamara]

Hi Folks,

Has anyone had a chance to consider this question yet?

Thanks!
Stephen

On Tue, Mar 3, 2020 at 2:28 PM Stephen Lewis Bianamara <
stephen.bianam...@gmail.com> wrote:

> Hi SOLR Community,
>
> I've observed while hosting a SOLR 6.6 installation that if I issue a
> query where the filter query returns an empty set but there is a sort
> associated with it, the query takes an extended time to execute over the
> query with only the filter query and no sort associated to it. This
> suggests to me that SOLR is sorting in parallel with or even before the
> filter query. However, it seems to me like the query should generally
> filter first and then sort, or perhaps have an option to do so. I don't
> currently see any way of making that happen.
>
> What motivates my question today is that the sort being used is typically
> quite expensive if applied to all documents in a shard or cluster, but it
> seems to me that the filter should precede the sort for exactly this reason.
>
> So my questions for the community:
>
>- Am I correct that the sort happens even when the filter query result
>is empty?
>- Is it possible to achieve the desired behavior of only sorting on
>results of the filter?
>- Is this behavior changed in any later versions of SOLR?
>- If none of these are so, is there a Jira issue tracking this
>capability?
>
> Thanks!
> Stephen
>

Re: "SolrCore Initialization Failures" in the Solr's current UI, but not in the original UI

[Ryan W]

I upgraded to v7.7.2 and am not having this issue anymore.

On Mon, Mar 9, 2020 at 10:04 AM Ryan W  wrote:

> I am using v6.6.6, which is the most recent release in the v6 branch, and
> is the branch commonly used with my app.  I have tried on Chrome, Firefox
> and Internet Explorer, and I see the same problem in all three.  Albeit it
> seems to be a minor problem.
>
> On Thu, Mar 5, 2020 at 4:34 PM Jan Høydahl  wrote:
>
>> v6.6.0 is from 2017 and not supported anymore. You are really encouraged
>> to upgrade!
>>
>> Are you by any chance using Internet Explorer? (See
>> https://stackoverflow.com/questions/56262704/solr-solrcore-initialization-failures-core-error
>> )
>>
>> Jan
>>
>> > 5. mar. 2020 kl. 22:03 skrev Ryan W :
>> >
>> > Hi all,
>> >
>> > On my dev server, in the Solr admin UI, I see...
>> >
>> >SolrCore Initialization Failures
>> >{{core}}: {{error}}
>> >Please check your logs for more information
>> >{{exception.msg}}
>> >
>> > These appear to be template variables, but they are never populated.
>> They
>> > just dump to the screen.  There is nothing useful in the log.  If I
>> click
>> > over to the "original UI" via the link in the upper right corner of the
>> > screen, there is no error displayed and all seems to be well.
>> Meanwhile,
>> > Apache Solr seems to be functioning OK.  So this does not appear to be a
>> > significant problem, but still a little annoying.
>> >
>> > I am trying to get the dev server to perform the same way as the staging
>> > server, but at least in the "current UI," I get these errors in my dev
>> > server.  I have tried to compared the two installs very carefully, but
>> > can't find any discrepancy between staging and dev.
>> >
>> > Both servers run...
>> > Solr 6.6.6
>> > RHEL 7
>> >
>> > Thank you,
>> > Ryan
>>
>>

Restrict access to admin interface by IP address in Solr 7.7.2

[Ryan W]

What options do I have for restricting access to the admin UI by IP
address?  In Solr 6.x, this could be done with an IPAccessHandler in
jetty.xml, but this doesn't seem to work in Solr 7.x.  Is there some other
way to do it?

Thanks!

RE: No files to download for index generation

[Oakley, Craig (NIH/NLM/NCBI) [C]]

I wanted to ask *again* whether anyone has any insight regarding this message

There seem to have been several people asking the question on this forum 
(Markus Jelsma on 8/23/19, Akreeti Agarwal on 12/27/19 and Vadim Ivanov on 
12/29/19)

The only response I have seen was five words from Erick Erickson on 12/27/19: 
"Not sure about that one"

Could someone please clarify what this error means?

The wording could be interpreted as a benign "I found that there was nothing 
which needed to be done after all"; but were that to be the meaning of this 
error, why would it be flagged as an ERROR rather than as INFO or WARN ?


-Original Message-
From: Oakley, Craig (NIH/NLM/NCBI) [C]  
Sent: Monday, June 10, 2019 9:57 AM
To: solr-user@lucene.apache.org
Subject: RE: No files to download for index generation

Does anyone yet have any insight on interpreting the severity of this message?

-Original Message-
From: Oakley, Craig (NIH/NLM/NCBI) [C]  
Sent: Tuesday, June 04, 2019 4:07 PM
To: solr-user@lucene.apache.org
Subject: No files to download for index generation

We have occasionally been seeing an error such as the following:
2019-06-03 23:32:45.583 INFO  (indexFetcher-45-thread-1) [   ] 
o.a.s.h.IndexFetcher Master's generation: 1424625
2019-06-03 23:32:45.583 INFO  (indexFetcher-45-thread-1) [   ] 
o.a.s.h.IndexFetcher Master's version: 1559619115480
2019-06-03 23:32:45.583 INFO  (indexFetcher-45-thread-1) [   ] 
o.a.s.h.IndexFetcher Slave's generation: 1424624
2019-06-03 23:32:45.583 INFO  (indexFetcher-45-thread-1) [   ] 
o.a.s.h.IndexFetcher Slave's version: 1559619050130
2019-06-03 23:32:45.583 INFO  (indexFetcher-45-thread-1) [   ] 
o.a.s.h.IndexFetcher Starting replication process
2019-06-03 23:32:45.587 ERROR (indexFetcher-45-thread-1) [   ] 
o.a.s.h.IndexFetcher No files to download for index generation: 1424625

Is that last line actually an error as in "there SHOULD be files to download, 
but there are none"?

Or is it simply informative as in "there are no files to download, so we are 
all done here"?

Graph Parser Bug

[sambasivarao giddaluri]

Hi All ,

i think this is bug in graph query parser if we pass additional brackets it
throws parser exception and this is blocking our project can anyone suggest
how to handle we are using solr 8.2.
ex:

({!graph from=parentId to=parentId traversalFilter='type:parent'
returnRoot=false}(childId.name:foo))


My use case multiple OR , AND conditions
EX:
({!graph from=parentId to=parentId traversalFilter='type:parent'
returnRoot=false}(childId.name:foo OR child.id:(1 2 4) )) AND ({!graph
from=parentId to=parentId traversalFilter='type:parent' returnRoot=false}
grandchild.id:1)

Re: Restrict access to admin interface by IP address in Solr 7.7.2

[Jan Høydahl]

That should still work if you follow Jetty’s procedures for the version of 
Jetty you’re at.
In 8.5 this will be much simpler: 
https://issues.apache.org/jira/browse/SOLR-14136

Jan

> 11. mar. 2020 kl. 20:39 skrev Ryan W :
> 
> What options do I have for restricting access to the admin UI by IP
> address?  In Solr 6.x, this could be done with an IPAccessHandler in
> jetty.xml, but this doesn't seem to work in Solr 7.x.  Is there some other
> way to do it?
> 
> Thanks!