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 Andy Jolly <jo...@gmail.com> on 2018/03/01 21:26:01 UTC
SolrCloud 7.2.1 - UnsupportedOperationException thrown after query
on specific environments
We are receiving an UnsupportedOperationException after making certain
requests. The requests themselves do not seem to be causing the issue as
when we run the job that makes these requests locally against the same
SolrCloud cluster where the errors are being thrown, there are no errors.
These errors only occur when we run this job from our remote job server.
In the log snippet are the last few requests made before the error is
thrown.
This error started happening after we did an upgrade from solr 6.3.0 to Solr
7.2.1. We believe the line causing the issue in Solr's HttpSolrCall.java is
/collectionsList.add(collectionName);/ in the getRemotCoreUrl method as
collectionsList is immutable (perhaps because it is set to
Collections.emptyList() in the resolveCollectionListOrAlias method).
We are not completely confident this is a bug in Solr, but are unsure what
could be causing this issue on our end. Does anyone have any insights as to
what could cause this error?
--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Re: SolrCloud 7.2.1 - UnsupportedOperationException thrown after
query on specific environments
Posted by Andy Jolly <jo...@gmail.com>.
Erick Erickson wrote
> Maybe your remote job server is using a different set of jars than
> your local one? How does the remote job server work?
The remote job server and our local are running the same code as our local,
and both our local and remote job server are making queries against the same
SolrCloud cluster. The main difference is we are running the job on our
local through a unit test that kicks off the entire job.
We have noticed that these errors are being thrown on all of our Solr nodes,
not just the node containing the collection that is being queried.
Erick Erickson wrote
> No log snippets came through BTW, so I'm guessing a bit. The Apache
> mail server is quite aggressive about stripping stuff....
Here is the log snippet without any formatting. Hopefully that should work.
2018-03-01 20:01:13.009 INFO (qtp20671747-2258) [c:mycollection s:shard1
r:core_node2 x:mycollection_shard1_replica_n1] o.a.s.c.S.Request
[mycollection_shard1_replica_n1] webapp=/solr path=/select
params={q=id:79ea39cb1fe01706a05d9595088fc0e04af7b5bf&defType=edismax&bf=recip(ms(NOW,published_on),3.16e-11,1,1)^2.0&start=0&fq=-excluded_tenants:(1)&fq=type:(News)&rows=1&version=2.2}
hits=1 status=0 QTime=0
2018-03-01 20:01:12.998 INFO (qtp20671747-2231) [c:mycollection s:shard1
r:core_node2 x:mycollection_shard1_replica_n1] o.a.s.c.S.Request
[mycollection_shard1_replica_n1] webapp=/solr path=/select
params={q=id:66d7fa7c716633e33aacf5b8514052f42889267f&defType=edismax&start=0&fq=type:(Job)&rows=1&version=2.2}
hits=0 status=0 QTime=0
2018-03-01 20:01:12.998 INFO (qtp20671747-2257) [c:mycollection s:shard1
r:core_node2 x:mycollection_shard1_replica_n1] o.a.s.c.S.Request
[mycollection_shard1_replica_n1] webapp=/solr path=/select
params={q=id:5f02f0d8034a15c4604baec33c40c1f48152ffdf&defType=edismax&start=0&fq=type:(Job)&rows=1&version=2.2}
hits=1 status=0 QTime=0
2018-02-28 20:00:11.713 ERROR (qtp20671747-314) [ ] o.a.s.s.HttpSolrCall
null:java.lang.UnsupportedOperationException
at java.util.AbstractList.add(AbstractList.java:148)
at java.util.AbstractList.add(AbstractList.java:108)
at
org.apache.solr.servlet.HttpSolrCall.getRemotCoreUrl(HttpSolrCall.java:901)
at
org.apache.solr.servlet.HttpSolrCall.extractRemotePath(HttpSolrCall.java:432)
at org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:289)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:470)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:534)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
at
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
at
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
at
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.lang.Thread.run(Thread.java:748)
--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Re: SolrCloud 7.2.1 - UnsupportedOperationException thrown after
query on specific environments
Posted by Erick Erickson <er...@gmail.com>.
bq: These errors only occur when we run this job from our remote job server
Maybe your remote job server is using a different set of jars than
your local one? How does the remote job server work?
No log snippets came through BTW, so I'm guessing a bit. The Apache
mail server is quite aggressive about stripping stuff....
Best,
Erick
On Thu, Mar 1, 2018 at 1:26 PM, Andy Jolly <jo...@gmail.com> wrote:
> We are receiving an UnsupportedOperationException after making certain
> requests. The requests themselves do not seem to be causing the issue as
> when we run the job that makes these requests locally against the same
> SolrCloud cluster where the errors are being thrown, there are no errors.
> These errors only occur when we run this job from our remote job server.
>
>
>
> In the log snippet are the last few requests made before the error is
> thrown.
>
> This error started happening after we did an upgrade from solr 6.3.0 to Solr
> 7.2.1. We believe the line causing the issue in Solr's HttpSolrCall.java is
> /collectionsList.add(collectionName);/ in the getRemotCoreUrl method as
> collectionsList is immutable (perhaps because it is set to
> Collections.emptyList() in the resolveCollectionListOrAlias method).
>
> We are not completely confident this is a bug in Solr, but are unsure what
> could be causing this issue on our end. Does anyone have any insights as to
> what could cause this error?
>
>
>
> --
> Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Re: SolrCloud 7.2.1 - UnsupportedOperationException thrown after
query on specific environments
Posted by Andy Jolly <jo...@gmail.com>.
We were able to locate the exact issue after some more digging. We added a
query to another collection that runs alongside the job we were executing
and we were missing the collection reference in the URL. If the below query
is run by itself in at least Solr 7, the error will be reproduced.
http://localhost:8983/solr//select?q=*:*
Since the collection was left empty, collectionsList in HttpSolrCall.java
was being set to an immutable Collections.emptyList() by the
resolveCollectionListOrAlias method. Then, when
collectionsList.add(collectionName) was called in the getRemotCoreUrl method
the error we are seeing is thrown as it is trying to add to an immutable
list.
--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html