You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Jörn Franke <jo...@gmail.com> on 2019/05/14 19:52:41 UTC

Solr 8.1 issue with collection aliases

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
org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat
org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:126)\n\tat
org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:338)\n\tat
org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)\n\tat
org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)\n\tat
org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)\n\tat
org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)\n\tat
org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)\n\tat
java.base/java.lang.Thread.run(Thread.java:834)\n",
    "code":500}}


Thank you.

Best regards

Re: Solr 8.1 issue with collection aliases

Posted by Andrzej Białecki <ab...@getopt.org>.
Yes, I can work on 8.1.1 release - I’ll announce this shortly.

> On 16 May 2019, at 13:51, Ishan Chattopadhyaya <ic...@gmail.com> 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 <jo...@gmail.com> 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 <ic...@gmail.com>:
>>> 
>>> 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 <jo...@gmail.com> wrote:
>>>> 
>>>> SOLR-13475
>>>> 
>>>>> Am 16.05.2019 um 05:24 schrieb Ishan Chattopadhyaya <ic...@gmail.com>:
>>>>> 
>>>>> Please open a JIRA.
>>>>> 
>>>>>> On Thu, 16 May, 2019, 8:09 AM Jörn Franke, <jo...@gmail.com> 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 <jo...@gmail.com>:
>>>>>>> 
>>>>>>> Note only an admin UI issue. Access collections via their alias does not work.
>>>>>>> 
>>>>>>>> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev <mk...@apache.org>:
>>>>>>>> 
>>>>>>>> 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&name=testalias&collections=gettingstarted  successfully.
>>>>>>>> Jörn, thanks for reporting.
>>>>>>>> 
>>>>>>>>> On Tue, May 14, 2019 at 11:03 PM Jörn Franke <jo...@gmail.com> 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
>>>>>>>>> org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat
>>>>>>>>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
>>>>>>>>> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
>>>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
>>>>>>>>> org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat
>>>>>>>>> org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:126)\n\tat
>>>>>>>>> org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:338)\n\tat
>>>>>>>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>>>>>>>>> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)\n\tat
>>>>>>>>> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)\n\tat
>>>>>>>>> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)\n\tat
>>>>>>>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>>>>>>>>> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
>>>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)\n\tat
>>>>>>>>> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)\n\tat
>>>>>>>>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)\n\tat
>>>>>>>>> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)\n\tat
>>>>>>>>> java.base/java.lang.Thread.run(Thread.java:834)\n",
>>>>>>>>>   "code":500}}
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thank you.
>>>>>>>>> 
>>>>>>>>> Best regards
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Sincerely yours
>>>>>>>> Mikhail Khludnev
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Re: Solr 8.1 issue with collection aliases

Posted by Andrzej Białecki <ab...@getopt.org>.
Yes, I can work on 8.1.1 release - I’ll announce this shortly.

> On 16 May 2019, at 13:51, Ishan Chattopadhyaya <ic...@gmail.com> 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 <jo...@gmail.com> 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 <ic...@gmail.com>:
>>> 
>>> 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 <jo...@gmail.com> wrote:
>>>> 
>>>> SOLR-13475
>>>> 
>>>>> Am 16.05.2019 um 05:24 schrieb Ishan Chattopadhyaya <ic...@gmail.com>:
>>>>> 
>>>>> Please open a JIRA.
>>>>> 
>>>>>> On Thu, 16 May, 2019, 8:09 AM Jörn Franke, <jo...@gmail.com> 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 <jo...@gmail.com>:
>>>>>>> 
>>>>>>> Note only an admin UI issue. Access collections via their alias does not work.
>>>>>>> 
>>>>>>>> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev <mk...@apache.org>:
>>>>>>>> 
>>>>>>>> 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&name=testalias&collections=gettingstarted  successfully.
>>>>>>>> Jörn, thanks for reporting.
>>>>>>>> 
>>>>>>>>> On Tue, May 14, 2019 at 11:03 PM Jörn Franke <jo...@gmail.com> 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
>>>>>>>>> org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat
>>>>>>>>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
>>>>>>>>> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
>>>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
>>>>>>>>> org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat
>>>>>>>>> org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:126)\n\tat
>>>>>>>>> org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:338)\n\tat
>>>>>>>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>>>>>>>>> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)\n\tat
>>>>>>>>> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)\n\tat
>>>>>>>>> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)\n\tat
>>>>>>>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>>>>>>>>> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
>>>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)\n\tat
>>>>>>>>> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)\n\tat
>>>>>>>>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)\n\tat
>>>>>>>>> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)\n\tat
>>>>>>>>> java.base/java.lang.Thread.run(Thread.java:834)\n",
>>>>>>>>>   "code":500}}
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thank you.
>>>>>>>>> 
>>>>>>>>> Best regards
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Sincerely yours
>>>>>>>> Mikhail Khludnev
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>> 
> 


Re: Solr 8.1 issue with collection aliases

Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
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 <jo...@gmail.com> 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 <ic...@gmail.com>:
> >
> > 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 <jo...@gmail.com> wrote:
> >>
> >> SOLR-13475
> >>
> >>> Am 16.05.2019 um 05:24 schrieb Ishan Chattopadhyaya <ic...@gmail.com>:
> >>>
> >>> Please open a JIRA.
> >>>
> >>>> On Thu, 16 May, 2019, 8:09 AM Jörn Franke, <jo...@gmail.com> 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 <jo...@gmail.com>:
> >>>>>
> >>>>> Note only an admin UI issue. Access collections via their alias does not work.
> >>>>>
> >>>>>> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev <mk...@apache.org>:
> >>>>>>
> >>>>>> 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&name=testalias&collections=gettingstarted  successfully.
> >>>>>> Jörn, thanks for reporting.
> >>>>>>
> >>>>>>> On Tue, May 14, 2019 at 11:03 PM Jörn Franke <jo...@gmail.com> 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
> >>>>>>> org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat
> >>>>>>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
> >>>>>>> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
> >>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
> >>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
> >>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
> >>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
> >>>>>>> org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat
> >>>>>>> org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:126)\n\tat
> >>>>>>> org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:338)\n\tat
> >>>>>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
> >>>>>>> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)\n\tat
> >>>>>>> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)\n\tat
> >>>>>>> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)\n\tat
> >>>>>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
> >>>>>>> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
> >>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
> >>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
> >>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
> >>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)\n\tat
> >>>>>>> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)\n\tat
> >>>>>>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)\n\tat
> >>>>>>> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)\n\tat
> >>>>>>> java.base/java.lang.Thread.run(Thread.java:834)\n",
> >>>>>>>    "code":500}}
> >>>>>>>
> >>>>>>>
> >>>>>>> Thank you.
> >>>>>>>
> >>>>>>> Best regards
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Sincerely yours
> >>>>>> Mikhail Khludnev
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >

Re: Solr 8.1 issue with collection aliases

Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
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 <jo...@gmail.com> 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 <ic...@gmail.com>:
> >
> > 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 <jo...@gmail.com> wrote:
> >>
> >> SOLR-13475
> >>
> >>> Am 16.05.2019 um 05:24 schrieb Ishan Chattopadhyaya <ic...@gmail.com>:
> >>>
> >>> Please open a JIRA.
> >>>
> >>>> On Thu, 16 May, 2019, 8:09 AM Jörn Franke, <jo...@gmail.com> 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 <jo...@gmail.com>:
> >>>>>
> >>>>> Note only an admin UI issue. Access collections via their alias does not work.
> >>>>>
> >>>>>> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev <mk...@apache.org>:
> >>>>>>
> >>>>>> 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&name=testalias&collections=gettingstarted  successfully.
> >>>>>> Jörn, thanks for reporting.
> >>>>>>
> >>>>>>> On Tue, May 14, 2019 at 11:03 PM Jörn Franke <jo...@gmail.com> 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
> >>>>>>> org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat
> >>>>>>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
> >>>>>>> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
> >>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
> >>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
> >>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
> >>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
> >>>>>>> org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat
> >>>>>>> org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:126)\n\tat
> >>>>>>> org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:338)\n\tat
> >>>>>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
> >>>>>>> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)\n\tat
> >>>>>>> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)\n\tat
> >>>>>>> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)\n\tat
> >>>>>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
> >>>>>>> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
> >>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
> >>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
> >>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
> >>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)\n\tat
> >>>>>>> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)\n\tat
> >>>>>>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)\n\tat
> >>>>>>> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)\n\tat
> >>>>>>> java.base/java.lang.Thread.run(Thread.java:834)\n",
> >>>>>>>    "code":500}}
> >>>>>>>
> >>>>>>>
> >>>>>>> Thank you.
> >>>>>>>
> >>>>>>> Best regards
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Sincerely yours
> >>>>>> Mikhail Khludnev
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Re: Solr 8.1 issue with collection aliases

Posted by Jörn Franke <jo...@gmail.com>.
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 <ic...@gmail.com>:
> 
> 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 <jo...@gmail.com> wrote:
>> 
>> SOLR-13475
>> 
>>> Am 16.05.2019 um 05:24 schrieb Ishan Chattopadhyaya <ic...@gmail.com>:
>>> 
>>> Please open a JIRA.
>>> 
>>>> On Thu, 16 May, 2019, 8:09 AM Jörn Franke, <jo...@gmail.com> 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 <jo...@gmail.com>:
>>>>> 
>>>>> Note only an admin UI issue. Access collections via their alias does not work.
>>>>> 
>>>>>> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev <mk...@apache.org>:
>>>>>> 
>>>>>> 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&name=testalias&collections=gettingstarted  successfully.
>>>>>> Jörn, thanks for reporting.
>>>>>> 
>>>>>>> On Tue, May 14, 2019 at 11:03 PM Jörn Franke <jo...@gmail.com> 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
>>>>>>> org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat
>>>>>>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
>>>>>>> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
>>>>>>> org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat
>>>>>>> org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:126)\n\tat
>>>>>>> org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:338)\n\tat
>>>>>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>>>>>>> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)\n\tat
>>>>>>> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)\n\tat
>>>>>>> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)\n\tat
>>>>>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>>>>>>> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)\n\tat
>>>>>>> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)\n\tat
>>>>>>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)\n\tat
>>>>>>> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)\n\tat
>>>>>>> java.base/java.lang.Thread.run(Thread.java:834)\n",
>>>>>>>    "code":500}}
>>>>>>> 
>>>>>>> 
>>>>>>> Thank you.
>>>>>>> 
>>>>>>> Best regards
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Sincerely yours
>>>>>> Mikhail Khludnev
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
> 

Re: Solr 8.1 issue with collection aliases

Posted by Jörn Franke <jo...@gmail.com>.
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 <ic...@gmail.com>:
> 
> 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 <jo...@gmail.com> wrote:
>> 
>> SOLR-13475
>> 
>>> Am 16.05.2019 um 05:24 schrieb Ishan Chattopadhyaya <ic...@gmail.com>:
>>> 
>>> Please open a JIRA.
>>> 
>>>> On Thu, 16 May, 2019, 8:09 AM Jörn Franke, <jo...@gmail.com> 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 <jo...@gmail.com>:
>>>>> 
>>>>> Note only an admin UI issue. Access collections via their alias does not work.
>>>>> 
>>>>>> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev <mk...@apache.org>:
>>>>>> 
>>>>>> 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&name=testalias&collections=gettingstarted  successfully.
>>>>>> Jörn, thanks for reporting.
>>>>>> 
>>>>>>> On Tue, May 14, 2019 at 11:03 PM Jörn Franke <jo...@gmail.com> 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
>>>>>>> org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat
>>>>>>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
>>>>>>> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
>>>>>>> org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat
>>>>>>> org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:126)\n\tat
>>>>>>> org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:338)\n\tat
>>>>>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>>>>>>> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)\n\tat
>>>>>>> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)\n\tat
>>>>>>> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)\n\tat
>>>>>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>>>>>>> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)\n\tat
>>>>>>> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)\n\tat
>>>>>>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)\n\tat
>>>>>>> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)\n\tat
>>>>>>> java.base/java.lang.Thread.run(Thread.java:834)\n",
>>>>>>>    "code":500}}
>>>>>>> 
>>>>>>> 
>>>>>>> Thank you.
>>>>>>> 
>>>>>>> Best regards
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Sincerely yours
>>>>>> Mikhail Khludnev
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Re: Solr 8.1 issue with collection aliases

Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
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 <jo...@gmail.com> wrote:
>
> SOLR-13475
>
> > Am 16.05.2019 um 05:24 schrieb Ishan Chattopadhyaya <ic...@gmail.com>:
> >
> > Please open a JIRA.
> >
> >> On Thu, 16 May, 2019, 8:09 AM Jörn Franke, <jo...@gmail.com> 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 <jo...@gmail.com>:
> >>>
> >>> Note only an admin UI issue. Access collections via their alias does not work.
> >>>
> >>>> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev <mk...@apache.org>:
> >>>>
> >>>> 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&name=testalias&collections=gettingstarted  successfully.
> >>>> Jörn, thanks for reporting.
> >>>>
> >>>>> On Tue, May 14, 2019 at 11:03 PM Jörn Franke <jo...@gmail.com> 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
> >>>>> org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat
> >>>>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
> >>>>> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
> >>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
> >>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
> >>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
> >>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
> >>>>> org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat
> >>>>> org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:126)\n\tat
> >>>>> org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:338)\n\tat
> >>>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
> >>>>> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)\n\tat
> >>>>> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)\n\tat
> >>>>> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)\n\tat
> >>>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
> >>>>> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
> >>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
> >>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
> >>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
> >>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)\n\tat
> >>>>> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)\n\tat
> >>>>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)\n\tat
> >>>>> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)\n\tat
> >>>>> java.base/java.lang.Thread.run(Thread.java:834)\n",
> >>>>>     "code":500}}
> >>>>>
> >>>>>
> >>>>> Thank you.
> >>>>>
> >>>>> Best regards
> >>>>
> >>>>
> >>>> --
> >>>> Sincerely yours
> >>>> Mikhail Khludnev

Re: Solr 8.1 issue with collection aliases

Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
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 <jo...@gmail.com> wrote:
>
> SOLR-13475
>
> > Am 16.05.2019 um 05:24 schrieb Ishan Chattopadhyaya <ic...@gmail.com>:
> >
> > Please open a JIRA.
> >
> >> On Thu, 16 May, 2019, 8:09 AM Jörn Franke, <jo...@gmail.com> 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 <jo...@gmail.com>:
> >>>
> >>> Note only an admin UI issue. Access collections via their alias does not work.
> >>>
> >>>> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev <mk...@apache.org>:
> >>>>
> >>>> 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&name=testalias&collections=gettingstarted  successfully.
> >>>> Jörn, thanks for reporting.
> >>>>
> >>>>> On Tue, May 14, 2019 at 11:03 PM Jörn Franke <jo...@gmail.com> 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
> >>>>> org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat
> >>>>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
> >>>>> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
> >>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
> >>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
> >>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
> >>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
> >>>>> org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat
> >>>>> org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:126)\n\tat
> >>>>> org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:338)\n\tat
> >>>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
> >>>>> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)\n\tat
> >>>>> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)\n\tat
> >>>>> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)\n\tat
> >>>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
> >>>>> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
> >>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
> >>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
> >>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
> >>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)\n\tat
> >>>>> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)\n\tat
> >>>>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)\n\tat
> >>>>> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)\n\tat
> >>>>> java.base/java.lang.Thread.run(Thread.java:834)\n",
> >>>>>     "code":500}}
> >>>>>
> >>>>>
> >>>>> Thank you.
> >>>>>
> >>>>> Best regards
> >>>>
> >>>>
> >>>> --
> >>>> Sincerely yours
> >>>> Mikhail Khludnev

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Re: Solr 8.1 issue with collection aliases

Posted by Jörn Franke <jo...@gmail.com>.
SOLR-13475

> Am 16.05.2019 um 05:24 schrieb Ishan Chattopadhyaya <ic...@gmail.com>:
> 
> Please open a JIRA.
> 
>> On Thu, 16 May, 2019, 8:09 AM Jörn Franke, <jo...@gmail.com> 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 <jo...@gmail.com>:
>>> 
>>> Note only an admin UI issue. Access collections via their alias does not work.
>>> 
>>>> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev <mk...@apache.org>:
>>>> 
>>>> 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&name=testalias&collections=gettingstarted  successfully. 
>>>> Jörn, thanks for reporting. 
>>>> 
>>>>> On Tue, May 14, 2019 at 11:03 PM Jörn Franke <jo...@gmail.com> 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
>>>>> org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat
>>>>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
>>>>> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
>>>>> org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat
>>>>> org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:126)\n\tat
>>>>> org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:338)\n\tat
>>>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>>>>> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)\n\tat
>>>>> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)\n\tat
>>>>> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)\n\tat
>>>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>>>>> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)\n\tat
>>>>> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)\n\tat
>>>>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)\n\tat
>>>>> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)\n\tat
>>>>> java.base/java.lang.Thread.run(Thread.java:834)\n",
>>>>>     "code":500}}
>>>>> 
>>>>> 
>>>>> Thank you.
>>>>> 
>>>>> Best regards
>>>> 
>>>> 
>>>> -- 
>>>> Sincerely yours
>>>> Mikhail Khludnev

Re: Solr 8.1 issue with collection aliases

Posted by Jörn Franke <jo...@gmail.com>.
SOLR-13475

> Am 16.05.2019 um 05:24 schrieb Ishan Chattopadhyaya <ic...@gmail.com>:
> 
> Please open a JIRA.
> 
>> On Thu, 16 May, 2019, 8:09 AM Jörn Franke, <jo...@gmail.com> 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 <jo...@gmail.com>:
>>> 
>>> Note only an admin UI issue. Access collections via their alias does not work.
>>> 
>>>> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev <mk...@apache.org>:
>>>> 
>>>> 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&name=testalias&collections=gettingstarted  successfully. 
>>>> Jörn, thanks for reporting. 
>>>> 
>>>>> On Tue, May 14, 2019 at 11:03 PM Jörn Franke <jo...@gmail.com> 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
>>>>> org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat
>>>>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
>>>>> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
>>>>> org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat
>>>>> org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:126)\n\tat
>>>>> org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:338)\n\tat
>>>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>>>>> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)\n\tat
>>>>> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)\n\tat
>>>>> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)\n\tat
>>>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>>>>> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)\n\tat
>>>>> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)\n\tat
>>>>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)\n\tat
>>>>> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)\n\tat
>>>>> java.base/java.lang.Thread.run(Thread.java:834)\n",
>>>>>     "code":500}}
>>>>> 
>>>>> 
>>>>> Thank you.
>>>>> 
>>>>> Best regards
>>>> 
>>>> 
>>>> -- 
>>>> Sincerely yours
>>>> Mikhail Khludnev

Re: Solr 8.1 issue with collection aliases

Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
Please open a JIRA.

On Thu, 16 May, 2019, 8:09 AM Jörn Franke, <jo...@gmail.com> 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 <jo...@gmail.com>:
>
> Note only an admin UI issue. Access collections via their alias does not
> work.
>
> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev <mk...@apache.org>:
>
> 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&name=testalias&collections=gettingstarted
>  successfully.
> Jörn, thanks for reporting.
>
> On Tue, May 14, 2019 at 11:03 PM Jörn Franke <jo...@gmail.com> 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
>> org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat
>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
>> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
>>
>> org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat
>>
>> org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:126)\n\tat
>>
>> org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:338)\n\tat
>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>>
>> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)\n\tat
>>
>> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)\n\tat
>>
>> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)\n\tat
>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>> org.eclipse.jetty.io
>> .ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)\n\tat
>>
>> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)\n\tat
>>
>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)\n\tat
>>
>> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)\n\tat
>> java.base/java.lang.Thread.run(Thread.java:834)\n",
>>     "code":500}}
>>
>>
>> Thank you.
>>
>> Best regards
>>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
>
>

Re: Solr 8.1 issue with collection aliases

Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
Please open a JIRA.

On Thu, 16 May, 2019, 8:09 AM Jörn Franke, <jo...@gmail.com> 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 <jo...@gmail.com>:
>
> Note only an admin UI issue. Access collections via their alias does not
> work.
>
> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev <mk...@apache.org>:
>
> 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&name=testalias&collections=gettingstarted
>  successfully.
> Jörn, thanks for reporting.
>
> On Tue, May 14, 2019 at 11:03 PM Jörn Franke <jo...@gmail.com> 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
>> org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat
>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
>> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
>>
>> org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat
>>
>> org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:126)\n\tat
>>
>> org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:338)\n\tat
>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>>
>> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)\n\tat
>>
>> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)\n\tat
>>
>> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)\n\tat
>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>> org.eclipse.jetty.io
>> .ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)\n\tat
>>
>> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)\n\tat
>>
>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)\n\tat
>>
>> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)\n\tat
>> java.base/java.lang.Thread.run(Thread.java:834)\n",
>>     "code":500}}
>>
>>
>> Thank you.
>>
>> Best regards
>>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
>
>

Re: Solr 8.1 issue with collection aliases

Posted by Jörn Franke <jo...@gmail.com>.
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 <jo...@gmail.com>:
> 
> Note only an admin UI issue. Access collections via their alias does not work.
> 
>> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev <mk...@apache.org>:
>> 
>> 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&name=testalias&collections=gettingstarted  successfully. 
>> Jörn, thanks for reporting. 
>> 
>>> On Tue, May 14, 2019 at 11:03 PM Jörn Franke <jo...@gmail.com> 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
>>> org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat
>>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
>>> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
>>> org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat
>>> org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:126)\n\tat
>>> org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:338)\n\tat
>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>>> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)\n\tat
>>> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)\n\tat
>>> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)\n\tat
>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>>> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)\n\tat
>>> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)\n\tat
>>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)\n\tat
>>> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)\n\tat
>>> java.base/java.lang.Thread.run(Thread.java:834)\n",
>>>     "code":500}}
>>> 
>>> 
>>> Thank you.
>>> 
>>> Best regards
>> 
>> 
>> -- 
>> Sincerely yours
>> Mikhail Khludnev

Re: Solr 8.1 issue with collection aliases

Posted by Jörn Franke <jo...@gmail.com>.
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 <jo...@gmail.com>:
> 
> Note only an admin UI issue. Access collections via their alias does not work.
> 
>> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev <mk...@apache.org>:
>> 
>> 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&name=testalias&collections=gettingstarted  successfully. 
>> Jörn, thanks for reporting. 
>> 
>>> On Tue, May 14, 2019 at 11:03 PM Jörn Franke <jo...@gmail.com> 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
>>> org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat
>>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
>>> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
>>> org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat
>>> org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:126)\n\tat
>>> org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:338)\n\tat
>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>>> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)\n\tat
>>> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)\n\tat
>>> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)\n\tat
>>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>>> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)\n\tat
>>> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)\n\tat
>>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)\n\tat
>>> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)\n\tat
>>> java.base/java.lang.Thread.run(Thread.java:834)\n",
>>>     "code":500}}
>>> 
>>> 
>>> Thank you.
>>> 
>>> Best regards
>> 
>> 
>> -- 
>> Sincerely yours
>> Mikhail Khludnev

Re: Solr 8.1 issue with collection aliases

Posted by Jörn Franke <jo...@gmail.com>.
Note only an admin UI issue. Access collections via their alias does not work.

> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev <mk...@apache.org>:
> 
> 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&name=testalias&collections=gettingstarted  successfully. 
> Jörn, thanks for reporting. 
> 
>> On Tue, May 14, 2019 at 11:03 PM Jörn Franke <jo...@gmail.com> 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
>> org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat
>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
>> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
>> org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat
>> org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:126)\n\tat
>> org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:338)\n\tat
>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)\n\tat
>> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)\n\tat
>> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)\n\tat
>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)\n\tat
>> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)\n\tat
>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)\n\tat
>> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)\n\tat
>> java.base/java.lang.Thread.run(Thread.java:834)\n",
>>     "code":500}}
>> 
>> 
>> Thank you.
>> 
>> Best regards
> 
> 
> -- 
> Sincerely yours
> Mikhail Khludnev

Re: Solr 8.1 issue with collection aliases

Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
Thanks Jörn for reporting this. Sounds like some backward comparability
break with aliases. Can you please open a JIRA? I'll take a look at
reproducing it soon.

On Wed, 15 May, 2019, 7:18 PM Mikhail Khludnev, <mk...@apache.org> wrote:

> 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&name=testalias&collections=gettingstarted
>  successfully.
> Jörn, thanks for reporting.
>
> On Tue, May 14, 2019 at 11:03 PM Jörn Franke <jo...@gmail.com> 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
>> org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat
>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
>> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
>>
>> org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat
>>
>> org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:126)\n\tat
>>
>> org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:338)\n\tat
>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>>
>> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)\n\tat
>>
>> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)\n\tat
>>
>> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)\n\tat
>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>> org.eclipse.jetty.io
>> .ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)\n\tat
>>
>> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)\n\tat
>>
>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)\n\tat
>>
>> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)\n\tat
>> java.base/java.lang.Thread.run(Thread.java:834)\n",
>>     "code":500}}
>>
>>
>> Thank you.
>>
>> Best regards
>>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
>

Re: Solr 8.1 issue with collection aliases

Posted by Jörn Franke <jo...@gmail.com>.
Note only an admin UI issue. Access collections via their alias does not work.

> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev <mk...@apache.org>:
> 
> 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&name=testalias&collections=gettingstarted  successfully. 
> Jörn, thanks for reporting. 
> 
>> On Tue, May 14, 2019 at 11:03 PM Jörn Franke <jo...@gmail.com> 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
>> org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat
>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
>> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
>> org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat
>> org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:126)\n\tat
>> org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:338)\n\tat
>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)\n\tat
>> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)\n\tat
>> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)\n\tat
>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)\n\tat
>> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)\n\tat
>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)\n\tat
>> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)\n\tat
>> java.base/java.lang.Thread.run(Thread.java:834)\n",
>>     "code":500}}
>> 
>> 
>> Thank you.
>> 
>> Best regards
> 
> 
> -- 
> Sincerely yours
> Mikhail Khludnev

Re: Solr 8.1 issue with collection aliases

Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
Thanks Jörn for reporting this. Sounds like some backward comparability
break with aliases. Can you please open a JIRA? I'll take a look at
reproducing it soon.

On Wed, 15 May, 2019, 7:18 PM Mikhail Khludnev, <mk...@apache.org> wrote:

> 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&name=testalias&collections=gettingstarted
>  successfully.
> Jörn, thanks for reporting.
>
> On Tue, May 14, 2019 at 11:03 PM Jörn Franke <jo...@gmail.com> 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
>> org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat
>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
>> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
>>
>> org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat
>>
>> org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:126)\n\tat
>>
>> org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:338)\n\tat
>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>>
>> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)\n\tat
>>
>> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)\n\tat
>>
>> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)\n\tat
>> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>> org.eclipse.jetty.io
>> .ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)\n\tat
>>
>> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)\n\tat
>>
>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)\n\tat
>>
>> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)\n\tat
>> java.base/java.lang.Thread.run(Thread.java:834)\n",
>>     "code":500}}
>>
>>
>> Thank you.
>>
>> Best regards
>>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
>

Re: Solr 8.1 issue with collection aliases

Posted by Mikhail Khludnev <mk...@apache.org>.
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&name=testalias&collections=gettingstarted
 successfully.
Jörn, thanks for reporting.

On Tue, May 14, 2019 at 11:03 PM Jörn Franke <jo...@gmail.com> 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
> org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
>
> org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat
>
> org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:126)\n\tat
>
> org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:338)\n\tat
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>
> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)\n\tat
>
> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)\n\tat
>
> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)\n\tat
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)\n\tat
>
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)\n\tat
> java.base/java.lang.Thread.run(Thread.java:834)\n",
>     "code":500}}
>
>
> Thank you.
>
> Best regards
>


-- 
Sincerely yours
Mikhail Khludnev

Re: Solr 8.1 issue with collection aliases

Posted by Mikhail Khludnev <mk...@apache.org>.
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&name=testalias&collections=gettingstarted
 successfully.
Jörn, thanks for reporting.

On Tue, May 14, 2019 at 11:03 PM Jörn Franke <jo...@gmail.com> 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
> org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
>
> org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat
>
> org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:126)\n\tat
>
> org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:338)\n\tat
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
>
> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)\n\tat
>
> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)\n\tat
>
> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)\n\tat
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\n\tat
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)\n\tat
>
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)\n\tat
> java.base/java.lang.Thread.run(Thread.java:834)\n",
>     "code":500}}
>
>
> Thank you.
>
> Best regards
>


-- 
Sincerely yours
Mikhail Khludnev