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