SSL question

[Tony Sargent]

Hello,

I have set up a SolrCloud with 3 Solr nodes (v7.7) and 3 external Zookeepers 
(3.4.14). However, whenever I enable SSL I get these errors in the logs that 
for some reason Solr (or maybe ZK) still wants to communicate via http. I am 
able to pull up admin Console via https but when I click on Cloud/Nodes to look 
at metrics that’s when I see this message in the logs.
In the documentation it’s showing to pass “-name urlScheme -val https”  to 
Zookeeper also but external zkServer.sh doesn’t have that option.
What am I doing wrong? I am pulling my hair out, trying to get this going.
JKS has Key and a SAN certificate that includes all of the node names. JKS is 
loaded on all Solr nodes.
This is running inside of docker contains and I have passed the following 
variables:

  - SOLR_MODE=solrcloud
  - ZK_HOST=mynode1_fqdn:2181,mynode2_fqdn:2181,mynode2_fqdn:2181
  - SOLR_SSL_ENABLED=true
  - SOLR_SSL_KEY_STORE=/opt/solr/etc/solr-ssl.keystore.jks
  - SOLR_SSL_KEY_STORE_PASSWORD=secret
  - SOLR_SSL_TRUST_STORE=/opt/solr/etc/solr-ssl.keystore.jks
  - SOLR_SSL_TRUST_STORE_PASSWORD=secret
  - SOLR_SSL_NEED_CLIENT_AUTH=false
  - SOLR_SSL_WANT_CLIENT_AUTH=true
  - SOLR_SSL_CHECK_PEER_NAME=false
  - SOLR_URL_SCHEME=https





2019-05-16 22:15:44.999 WARN  (qtp841262455-21) [   ] 
o.a.s.h.a.AdminHandlersProxy Exception when fetching result from node 
mynode1_fqdn:8983_solr
java.util.concurrent.ExecutionException: 
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://mynode1_fqdn:8983/solr
at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
~[?:?]
at java.util.concurrent.FutureTask.get(FutureTask.java:205) 
~[?:?]
at 
org.apache.solr.handler.admin.AdminHandlersProxy.maybeProxyToNodes(AdminHandlersProxy.java:102)
 [solr-core-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 - ishan - 
2019-02-23 02:39:07]
at 
org.apache.solr.handler.admin.SystemInfoHandler.handleRequestBody(SystemInfoHandler.java:136)
 [solr-core-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 - ishan - 
2019-02-23 02:39:07]
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
 [solr-core-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 - ishan - 
2019-02-23 02:39:07]
at 
org.apache.solr.handler.admin.InfoHandler.handle(InfoHandler.java:91) 
[solr-core-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 - ishan - 
2019-02-23 02:39:07]
at 
org.apache.solr.handler.admin.InfoHandler.handleRequestBody(InfoHandler.java:81)
 [solr-core-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 - ishan - 
2019-02-23 02:39:07]
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
 [solr-core-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 - ishan - 
2019-02-23 02:39:07]
at 
org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:735) 
[solr-core-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 - ishan - 
2019-02-23 02:39:07]
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:716) 
[solr-core-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 - ishan - 
2019-02-23 02:39:07]
at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496) 
[solr-core-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 - ishan - 
2019-02-23 02:39:07]
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:395)
 [solr-core-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 - ishan - 
2019-02-23 02:39:07]
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:341)
 [solr-core-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 - ishan - 
2019-02-23 02:39:07]
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
 [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114]
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) 
[jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114]
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) 
[jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) 
[jetty-security-9.4.14.v20181114.jar:9.4.14.v20181114]
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) 
[jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
 [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
at 

ERR_SSL_VERSION_OR_CIPHER_MISMATCH Solr 8.1.0

[Younge, Kent A - Norman, OK - Contractor]

Hello,

I have upgraded one of our boxes to Solr 8.1.0 on RHEL 7.6 with Java 12.0.1.  I 
also had a certificate up for renewal and I went through my regular process of 
creating the certificate and key.  Now I get a 
ERR_SSL_VERSION_OR_CIPHER_MISMATCH error.  I have gotten this before however, 
that was due to me adding the certificate into the keystore.   Here are the 
list of cmds I that have run.

keytool -import -trustcacerts -alias root -file RootCA.cer -keystore 
solr-ssl.keystore.jks
keytool -import -trustcacerts -alias POL1 -file Pol1CA.cer -keystore 
solr-ssl.keystore.jks
keytool -import -trustcacerts -alias SUB1 -file Sub1CA.cer -keystore 
solr-ssl.keystore.jks
keytool -import -trustcacerts -alias SUB2 -file Sub2CA.cer -keystore 
solr-ssl.keystore.jks


openssl pkcs12 -export -in solr.cer -inkey solrpk.key > solr-ssl.p12


keytool -importkeystore -srckeystore solr-ssl.keystore.jks -destkeystore 
solr-ssl.keystore.jks -deststoretype pkcs12

solr.in.sh

# Enables HTTPS. It is implictly true if you set SOLR_SSL_KEY_STORE. Use this 
config
# to enable https module with custom jetty configuration.
#SOLR_SSL_ENABLED=true
# Uncomment to set SSL-related system properties
# Be sure to update the paths to the correct keystore for your environment
SOLR_SSL_KEY_STORE=/opt/solr-8.1.0/solr-ssl.keystore.jks
SOLR_SSL_KEY_STORE_PASSWORD=password
SOLR_SSL_TRUST_STORE=/opt/solr-8.1.0/solr-ssl.keystore.jks
SOLR_SSL_TRUST_STORE_PASSWORD=password
# Require clients to authenticate
SOLR_SSL_NEED_CLIENT_AUTH=false
# Enable clients to authenticate (but not require)
SOLR_SSL_WANT_CLIENT_AUTH=false
# SSL Certificates contain host/ip "peer name" information that is validated by 
default. Setting
# this to false can be useful to disable these checks when re-using a 
certificate on many hosts
#SOLR_SSL_CHECK_PEER_NAME=true
# Override Key/Trust Store types if necessary
SOLR_SSL_KEY_STORE_TYPE=JKS
SOLR_SSL_TRUST_STORE_TYPE=JKS




Thank you,

Kent Younge
Systems Engineer

Re: Execute query against to one document

[Erick Erickson]

This seems extremely inefficient. Let’s claim you have a document without a 
category. How do you determine what the category should be? Query the index? 
Reach out into another database and create a category? Add a default value? 
Depending on the source of the category, there are several options.


My first approach would be to insure the doc had a category when it was being 
indexed. Either write a SolrJ client that parses your very large data fie and 
adds the category when you index the doc or perhaps add a ScriptUpdateProcessor 
on the Solr end if you can’t parse the file on your client that added the 
category.

Well actually the very easiest thing to do would be to define a default value 
for the field as: , but that may not serve well.

Best,
Erick

> On May 16, 2019, at 6:10 AM, Derrick Cui  wrote:
> 
> Hi,
> I have a use case, but don’t know how to implement, please help.
> 
> I have one large data file, let’s say 500b data,  which doesn’t have
> category in the source. What I want to do is that execute a query on
> indexing documents, if the query hits great than 0, add category field and
> save to solr.
> 
> Currently I do two steps , indexing, then query on collection and add field
> of hits great than 0, but it takes several days to complete.
> 
> Any idea or solution please .
> 
> Thanks
> -- 
> Regards,
> 
> Derrick Cui
> Email: derrick...@gmail.com

Re: Writing unit tests to test complex solr queries

[Pratik Patel]

Thanks a lot for the response Mikhail and Angie!

I did go through most of the test classes in solr before posting here but
couldn't find anything which is close to what I want to do which is to load
pre-created index files and configuration or at least index files.
However, the class HelloWorldSolrCloudTestCase.java class pointed out by
Angie put together with his code that he has shared seems to be completing
the picture and looks spot on! Thanks a lot.

I will try to re-write my unit tests with this approach and will post an
update soon.

@Angie, can you please share the format of data in your
"testdata/test-data.json" file? I want to be sure about using the correct
format.

Thanks!
Pratik

On Tue, May 14, 2019 at 1:14 PM Angie Rabelero 
wrote:

> Hi, I’ll advised you to extend the class SolrCloudTestCase, which extends
> the MiniSolrCloudCluster. Theres a hello world example in the solr source
> at
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/test/org/apache/solr/HelloWorldSolrCloudTestCase.java
> .
>
> Here’s how I setup a cluster, create a collection with my ConfigSet, and
> index a file.
>
> @BeforeClass
> public static void setupCluster() throws Exception {
>
> // Create and configure cluster
> configureCluster(nodeCount)
> .addConfig(CONFIG_NAME, getFile(CONFIG_DIR).toPath())
> .configure();
>
> // Create an empty collection
> Create.createCollection(COLLECTION, CONFIG_NAME, numShards,
> numReplicas)
>   .setMaxShardsPerNode(maxShardsPerNode)
>   .process(cluster.getSolrClient(), COLLECTION);
> AbstractDistribZkTestBase
> .waitForRecoveriesToFinish(COLLECTION,
> cluster.getSolrClient().getZkStateReader(), true, true, 120);
>
> // Set default collection
> cluster.getSolrClient().setDefaultCollection(COLLECTION);
>
> // Add documents to collection
> ContentStreamUpdateRequest up = new
> ContentStreamUpdateRequest("/update");
> up.addFile(getFile("testdata/test-data.json"), "application/json");
> up.setAction(AbstractUpdateRequest.ACTION.COMMIT, true, true);
> NamedList result = cluster.getSolrClient().request(up);
>
> // Print cluster status
> System.out.println("Default Collection: " +
> cluster.getSolrClient().getDefaultCollection());
> System.out.println("Cluster State: " +
> cluster.getSolrClient().getZkStateReader().getClusterState());
> System.out.println("Update Result: " + result);
>
> }
>
>  I copy the configset to the resources dir in the pom using a mauven
> plugin. And the test file is already in the resources dir.
>
>
>
>
> > On May 14, 2019, at 04:01, Mikhail Khludnev  wrote:
> >
> > Hello, Pratick.
> > Welcome to mysterious world of Solr testing. The best way is to find
> > existing test closest to your problem field, copy in and amend
> necessarily.
> > What about
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_lucene-2Dsolr_blob_master_solr_solrj_src_test_org_apache_solr_client_solrj_io_stream_StreamExpressionTest.java=DwIBaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=lUsTzFRk0CX38HvagQ0wd52D67dA0fx_D6M6F3LHzAU=9tFliF4KA1tiG2lGmDJWO34hyq9-Sz1inAxRPVKkz78=KjveDzxzQAKRmvzPYk2y1FQ-w6yAGWuwfTVGHMQP2ZA=
> > ?
> >
> > On Fri, May 10, 2019 at 11:36 PM Pratik Patel 
> wrote:
> >
> >> Hello Everyone,
> >>
> >> I want to write unit tests for some solr queries which are being
> triggered
> >> through java code. These queries includes complex streaming expressions
> and
> >> faceting queries which requires large number of documents to be present
> in
> >> solr index. I can not create and push so many documents programmatically
> >> through my tests.
> >>
> >> I am trying to find a way to test these queries without depending on
> >> externally running solr instance. I found following approach which is
> using
> >> classes like EmbeddedSolrServer and CoreContainer. We can put index
> files
> >> and solr configuration on classpath and run the tests against them.
> >>
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__dzone.com_articles_junit-2Dtesting-2Dfor-2Dsolr-2D6=DwIBaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=lUsTzFRk0CX38HvagQ0wd52D67dA0fx_D6M6F3LHzAU=9tFliF4KA1tiG2lGmDJWO34hyq9-Sz1inAxRPVKkz78=K4vPwvz9h9H8s-nsZTbkmCvTh002RP3CHcpbb9IOrpw=
> >>
> >> However, this seems to be an old approach and I am trying to find a way
> to
> >> do it using latest solr-test-framework. I also can not use old approach
> >> because I want to test Streaming Expressions as well and I need
> >> SolrCloudClient for that.
> >> In solr-test-framework, I found MiniSolrCloudCluster class but I don't
> know
> >> how to use pre-created index files and configuration with that.
> >>
> >> Does anyone know how we can use pre-created index files and
> configuration
> >> with latest test-framework? What is the recommended way to do such kind
> of
> >> 

Re: Solr 8.1 issue with collection aliases

[Andrzej Białecki]

Yes, I can work on 8.1.1 release - I’ll announce this shortly.

> On 16 May 2019, at 13:51, Ishan Chattopadhyaya  
> wrote:
> 
> Absolutely. This is a critical feature.
> Andrzej, would you have time to do a 8.1.1 release? We also need to
> coordinate with Jan, since he's doing a 7.7.2 release right now.
> 
> On Thu, May 16, 2019 at 5:18 PM Jörn Franke  wrote:
>> 
>> For the specific client the Solr 8.1 is not usable with this bug.
>> 
>> Collection aliases are also a crucial feature for doing “zero-downtime” 
>> reindexing or changing the Schema of a collection or for switching back to 
>> an old Index if the new Index structure has bugs etc.
>> 
>> However  I also understand that there are other considerations by other 
>> people.
>> 
>>> Am 16.05.2019 um 11:55 schrieb Ishan Chattopadhyaya 
>>> :
>>> 
>>> Does this warrant a 8.1.1 release? I think this is serious enough.
>>> 
 On Thu, May 16, 2019 at 12:03 PM Jörn Franke  wrote:
 
 SOLR-13475
 
> Am 16.05.2019 um 05:24 schrieb Ishan Chattopadhyaya 
> :
> 
> Please open a JIRA.
> 
>> On Thu, 16 May, 2019, 8:09 AM Jörn Franke,  wrote:
>> Sorry autocorrection. It is not only a admin UI issue. I described in my 
>> previous email that access through the collection alias does not work. I 
>> cannot even do execute the select query handler if I use the collection 
>> alias instead of the collection name.
>> So it is maybe more problematic.
>> 
>>> Am 16.05.2019 um 04:36 schrieb Jörn Franke :
>>> 
>>> Note only an admin UI issue. Access collections via their alias does 
>>> not work.
>>> 
 Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev :
 
 It seems creating alias in Solr Admin UI is broken. It's a minor issue 
 for 8.1.0
 I've alias via REST call 
 http://localhost:8983/solr/admin/collections?action=CREATEALIAS=testalias=gettingstarted
   successfully.
 Jörn, thanks for reporting.
 
> On Tue, May 14, 2019 at 11:03 PM Jörn Franke  
> wrote:
> Hi,
> 
> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue 
> with
> collection aliases, but I am not 100% sure it is due to the upgrade.
> 
> Situation:
> I have a collection called c_testcollection.
> I have an alias called testcollection.
> Alias "testcollection" points to "c_testcollection".
> On Solr 8.0 no issue
> 
> After upgrade to Solr 8.1:
> When I do a query on c_testcollection then there is no issue:
> http://localhost:8983/solr/c_testcollection/select?q=test
> When I do a query on testcollection then I receive the stacktrace 
> below
> http://localhost:8983/solr/testcollection/select?q=test
> 
> Additionally I observe a strange behavior in the admin ui. When I try 
> to
> create an alias (e.g. new) for a new collection (e.g. c_new) then it
> creates two aliases:
> new => c_new
> c_new => c_new
> if i then do a query on the alias new it works without issues. If I 
> remove
> the alias from c_new to c_new then I get the same error. Is this 
> desired
> behaviour?
> It is rather annoying to have unnecessary aliases, because I need to 
> filter
> them out in my application when retrieving all aliases.
> Is there a related issue.
> 
> Here the stacktrace:
> {
> "error":{
>   "trace":"java.lang.NullPointerException\n\tat
> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
> org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat
> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
> org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
> 

Re: SolrCloud scaling/optimization for high request rate

[Sofiya Strochyk]

Thanks to everyone for the suggestions. We managed to get the 
performance to a bearable level by splitting the index into ~20 separate 
collections (one collection per country) and spreading them between 
existing servers as evenly as possible. The largest country is also 
split into 2 shards. This means that


1. QPS is lower for each instance since it only receives requests to the 
corresponding country.


2. Index size is smaller for each instance as it only contains documents 
for the corresponding country.


3. If one instance fails then most of the other instances keep running 
(possibly except the ones colocated with the failed one)


We didn't make any changes to the main query, but have added a few 
fields to facet on. This had a small negative impact on performance but 
overall kept working nicely.



On 14.11.18 12:18, Toke Eskildsen wrote:

On Mon, 2018-11-12 at 14:19 +0200, Sofiya Strochyk wrote:

I'll check if the filter queries or the main query tokenizers/filters
might have anything to do with this, but I'm afraid query
optimization can only get us so far.

Why do you think that? As you tried eliminating sorting and retrieval
previously, the queries are all that's left. There are multiple
performance traps when querying and a lot of them can be bypassed by
changing the index or querying in a different way.


Since we will have to add facets later, the queries will only become
heavier, and there has to be a way to scale this setup and deal with
both higher load and more complex queries.

There is of course a way. It is more a question of what you are willing
to pay.

If you have money, just buy more hardware: We know (with very high
probability) that it will work as your problem is search throughput,
which can be solved by adding more replicas on extra machines.

If you have more engineering hours, you can use them on some of the
things discussed previously:

* Pinpoint query bottlenecks
* Use less/more shards
* Applyhttps://issues.apache.org/jira/browse/LUCENE-8374
* Experiment with different amounts of concurrent requests to see what
gives the optimum throughput. This also tells you how much extra
hardware you need, if you decide you need to expand..


- Toke Eskildsen, Royal Danish Library




--
Email Signature
*Sofiia Strochyk
*


s...@interlogic.com.ua 
InterLogic
www.interlogic.com.ua 

Facebook icon  LinkedIn 
icon 

Execute query against to one document

[Derrick Cui]

Hi,
I have a use case, but don’t know how to implement, please help.

I have one large data file, let’s say 500b data,  which doesn’t have
category in the source. What I want to do is that execute a query on
indexing documents, if the query hits great than 0, add category field and
save to solr.

Currently I do two steps , indexing, then query on collection and add field
of hits great than 0, but it takes several days to complete.

Any idea or solution please .

Thanks
-- 
Regards,

Derrick Cui
Email: derrick...@gmail.com

Re: Solr 8.1 issue with collection aliases

[Ishan Chattopadhyaya]

Absolutely. This is a critical feature.
Andrzej, would you have time to do a 8.1.1 release? We also need to
coordinate with Jan, since he's doing a 7.7.2 release right now.

On Thu, May 16, 2019 at 5:18 PM Jörn Franke  wrote:
>
> For the specific client the Solr 8.1 is not usable with this bug.
>
> Collection aliases are also a crucial feature for doing “zero-downtime” 
> reindexing or changing the Schema of a collection or for switching back to an 
> old Index if the new Index structure has bugs etc.
>
> However  I also understand that there are other considerations by other 
> people.
>
> > Am 16.05.2019 um 11:55 schrieb Ishan Chattopadhyaya 
> > :
> >
> > Does this warrant a 8.1.1 release? I think this is serious enough.
> >
> >> On Thu, May 16, 2019 at 12:03 PM Jörn Franke  wrote:
> >>
> >> SOLR-13475
> >>
> >>> Am 16.05.2019 um 05:24 schrieb Ishan Chattopadhyaya 
> >>> :
> >>>
> >>> Please open a JIRA.
> >>>
>  On Thu, 16 May, 2019, 8:09 AM Jörn Franke,  wrote:
>  Sorry autocorrection. It is not only a admin UI issue. I described in my 
>  previous email that access through the collection alias does not work. I 
>  cannot even do execute the select query handler if I use the collection 
>  alias instead of the collection name.
>  So it is maybe more problematic.
> 
> > Am 16.05.2019 um 04:36 schrieb Jörn Franke :
> >
> > Note only an admin UI issue. Access collections via their alias does 
> > not work.
> >
> >> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev :
> >>
> >> It seems creating alias in Solr Admin UI is broken. It's a minor issue 
> >> for 8.1.0
> >> I've alias via REST call 
> >> http://localhost:8983/solr/admin/collections?action=CREATEALIAS=testalias=gettingstarted
> >>   successfully.
> >> Jörn, thanks for reporting.
> >>
> >>> On Tue, May 14, 2019 at 11:03 PM Jörn Franke  
> >>> wrote:
> >>> Hi,
> >>>
> >>> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue 
> >>> with
> >>> collection aliases, but I am not 100% sure it is due to the upgrade.
> >>>
> >>> Situation:
> >>> I have a collection called c_testcollection.
> >>> I have an alias called testcollection.
> >>> Alias "testcollection" points to "c_testcollection".
> >>> On Solr 8.0 no issue
> >>>
> >>> After upgrade to Solr 8.1:
> >>> When I do a query on c_testcollection then there is no issue:
> >>> http://localhost:8983/solr/c_testcollection/select?q=test
> >>> When I do a query on testcollection then I receive the stacktrace 
> >>> below
> >>> http://localhost:8983/solr/testcollection/select?q=test
> >>>
> >>> Additionally I observe a strange behavior in the admin ui. When I try 
> >>> to
> >>> create an alias (e.g. new) for a new collection (e.g. c_new) then it
> >>> creates two aliases:
> >>> new => c_new
> >>> c_new => c_new
> >>> if i then do a query on the alias new it works without issues. If I 
> >>> remove
> >>> the alias from c_new to c_new then I get the same error. Is this 
> >>> desired
> >>> behaviour?
> >>> It is rather annoying to have unnecessary aliases, because I need to 
> >>> filter
> >>> them out in my application when retrieving all aliases.
> >>> Is there a related issue.
> >>>
> >>> Here the stacktrace:
> >>> {
> >>>  "error":{
> >>>"trace":"java.lang.NullPointerException\n\tat
> >>> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
> >>> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
> >>> org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat
> >>> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
> >>> org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat
> >>> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat
> >>> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
> >>> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
> >>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
> >>> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
> >>> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
> >>> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
> >>> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> >>> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
> >>> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)\n\tat
> >>> 

Re: Solr 8.1 issue with collection aliases

[Jörn Franke]

For the specific client the Solr 8.1 is not usable with this bug.

Collection aliases are also a crucial feature for doing “zero-downtime” 
reindexing or changing the Schema of a collection or for switching back to an 
old Index if the new Index structure has bugs etc.

However  I also understand that there are other considerations by other people.

> Am 16.05.2019 um 11:55 schrieb Ishan Chattopadhyaya 
> :
> 
> Does this warrant a 8.1.1 release? I think this is serious enough.
> 
>> On Thu, May 16, 2019 at 12:03 PM Jörn Franke  wrote:
>> 
>> SOLR-13475
>> 
>>> Am 16.05.2019 um 05:24 schrieb Ishan Chattopadhyaya 
>>> :
>>> 
>>> Please open a JIRA.
>>> 
 On Thu, 16 May, 2019, 8:09 AM Jörn Franke,  wrote:
 Sorry autocorrection. It is not only a admin UI issue. I described in my 
 previous email that access through the collection alias does not work. I 
 cannot even do execute the select query handler if I use the collection 
 alias instead of the collection name.
 So it is maybe more problematic.
 
> Am 16.05.2019 um 04:36 schrieb Jörn Franke :
> 
> Note only an admin UI issue. Access collections via their alias does not 
> work.
> 
>> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev :
>> 
>> It seems creating alias in Solr Admin UI is broken. It's a minor issue 
>> for 8.1.0
>> I've alias via REST call 
>> http://localhost:8983/solr/admin/collections?action=CREATEALIAS=testalias=gettingstarted
>>   successfully.
>> Jörn, thanks for reporting.
>> 
>>> On Tue, May 14, 2019 at 11:03 PM Jörn Franke  
>>> wrote:
>>> Hi,
>>> 
>>> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue 
>>> with
>>> collection aliases, but I am not 100% sure it is due to the upgrade.
>>> 
>>> Situation:
>>> I have a collection called c_testcollection.
>>> I have an alias called testcollection.
>>> Alias "testcollection" points to "c_testcollection".
>>> On Solr 8.0 no issue
>>> 
>>> After upgrade to Solr 8.1:
>>> When I do a query on c_testcollection then there is no issue:
>>> http://localhost:8983/solr/c_testcollection/select?q=test
>>> When I do a query on testcollection then I receive the stacktrace below
>>> http://localhost:8983/solr/testcollection/select?q=test
>>> 
>>> Additionally I observe a strange behavior in the admin ui. When I try to
>>> create an alias (e.g. new) for a new collection (e.g. c_new) then it
>>> creates two aliases:
>>> new => c_new
>>> c_new => c_new
>>> if i then do a query on the alias new it works without issues. If I 
>>> remove
>>> the alias from c_new to c_new then I get the same error. Is this desired
>>> behaviour?
>>> It is rather annoying to have unnecessary aliases, because I need to 
>>> filter
>>> them out in my application when retrieving all aliases.
>>> Is there a related issue.
>>> 
>>> Here the stacktrace:
>>> {
>>>  "error":{
>>>"trace":"java.lang.NullPointerException\n\tat
>>> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
>>> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
>>> org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat
>>> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
>>> org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat
>>> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat
>>> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
>>> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
>>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
>>> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
>>> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>>> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>>> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>>> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>>> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)\n\tat
>>> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>>> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)\n\tat
>>> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>>> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
>>> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)\n\tat
>>> 

Re: Solr 8.1 issue with collection aliases

[Ishan Chattopadhyaya]

Does this warrant a 8.1.1 release? I think this is serious enough.

On Thu, May 16, 2019 at 12:03 PM Jörn Franke  wrote:
>
> SOLR-13475
>
> > Am 16.05.2019 um 05:24 schrieb Ishan Chattopadhyaya 
> > :
> >
> > Please open a JIRA.
> >
> >> On Thu, 16 May, 2019, 8:09 AM Jörn Franke,  wrote:
> >> Sorry autocorrection. It is not only a admin UI issue. I described in my 
> >> previous email that access through the collection alias does not work. I 
> >> cannot even do execute the select query handler if I use the collection 
> >> alias instead of the collection name.
> >> So it is maybe more problematic.
> >>
> >>> Am 16.05.2019 um 04:36 schrieb Jörn Franke :
> >>>
> >>> Note only an admin UI issue. Access collections via their alias does not 
> >>> work.
> >>>
>  Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev :
> 
>  It seems creating alias in Solr Admin UI is broken. It's a minor issue 
>  for 8.1.0
>  I've alias via REST call 
>  http://localhost:8983/solr/admin/collections?action=CREATEALIAS=testalias=gettingstarted
>    successfully.
>  Jörn, thanks for reporting.
> 
> > On Tue, May 14, 2019 at 11:03 PM Jörn Franke  
> > wrote:
> > Hi,
> >
> > I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue 
> > with
> > collection aliases, but I am not 100% sure it is due to the upgrade.
> >
> > Situation:
> > I have a collection called c_testcollection.
> > I have an alias called testcollection.
> > Alias "testcollection" points to "c_testcollection".
> > On Solr 8.0 no issue
> >
> > After upgrade to Solr 8.1:
> > When I do a query on c_testcollection then there is no issue:
> > http://localhost:8983/solr/c_testcollection/select?q=test
> > When I do a query on testcollection then I receive the stacktrace below
> > http://localhost:8983/solr/testcollection/select?q=test
> >
> > Additionally I observe a strange behavior in the admin ui. When I try to
> > create an alias (e.g. new) for a new collection (e.g. c_new) then it
> > creates two aliases:
> > new => c_new
> > c_new => c_new
> > if i then do a query on the alias new it works without issues. If I 
> > remove
> > the alias from c_new to c_new then I get the same error. Is this desired
> > behaviour?
> > It is rather annoying to have unnecessary aliases, because I need to 
> > filter
> > them out in my application when retrieving all aliases.
> > Is there a related issue.
> >
> > Here the stacktrace:
> > {
> >   "error":{
> > "trace":"java.lang.NullPointerException\n\tat
> > java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
> > org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
> > org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat
> > org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
> > org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat
> > org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat
> > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
> > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
> > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
> > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
> > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
> > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
> > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)\n\tat
> > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
> > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)\n\tat
> > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
> > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
> > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)\n\tat
> > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
> > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)\n\tat
> > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
> > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\n\tat
> > 

Re: [ANNOUNCE] Apache Solr 8.1.0 released

[Hasan Diwan]

On Thu, 16 May 2019 at 00:43, Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> = 16 March 2019, Apache Solr™ 8.1.0 available =
>
> The Lucene PMC is pleased to announce the release of Apache Solr 8.1.0
>

Congrats to all involved! -- H
-- 
OpenPGP:
https://sks-keyservers.net/pks/lookup?op=get=0xFEBAD7FFD041BBA1
If you wish to request my time, please do so using
*bit.ly/hd1AppointmentRequest
*.
Si vous voudrais faire connnaisance, allez a *bit.ly/hd1AppointmentRequest
*.

Sent
from my mobile device
Envoye de mon portable

[ANNOUNCE] Apache Solr 8.1.0 released

[Ishan Chattopadhyaya]

= 16 March 2019, Apache Solr™ 8.1.0 available =

The Lucene PMC is pleased to announce the release of Apache Solr 8.1.0

Solr is the popular, blazing fast, open source NoSQL search platform
from the Apache Lucene project. Its major features include powerful
full-text search, hit highlighting, faceted search and analytics, rich
document parsing, geospatial search, extensive REST APIs as well as
parallel SQL. Solr is enterprise grade, secure and highly scalable,
providing fault tolerant distributed search and indexing, and powers
the search and navigation features of many of the world's largest
internet sites.

The release is available for immediate download at:

http://www.apache.org/dyn/closer.lua/lucene/solr/8.1.0

Please read CHANGES.txt for a detailed list of changes:

https://lucene.apache.org/solr/8_1_0/changes/Changes.html

== Solr 8.1.0 Release Highlights ==

 * Partial/Atomic Updates for nested documents. This enables atomic
updates for nested documents, without the need to supply the whole
nested hierarchy (which would be overwritten if absent).
 * Category Routed Aliases feature introduced for data driven
assignment of documents to collections based on values of a field
 * JWT Token authentication plugin with OpenID Connect implicit flow
login through Admin UI
 * REINDEXCOLLECTION command for re-indexing of existing collections
 * Collection RENAME command and support using aliases in most
collection admin commands
 * Read-only mode for SolrCloud collections

Solr 8.1.0 also includes many other new features as well as numerous
optimizations and bugfixes of the corresponding Apache Lucene release.

Please report any feedback to the mailing lists
(http://lucene.apache.org/solr/discussion.html)

Note: The Apache Software Foundation uses an extensive mirroring
network for distributing releases. It is possible that the mirror you
are using may not have replicated the release yet. If that is the
case, please try another mirror. This also goes for Maven access.

Re: Solr 8.1 issue with collection aliases

[Jörn Franke]

SOLR-13475

> Am 16.05.2019 um 05:24 schrieb Ishan Chattopadhyaya 
> :
> 
> Please open a JIRA.
> 
>> On Thu, 16 May, 2019, 8:09 AM Jörn Franke,  wrote:
>> Sorry autocorrection. It is not only a admin UI issue. I described in my 
>> previous email that access through the collection alias does not work. I 
>> cannot even do execute the select query handler if I use the collection 
>> alias instead of the collection name.
>> So it is maybe more problematic.
>> 
>>> Am 16.05.2019 um 04:36 schrieb Jörn Franke :
>>> 
>>> Note only an admin UI issue. Access collections via their alias does not 
>>> work.
>>> 
 Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev :
 
 It seems creating alias in Solr Admin UI is broken. It's a minor issue for 
 8.1.0 
 I've alias via REST call 
 http://localhost:8983/solr/admin/collections?action=CREATEALIAS=testalias=gettingstarted
   successfully. 
 Jörn, thanks for reporting. 
 
> On Tue, May 14, 2019 at 11:03 PM Jörn Franke  wrote:
> Hi,
> 
> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue with
> collection aliases, but I am not 100% sure it is due to the upgrade.
> 
> Situation:
> I have a collection called c_testcollection.
> I have an alias called testcollection.
> Alias "testcollection" points to "c_testcollection".
> On Solr 8.0 no issue
> 
> After upgrade to Solr 8.1:
> When I do a query on c_testcollection then there is no issue:
> http://localhost:8983/solr/c_testcollection/select?q=test
> When I do a query on testcollection then I receive the stacktrace below
> http://localhost:8983/solr/testcollection/select?q=test
> 
> Additionally I observe a strange behavior in the admin ui. When I try to
> create an alias (e.g. new) for a new collection (e.g. c_new) then it
> creates two aliases:
> new => c_new
> c_new => c_new
> if i then do a query on the alias new it works without issues. If I remove
> the alias from c_new to c_new then I get the same error. Is this desired
> behaviour?
> It is rather annoying to have unnecessary aliases, because I need to 
> filter
> them out in my application when retrieving all aliases.
> Is there a related issue.
> 
> Here the stacktrace:
> {
>   "error":{
> "trace":"java.lang.NullPointerException\n\tat
> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
> org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat
> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
> org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)\n\tat
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)\n\tat
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)\n\tat
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)\n\tat
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\n\tat
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>