Different results for comma and whitespace separated query string using eDisMax Query Parser
Hi,
different results are obtained for a query separated by comma and one separated
by whitespace,
"q":"foo,bar",
"q":"foo bar",
although solr.StandardTokenizerFactory is utilized. The eDisMax Query Parser is
used.
Fields of interest are determined by the 'qf' parameter.
"defType":"edismax",
"qf":"STREET_NAME COMMPART_NAME",
The different results are also reflected within the parsedquery debug output:
Whitespace:
"rawquerystring":"foo bar",
"querystring":"foo bar",
"parsedquery":"(+(DisjunctionMaxQuery((STREET_NAME:foo |
COMMPART_NAME:foo)) DisjunctionMaxQuery((STREET_NAME:bar |
COMMPART_NAME:bar/no_coord",
"parsedquery_toString":"+((STREET_NAME:foo | COMMPART_NAME:foo)
(STREET_NAME:bar | COMMPART_NAME:bar))",
"explain":{},
"QParser":"ExtendedDismaxQParser",
Comma:
"rawquerystring":"foo,bar",
"querystring":"foo,bar",
"parsedquery":"(+DisjunctionMaxQuery(((STREET_NAME:foo STREET_NAME:bar) |
(COMMPART_NAME:foo COMMPART_NAME:bar/no_coord",
"parsedquery_toString":"+((STREET_NAME:foo STREET_NAME:bar) |
(COMMPART_NAME:foo COMMPART_NAME:bar))",
"explain":{},
"QParser":"ExtendedDismaxQParser",
The way I understand the standard tokenizer, both query strings should be split
in the same way,
treating whitespace and punctuation as delimiters.
However, obviously, different separators result in different evaluations.
In the first case, the score values of both DisjunctionMaxQuery evaluations are
added together.
In the second case, only one (the maximum) of these score values is returned.
Any ideas what I am missing here?
I am using Solr 6.2.0.
Configuration details:
and
Thanks and all the best,
Frank
--
Frank Zirkelbach
LEW Verteilnetz GmbH (LVN), GIS/NIS
Schaezlerstraße 3, 86150 Augsburg
Tel. intern: 71-1379
Tel. extern: +49-821-328-1379
Fax extern: +49-821-328-1360
mailto:frank.zirkelb...@lew-verteilnetz.de
www.lew-verteilnetz.de
Vorsitzender des Aufsichtsrats: Dr. Markus Litpher;
Geschäftsführer: Manfred Lux, Theo Schmidtner, Eugen Wiedemann
Sitz der Gesellschaft: Augsburg; USt-IdNr. DE240432124
Handelsregister HRB 20929, Registergericht: Amtsgericht Augsburg
Re: Heatmap in JSON facet API
I've built query as described in https://cwiki.apache.org/confluence/x/ZYDxAQ";>Heatmap Faceting, but I would like to get same results using JSON facet API 2016-10-30 15:24 GMT+03:00 GW : > If we are talking about the same kind of heat maps you might want to look > at the TomTom map API for a quick and dirty yet solid solution. Just supply > a whack of coordinates and let TomTom do the work. The Heat maps will zoom > in and de-cluster. > > Example below. > > http://www.frogclassifieds.com/tomtom/markers-clustering.html > > > On 28 October 2016 at 09:05, Никита Веневитин > wrote: > > > Hi! > > Is it possible to use JSON facet API to get heatmaps? > > >
RE: [E] Re: Questions about Disk space Usage
Thank you all for your comments and help - I kept the last days' worth of files form the /tmp folder and removed the rest - without any problems or difficulties. Sas -Original Message- From: Walter underwood [mailto:wun...@wunderwood.org] Sent: Saturday, October 29, 2016 1:10 PM To: solr-user@lucene.apache.org Subject: [E] Re: Questions about Disk space Usage If it works the way I think it does, an empty segment should take the same amount of time to read in as a full segment, but zero time to write out. wunder > On Oct 29, 2016, at 9:21 AM, Erick Erickson wrote: > > I would also expect a totally empty segment to be merged very quickly > as the percent deleted documents weighs heavily when determining > whether to merge a segment but that's based on principle, not deep > code knowledge. > > Best, > Erick > >> On Fri, Oct 28, 2016 at 6:02 PM, Walter Underwood >> wrote: >> After the merge. That is what merges do, clean up segments. >> >> I expect it is very rare for a segment to be 100% deleted docs, so it >> isn’t worth handling that case. >> >> wunder >> Walter Underwood >> wun...@wunderwood.org >> http://observer.wunderwood.org/ (my blog) >> >> >>> On Oct 28, 2016, at 5:54 PM, Alexandre Rafalovitch >>> wrote: >>> >>> Don't the segment that only has deleted documents just gets dropped? >>> Or does it get dropped _after_ the merge and therefore still sits >>> around? >>> >>> Regards, >>> Alex. >>> >>> Solr Example reading group is starting November 2016, join us at >>> http://j.mp/SolrERG Newsletter and resources for Solr beginners and >>> intermediates: >>> http://www.solr-start.com/ >>> >>> On 29 October 2016 at 08:53, Walter Underwood wrote: It is normal for disk usage to double. Under controlled circumstances, it can triple, but that probably won’t happen. This is the second time today that I’ve sent this information to the list. It can use nearly 2X the space whenever the largest segment(s) are merged, especially if there are only a few smaller segments. In order to use 3X the space, you need to: 1. Disable merging. 2. Delete all the documents. 3. Add all the documents. 4. Enable merging. This causes one complete set of segments that are 100% deletes, one set that is 0% deletes, then the merge creates another set that is 0% deletes. During the merge, the old files remain while the new one is created. wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Oct 28, 2016, at 2:41 PM, Alexandre Rafalovitch > wrote: > > 2) Is probably a merge operation. Lucene index segments are not > rewritable in place, so the merge creates a new file, does > everything to it, then switches to it. > > I remember the number was that the space could temporarily triple > (?!?) though that may have been before the tiered merge policy. > > 3) It should be safe to delete old log files. It is standard log4j stuff. > > > Solr Example reading group is starting November 2016, join us at > http://j.mp/SolrERG Newsletter and resources for Solr beginners > and intermediates: > http://www.solr-start.com/ > > > On 29 October 2016 at 06:55, Jamal, Sarfaraz > wrote: >> Hi Guys, >> >> I am currently investigating an instance of Solr's Disk space usage and >> I had a few questions I thought you guys might be able to help answer. >> >> First Question >> * There is 30 gb's worth of autosuggest data in the /tmp folder. >> Each file is half of a gigabyte Is it safe to delete those files? >> >> Second Question >> Also, we notice that at times the disk runs down to only having a few >> gigabytes available, and then goes back to having more space. (the index >> file literally grows and then shrinks). >> >> Third Question >> Is it also safe to delete the log files? >> >> We run a database indexer on a set interval, perhaps that is relevant to >> this discussion. >> >> Sas >>
Re: Error: Strong key gen and multiprime gen require at least 1024-bit keysize
Definitely a valid JIRA. It may choose 512 default but shouldn't be hard
coded. There must be a way to pass on required lenght
Adnan
On Wed, Oct 5, 2016 at 9:02 PM, Erick Erickson
wrote:
> Sure seems like a JIRA to me. I have no clue why 512 was chosen in
> the first place though.
>
> Or you could post the same question on dev list first.
>
> But this is an appropriate JIRA I think.
>
> Erick
>
> On Wed, Oct 5, 2016 at 10:43 AM, Martini, Jeremy (CGI Federal)
> wrote:
> > Hi,
> >
> >
> >
> > I'm looking at filing an issue in JIRA, but wanted to first make sure my
> > issue would be a valid change.
> >
> >
> >
> > In order to configure our dataSource without requiring a plaintext
> password
> > in the configuration file, we extended JdbcDataSource to create our own
> > custom implementation. Our dataSource config now looks something like
> this:
> >
> >
> >
> > > url="jdbc:oracle:thin:@db-host-machine:1521:tst1" user="testuser"
> > password="{ENC}{1.1}1ePOfWcbOIU056gKiLTrLw=="/>
> >
> >
> >
> > We are using the RSA JSAFE Crypto-J libraries for encrypting/decrypting
> the
> > password. However, this seems to cause an issue when we try use Solr in a
> > Cloud Configuration (using Zookeeper). The error is "Strong key gen and
> > multiprime gen require at least 1024-bit keysize." Full log attached.
> >
> >
> >
> > This seems to be due to the hard-coded value of 512 in the
> > org.apache.solr.util.CryptoKeys$RSAKeyPair class:
> >
> >
> >
> > public RSAKeyPair() {
> >
> > KeyPairGenerator keyGen = null;
> >
> > try {
> >
> > keyGen = KeyPairGenerator.getInstance("RSA");
> >
> > } catch (NoSuchAlgorithmException e) {
> >
> > throw new SolrException(SolrException.ErrorCode.SERVER_ERROR,
> e);
> >
> > }
> >
> > keyGen.initialize(512);
> >
> >
> >
> > I pulled down the Solr code, changed the hard-coded value to 1024,
> rebuilt
> > it, and this now everything seems to work great.
> >
> >
> >
> > Would this be a valid code change to request? I'm happy to create the
> JIRA
> > ticket and supply a patch file.
> >
> >
> >
> > Thanks,
> >
> > Jeremy
>
--
Regards,
*Adnan Yaqoob*
solrj Https problem
I followed the steps to make the solr SSL enabled. I'm able to hit solr at:
https://localhost:8985/solr/problem/select?indent=on&q=*:*&wt=json And for
accessing it through Solr Client I created it as
follows:System.setProperty("javax.net.ssl.keyStore",
"/path/to/solr/server/etc/solr-ssl.keystore.jks");
System.setProperty("javax.net.ssl.keyStorePassword", "secret");
System.setProperty("javax.net.ssl.trustStore",
"/path/to/solr/server/etc/solr-ssl.keystore.jks");
System.setProperty("javax.net.ssl.trustStorePassword", "secret");
return new CloudSolrClient.Builder()
.withZkHost(solrConfig.getConnectString()).build(); The path to the
keystore and truststore is correct. However I still get the following
error:Caused by: javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) ~[na:1.8.0_45]
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1937) ~[na:1.8.0_45]
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302) ~[na:1.8.0_45]
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296) ~[na:1.8.0_45]
at
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1478)
~[na:1.8.0_45]
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:212)
~[na:1.8.0_45]
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979) ~[na:1.8.0_45]
at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
~[na:1.8.0_45]
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1050)
~[na:1.8.0_45]
at
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
~[na:1.8.0_45]
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391)
~[na:1.8.0_45]
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375)
~[na:1.8.0_45]
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543)
~[httpclient-4.5.1.jar:4.5.1]
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
~[httpclient-4.5.1.jar:4.5.1]
at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
~[httpclient-4.5.1.jar:4.5.1]
at
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
~[httpclient-4.5.1.jar:4.5.1]
at
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
~[httpclient-4.5.1.jar:4.5.1]
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
~[httpclient-4.5.1.jar:4.5.1]
at
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
~[httpclient-4.5.1.jar:4.5.1]
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
~[httpclient-4.5.1.jar:4.5.1]
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
~[httpclient-4.5.1.jar:4.5.1]
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
~[httpclient-4.5.1.jar:4.5.1]
at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:495)
~[solr-solrj-6.1.0.jar:6.1.0 4726c5b2d2efa9ba160b608d46a977d0a6b83f94 -
jpountz - 2016-06-13 09:46:59]
... 26 common frames omitted
Caused by: sun.security.validator.ValidatorException: PKIX path building
failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
~[na:1.8.0_45]
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
~[na:1.8.0_45]
at sun.security.validator.Validator.validate(Validator.java:260) ~[na:1.8.0_45]
at
sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
~[na:1.8.0_45]
at
sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
~[na:1.8.0_45]
at
sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
~[na:1.8.0_45]
at
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1460)
~[na:1.8.0_45]
... 44 common frames omitted
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable
to find valid certification path to requested target
at
sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145)
~[na:1.8.0_45]
at
sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:131)
~[na:1.8.0_45]
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
~[na:1.8.0_45]
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)
~[na:1.8.0_45]
... 50 common frames omitted What am I missing?
ThanksSandeep
Re: Error: Strong key gen and multiprime gen require at least 1024-bit keysize
See: https://issues.apache.org/jira/browse/SOLR-9609
Not quite sure when I'll get to it though...
Erick
On Mon, Oct 31, 2016 at 8:22 AM, Adnan Yaqoob wrote:
> Definitely a valid JIRA. It may choose 512 default but shouldn't be hard
> coded. There must be a way to pass on required lenght
>
> Adnan
>
> On Wed, Oct 5, 2016 at 9:02 PM, Erick Erickson
> wrote:
>
>> Sure seems like a JIRA to me. I have no clue why 512 was chosen in
>> the first place though.
>>
>> Or you could post the same question on dev list first.
>>
>> But this is an appropriate JIRA I think.
>>
>> Erick
>>
>> On Wed, Oct 5, 2016 at 10:43 AM, Martini, Jeremy (CGI Federal)
>> wrote:
>> > Hi,
>> >
>> >
>> >
>> > I'm looking at filing an issue in JIRA, but wanted to first make sure my
>> > issue would be a valid change.
>> >
>> >
>> >
>> > In order to configure our dataSource without requiring a plaintext
>> password
>> > in the configuration file, we extended JdbcDataSource to create our own
>> > custom implementation. Our dataSource config now looks something like
>> this:
>> >
>> >
>> >
>> > > > url="jdbc:oracle:thin:@db-host-machine:1521:tst1" user="testuser"
>> > password="{ENC}{1.1}1ePOfWcbOIU056gKiLTrLw=="/>
>> >
>> >
>> >
>> > We are using the RSA JSAFE Crypto-J libraries for encrypting/decrypting
>> the
>> > password. However, this seems to cause an issue when we try use Solr in a
>> > Cloud Configuration (using Zookeeper). The error is "Strong key gen and
>> > multiprime gen require at least 1024-bit keysize." Full log attached.
>> >
>> >
>> >
>> > This seems to be due to the hard-coded value of 512 in the
>> > org.apache.solr.util.CryptoKeys$RSAKeyPair class:
>> >
>> >
>> >
>> > public RSAKeyPair() {
>> >
>> > KeyPairGenerator keyGen = null;
>> >
>> > try {
>> >
>> > keyGen = KeyPairGenerator.getInstance("RSA");
>> >
>> > } catch (NoSuchAlgorithmException e) {
>> >
>> > throw new SolrException(SolrException.ErrorCode.SERVER_ERROR,
>> e);
>> >
>> > }
>> >
>> > keyGen.initialize(512);
>> >
>> >
>> >
>> > I pulled down the Solr code, changed the hard-coded value to 1024,
>> rebuilt
>> > it, and this now everything seems to work great.
>> >
>> >
>> >
>> > Would this be a valid code change to request? I'm happy to create the
>> JIRA
>> > ticket and supply a patch file.
>> >
>> >
>> >
>> > Thanks,
>> >
>> > Jeremy
>>
>
>
>
> --
> Regards,
> *Adnan Yaqoob*
Getting NullPointerException in an attempt to boost query result by date
Hi,
I am trying to construct a timestamp-boosted query comprising two weighted
fields: "title" and "body":
{!boost b=recip(ms(NOW/HOUR,submit_date),3.16e-11,1,1)}
{!type=dismax qf='title^10 body^1' v=$term}
$term=apple
I expect the given example query provided above to search fields "title"
and "body" using keyword "apple" and adjust the order of the results by the
submission date "submit_date".
However, the query just throws the NullPointerException exception: [1].
Could you please help me out with this issue?
I am using Solr 4.10.3+cdh5.8.2+434 - part of Cloudera 5.8.2 package.
Best,
Gin
[1] the exception:
java.lang.NullPointerException at
org.apache.lucene.queries.function.BoostedQuery.hashCode(BoostedQuery.java:215)
at org.apache.lucene.search.BooleanClause.hashCode(BooleanClause.java:99)
at java.util.AbstractList.hashCode(AbstractList.java:541) at
org.apache.lucene.search.BooleanQuery.hashCode(BooleanQuery.java:656) at
org.apache.solr.search.QueryResultKey.(QueryResultKey.java:47) at
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1347)
at
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:518)
at
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:485)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2025) at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:918)
at
org.apache.solr.servlet.SolrDispatchFilter.httpSolrCall(SolrDispatchFilter.java:481)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:260)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:255)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.solr.servlet.SolrHadoopAuthenticationFilter$2.doFilter(SolrHadoopAuthenticationFilter.java:408)
at
org.apache.hadoop.security.authentication.server.AuthenticationFilter.doFilter(AuthenticationFilter.java:622)
at
org.apache.hadoop.security.token.delegation.web.DelegationTokenAuthenticationFilter.doFilter(DelegationTokenAuthenticationFilter.java:291)
at
org.apache.hadoop.security.authentication.server.AuthenticationFilter.doFilter(AuthenticationFilter.java:574)
at
org.apache.solr.servlet.SolrHadoopAuthenticationFilter.doFilter(SolrHadoopAuthenticationFilter.java:413)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.solr.servlet.HostnameFilter.doFilter(HostnameFilter.java:86)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:861)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:620)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:745)
Using a library from blob-store without "add-runtimelib"
Hi! I'm wondering if there's any possibility to tell the current collection to use a library stored in the blobstore using the solrconfig.xml instead of having to do a /config request. Same way local filesystem libraries are added in solrconfig, it could exist for blobstore libraries. Since it's stored as an overlay property and merge in memory, not loaded until first request I think it's a reasonable approach or am I missing something? Thanks!
Re: Getting NullPointerException in an attempt to boost query result by date
how’d you set “$term” - the correct way would be &term=apple on the Solr
request.
> On Oct 31, 2016, at 2:07 PM, Gintautas Sulskus
> wrote:
>
> Hi,
>
> I am trying to construct a timestamp-boosted query comprising two weighted
> fields: "title" and "body":
>
> {!boost b=recip(ms(NOW/HOUR,submit_date),3.16e-11,1,1)}
> {!type=dismax qf='title^10 body^1' v=$term}
>
> $term=apple
>
> I expect the given example query provided above to search fields "title"
> and "body" using keyword "apple" and adjust the order of the results by the
> submission date "submit_date".
>
> However, the query just throws the NullPointerException exception: [1].
> Could you please help me out with this issue?
>
> I am using Solr 4.10.3+cdh5.8.2+434 - part of Cloudera 5.8.2 package.
>
> Best,
> Gin
>
> [1] the exception:
> java.lang.NullPointerException at
> org.apache.lucene.queries.function.BoostedQuery.hashCode(BoostedQuery.java:215)
> at org.apache.lucene.search.BooleanClause.hashCode(BooleanClause.java:99)
> at java.util.AbstractList.hashCode(AbstractList.java:541) at
> org.apache.lucene.search.BooleanQuery.hashCode(BooleanQuery.java:656) at
> org.apache.solr.search.QueryResultKey.(QueryResultKey.java:47) at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1347)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:518)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:485)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2025) at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:918)
> at
> org.apache.solr.servlet.SolrDispatchFilter.httpSolrCall(SolrDispatchFilter.java:481)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:260)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:255)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.solr.servlet.SolrHadoopAuthenticationFilter$2.doFilter(SolrHadoopAuthenticationFilter.java:408)
> at
> org.apache.hadoop.security.authentication.server.AuthenticationFilter.doFilter(AuthenticationFilter.java:622)
> at
> org.apache.hadoop.security.token.delegation.web.DelegationTokenAuthenticationFilter.doFilter(DelegationTokenAuthenticationFilter.java:291)
> at
> org.apache.hadoop.security.authentication.server.AuthenticationFilter.doFilter(AuthenticationFilter.java:574)
> at
> org.apache.solr.servlet.SolrHadoopAuthenticationFilter.doFilter(SolrHadoopAuthenticationFilter.java:413)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.apache.solr.servlet.HostnameFilter.doFilter(HostnameFilter.java:86)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:861)
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:620)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
> at java.lang.Thread.run(Thread.java:745)
Re: Getting NullPointerException in an attempt to boost query result by date
Hi Erik,
I have defined the query as SearchHandler:
{!boost b=recip(ms(NOW/HOUR, submit_date),3.16e-11,1,1)}
{!type=dismax qf='title^10 body^5 body^1' v=$term}
The handler is then invoked with the following url:
/solr/core/testSearch?term=apple
The handler works if I comment out the date-boost line:
"{!boost b=recip(ms(NOW/HOUR, submit_date),3.16e-11,1,1)}"
Gin
Best Wishes,
Gintautas Sulskus
On Mon, Oct 31, 2016 at 6:15 PM, Erik Hatcher
wrote:
> how’d you set “$term” - the correct way would be &term=apple on the Solr
> request.
>
>
> > On Oct 31, 2016, at 2:07 PM, Gintautas Sulskus <
> gintautas.suls...@gmail.com> wrote:
> >
> > Hi,
> >
> > I am trying to construct a timestamp-boosted query comprising two
> weighted
> > fields: "title" and "body":
> >
> > {!boost b=recip(ms(NOW/HOUR,submit_date),3.16e-11,1,1)}
> > {!type=dismax qf='title^10 body^1' v=$term}
> >
> > $term=apple
> >
> > I expect the given example query provided above to search fields "title"
> > and "body" using keyword "apple" and adjust the order of the results by
> the
> > submission date "submit_date".
> >
> > However, the query just throws the NullPointerException exception: [1].
> > Could you please help me out with this issue?
> >
> > I am using Solr 4.10.3+cdh5.8.2+434 - part of Cloudera 5.8.2 package.
> >
> > Best,
> > Gin
> >
> > [1] the exception:
> > java.lang.NullPointerException at
> > org.apache.lucene.queries.function.BoostedQuery.
> hashCode(BoostedQuery.java:215)
> > at org.apache.lucene.search.BooleanClause.hashCode(
> BooleanClause.java:99)
> > at java.util.AbstractList.hashCode(AbstractList.java:541) at
> > org.apache.lucene.search.BooleanQuery.hashCode(BooleanQuery.java:656) at
> > org.apache.solr.search.QueryResultKey.(QueryResultKey.java:47) at
> > org.apache.solr.search.SolrIndexSearcher.getDocListC(
> SolrIndexSearcher.java:1347)
> > at
> > org.apache.solr.search.SolrIndexSearcher.search(
> SolrIndexSearcher.java:518)
> > at
> > org.apache.solr.handler.component.QueryComponent.
> process(QueryComponent.java:485)
> > at
> > org.apache.solr.handler.component.SearchHandler.handleRequestBody(
> SearchHandler.java:218)
> > at
> > org.apache.solr.handler.RequestHandlerBase.handleRequest(
> RequestHandlerBase.java:135)
> > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2025) at
> > org.apache.solr.servlet.SolrDispatchFilter.execute(
> SolrDispatchFilter.java:918)
> > at
> > org.apache.solr.servlet.SolrDispatchFilter.httpSolrCall(
> SolrDispatchFilter.java:481)
> > at
> > org.apache.solr.servlet.SolrDispatchFilter.doFilter(
> SolrDispatchFilter.java:260)
> > at
> > org.apache.solr.servlet.SolrDispatchFilter.doFilter(
> SolrDispatchFilter.java:255)
> > at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> ApplicationFilterChain.java:235)
> > at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(
> ApplicationFilterChain.java:206)
> > at
> > org.apache.solr.servlet.SolrHadoopAuthenticationFilter$2.doFilter(
> SolrHadoopAuthenticationFilter.java:408)
> > at
> > org.apache.hadoop.security.authentication.server.
> AuthenticationFilter.doFilter(AuthenticationFilter.java:622)
> > at
> > org.apache.hadoop.security.token.delegation.web.
> DelegationTokenAuthenticationFilter.doFilter(
> DelegationTokenAuthenticationFilter.java:291)
> > at
> > org.apache.hadoop.security.authentication.server.
> AuthenticationFilter.doFilter(AuthenticationFilter.java:574)
> > at
> > org.apache.solr.servlet.SolrHadoopAuthenticationFilter.doFilter(
> SolrHadoopAuthenticationFilter.java:413)
> > at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> ApplicationFilterChain.java:235)
> > at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(
> ApplicationFilterChain.java:206)
> > at org.apache.solr.servlet.HostnameFilter.doFilter(
> HostnameFilter.java:86)
> > at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> ApplicationFilterChain.java:235)
> > at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(
> ApplicationFilterChain.java:206)
> > at
> > org.apache.catalina.core.StandardWrapperValve.invoke(
> StandardWrapperValve.java:233)
> > at
> > org.apache.catalina.core.StandardContextValve.invoke(
> StandardContextValve.java:191)
> > at
> > org.apache.catalina.core.StandardHostValve.invoke(
> StandardHostValve.java:127)
> > at
> > org.apache.catalina.valves.ErrorReportValve.invoke(
> ErrorReportValve.java:103)
> > at
> > org.apache.catalina.core.StandardEngineValve.invoke(
> StandardEngineValve.java:109)
> > at
> > org.apache.catalina.connector.CoyoteAdapter.service(
> CoyoteAdapter.java:293)
> > at
> > org.apache.coyote.http11.Http11Processor.process(
> Http11Processor.java:861)
> > at
> > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.
> process(Http11Protocol.java:620)
> > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(
> JIoEndpoint.java:489)
> > at java.lang.Thread.run(Thread.java:745)
>
>
RE: Getting NullPointerException in an attempt to boost query result by date
Does it work if you comment out any of the two local param queries? I'd doubt
passing two sets of local params ever worked at all without wrapping one in the
other.
-Original message-
> From:Gintautas Sulskus
> Sent: Monday 31st October 2016 21:19
> To: solr-user@lucene.apache.org
> Subject: Re: Getting NullPointerException in an attempt to boost query result
> by date
>
> Hi Erik,
>
> I have defined the query as SearchHandler:
>
>
>
>
> {!boost b=recip(ms(NOW/HOUR, submit_date),3.16e-11,1,1)}
> {!type=dismax qf='title^10 body^5 body^1' v=$term}
>
>
>
>
> The handler is then invoked with the following url:
>
> /solr/core/testSearch?term=apple
>
> The handler works if I comment out the date-boost line:
> "{!boost b=recip(ms(NOW/HOUR, submit_date),3.16e-11,1,1)}"
>
> Gin
>
> Best Wishes,
> Gintautas Sulskus
>
> On Mon, Oct 31, 2016 at 6:15 PM, Erik Hatcher
> wrote:
>
> > how’d you set “$term” - the correct way would be &term=apple on the Solr
> > request.
> >
> >
> > > On Oct 31, 2016, at 2:07 PM, Gintautas Sulskus <
> > gintautas.suls...@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > I am trying to construct a timestamp-boosted query comprising two
> > weighted
> > > fields: "title" and "body":
> > >
> > > {!boost b=recip(ms(NOW/HOUR,submit_date),3.16e-11,1,1)}
> > > {!type=dismax qf='title^10 body^1' v=$term}
> > >
> > > $term=apple
> > >
> > > I expect the given example query provided above to search fields "title"
> > > and "body" using keyword "apple" and adjust the order of the results by
> > the
> > > submission date "submit_date".
> > >
> > > However, the query just throws the NullPointerException exception: [1].
> > > Could you please help me out with this issue?
> > >
> > > I am using Solr 4.10.3+cdh5.8.2+434 - part of Cloudera 5.8.2 package.
> > >
> > > Best,
> > > Gin
> > >
> > > [1] the exception:
> > > java.lang.NullPointerException at
> > > org.apache.lucene.queries.function.BoostedQuery.
> > hashCode(BoostedQuery.java:215)
> > > at org.apache.lucene.search.BooleanClause.hashCode(
> > BooleanClause.java:99)
> > > at java.util.AbstractList.hashCode(AbstractList.java:541) at
> > > org.apache.lucene.search.BooleanQuery.hashCode(BooleanQuery.java:656) at
> > > org.apache.solr.search.QueryResultKey.(QueryResultKey.java:47) at
> > > org.apache.solr.search.SolrIndexSearcher.getDocListC(
> > SolrIndexSearcher.java:1347)
> > > at
> > > org.apache.solr.search.SolrIndexSearcher.search(
> > SolrIndexSearcher.java:518)
> > > at
> > > org.apache.solr.handler.component.QueryComponent.
> > process(QueryComponent.java:485)
> > > at
> > > org.apache.solr.handler.component.SearchHandler.handleRequestBody(
> > SearchHandler.java:218)
> > > at
> > > org.apache.solr.handler.RequestHandlerBase.handleRequest(
> > RequestHandlerBase.java:135)
> > > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2025) at
> > > org.apache.solr.servlet.SolrDispatchFilter.execute(
> > SolrDispatchFilter.java:918)
> > > at
> > > org.apache.solr.servlet.SolrDispatchFilter.httpSolrCall(
> > SolrDispatchFilter.java:481)
> > > at
> > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(
> > SolrDispatchFilter.java:260)
> > > at
> > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(
> > SolrDispatchFilter.java:255)
> > > at
> > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> > ApplicationFilterChain.java:235)
> > > at
> > > org.apache.catalina.core.ApplicationFilterChain.doFilter(
> > ApplicationFilterChain.java:206)
> > > at
> > > org.apache.solr.servlet.SolrHadoopAuthenticationFilter$2.doFilter(
> > SolrHadoopAuthenticationFilter.java:408)
> > > at
> > > org.apache.hadoop.security.authentication.server.
> > AuthenticationFilter.doFilter(AuthenticationFilter.java:622)
> > > at
> > > org.apache.hadoop.security.token.delegation.web.
> > DelegationTokenAuthenticationFilter.doFilter(
> > DelegationTokenAuthenticationFilter.java:291)
> > > at
> > > org.apache.hadoop.security.authentication.server.
> > AuthenticationFilter.doFilter(AuthenticationFilter.java:574)
> > > at
> > > org.apache.solr.servlet.SolrHadoopAuthenticationFilter.doFilter(
> > SolrHadoopAuthenticationFilter.java:413)
> > > at
> > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> > ApplicationFilterChain.java:235)
> > > at
> > > org.apache.catalina.core.ApplicationFilterChain.doFilter(
> > ApplicationFilterChain.java:206)
> > > at org.apache.solr.servlet.HostnameFilter.doFilter(
> > HostnameFilter.java:86)
> > > at
> > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> > ApplicationFilterChain.java:235)
> > > at
> > > org.apache.catalina.core.ApplicationFilterChain.doFilter(
> > ApplicationFilterChain.java:206)
> > > at
> > > org.apache.catalina.core.StandardWrapperValve.invoke(
> > StandardWrapperValve.java:233)
> > > at
> > > org.apache.catalina.core.StandardContextValve.invoke(
> > StandardContextValve.java:191)
> > > at
> > > org.apache.catalina.core.S
MLT Performance Degraded Between 4.6.1 and 5.5.2 Solr
I noticed a 3X performance degradation for MoreLikeThis between 4.6.1 and 5.5.2. Our configuration: where text_en is a pretty standard text fieldType. Any pointers? Thanks, Ivan Provalov
Re: solrj Https problem
A possible problem might be that your certificate was generated for
"localhost" which is why it works when you go to https://localhost:8985/solr
in your browser, but when SolrJ gets the cluster information from ZooKeeper
the hostnames of the Solr nodes might be using an IP address which won't
work when the SSL/TLS negotiation happens.
If this is the problem you will want to specify the hostname for Solr to
use when starting each node by passing "-h localhost".
-Bryan
On Mon, Oct 31, 2016 at 1:05 PM, sandeep mukherjee <
wiredcit...@yahoo.com.invalid> wrote:
> I followed the steps to make the solr SSL enabled. I'm able to hit solr
> at: https://localhost:8985/solr/problem/select?indent=on&q=*:*&wt=json And
> for accessing it through Solr Client I created it as
> follows:System.setProperty("javax.net.ssl.keyStore",
> "/path/to/solr/server/etc/solr-ssl.keystore.jks");
> System.setProperty("javax.net.ssl.keyStorePassword", "secret");
> System.setProperty("javax.net.ssl.trustStore", "/path/to/solr/server/etc/
> solr-ssl.keystore.jks");
> System.setProperty("javax.net.ssl.trustStorePassword", "secret");
> return new CloudSolrClient.Builder()
> .withZkHost(solrConfig.getConnectString()).build(); The path to
> the keystore and truststore is correct. However I still get the following
> error:Caused by: javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to
> find valid certification path to requested target
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) ~[na:1.8.0_45]
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1937)
> ~[na:1.8.0_45]
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302) ~[na:1.8.0_45]
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296) ~[na:1.8.0_45]
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1478)
> ~[na:1.8.0_45]
> at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:212)
> ~[na:1.8.0_45]
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
> ~[na:1.8.0_45]
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
> ~[na:1.8.0_45]
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1050)
> ~[na:1.8.0_45]
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
> ~[na:1.8.0_45]
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391)
> ~[na:1.8.0_45]
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375)
> ~[na:1.8.0_45]
> at
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543)
> ~[httpclient-4.5.1.jar:4.5.1]
> at
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
> ~[httpclient-4.5.1.jar:4.5.1]
> at org.apache.http.impl.conn.DefaultClientConnectionOperato
> r.openConnection(DefaultClientConnectionOperator.java:177)
> ~[httpclient-4.5.1.jar:4.5.1]
> at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(
> ManagedClientConnectionImpl.java:304) ~[httpclient-4.5.1.jar:4.5.1]
> at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(
> DefaultRequestDirector.java:611) ~[httpclient-4.5.1.jar:4.5.1]
> at org.apache.http.impl.client.DefaultRequestDirector.execute(
> DefaultRequestDirector.java:446) ~[httpclient-4.5.1.jar:4.5.1]
> at
> org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
> ~[httpclient-4.5.1.jar:4.5.1]
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> ~[httpclient-4.5.1.jar:4.5.1]
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
> ~[httpclient-4.5.1.jar:4.5.1]
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
> ~[httpclient-4.5.1.jar:4.5.1]
> at org.apache.solr.client.solrj.impl.HttpSolrClient.
> executeMethod(HttpSolrClient.java:495) ~[solr-solrj-6.1.0.jar:6.1.0
> 4726c5b2d2efa9ba160b608d46a977d0a6b83f94 - jpountz - 2016-06-13 09:46:59]
> ... 26 common frames omitted
> Caused by: sun.security.validator.ValidatorException: PKIX path building
> failed: sun.security.provider.certpath.SunCertPathBuilderException:
> unable to find valid certification path to requested target
> at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
> ~[na:1.8.0_45]
> at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
> ~[na:1.8.0_45]
> at sun.security.validator.Validator.validate(Validator.java:260)
> ~[na:1.8.0_45]
> at
> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
> ~[na:1.8.0_45]
> at
> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
> ~[na:1.8.0_45]
> at
> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
> ~[na:1.8.0_45]
> at
> sun.security.ssl.ClientHands
Re: Custom authentication plugin & inter-node auth
Hi I am facing same issue I have a custom authentication plugin and it is calling admin/info/key when the PKIAuthenticationPlugin is attempting to authenticate an inter-node request. Can you let me know how you resolved the same -- View this message in context: http://lucene.472066.n3.nabble.com/Custom-authentication-plugin-inter-node-auth-tp4294675p4303933.html Sent from the Solr - User mailing list archive at Nabble.com.
