[jira] [Updated] (SOLR-9139) ReplicationHandler getReplicationDetails() returns previous replicationData
[ https://issues.apache.org/jira/browse/SOLR-9139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun Mani updated SOLR-9139: Description: ReplicationHandler has volatile class member snapShootDetails. The variable is not reset on new submission. Usecase: On Core1 running a JVM1, submit a replication request. I poll this thread to check the replication status invoking the handler passing "command=details". Issue: I submit request1 on core1 to create replication. Poll the status using details. Once the replication is complete, i submit the replication request2 on core1 again. When when we poll using handler for replication details, it still has request1 details. I think on new submission, the previous request details(request1 in this eg) should be reset (meaning snapshotdetails= null) on new request. The getDetails should be returned the status of request2 instead of request1 details. This doesn't happen untill request2 either succeeds or fails. was: ReplicationHandler has volatile class member snapShootDetails. The variable is not reset on new submission. Usecase: On Core1 running a JVM1, submit a replication request. I poll this thread to check the replication status invoking the handler passing "command=details". Issue: I submit request1 on core1 to create replication. Poll the status using details. Once the replication is complete, i submit the replication request2 on core1 again. When when we poll using handler for replication details, it still has request1 details. I think on new submission, the previous request details(request1 in this eg) should be reset (meaning snapshotdetails= null) on new request. We don't have to wait till the request2 snapshot completes. > ReplicationHandler getReplicationDetails() returns previous replicationData > --- > > Key: SOLR-9139 > URL: https://issues.apache.org/jira/browse/SOLR-9139 > Project: Solr > Issue Type: Bug > Components: replication (java) >Affects Versions: 5.5 >Reporter: Arun Mani >Priority: Minor > > ReplicationHandler has volatile class member snapShootDetails. > The variable is not reset on new submission. > Usecase: > On Core1 running a JVM1, submit a replication request. > I poll this thread to check the replication status invoking the handler > passing "command=details". > Issue: > I submit request1 on core1 to create replication. Poll the status using > details. > Once the replication is complete, i submit the replication request2 on core1 > again. When when we poll using handler for replication details, it still has > request1 details. > I think on new submission, the previous request details(request1 in this eg) > should be reset (meaning snapshotdetails= null) on new request. > The getDetails should be returned the status of request2 instead of request1 > details. This doesn't happen untill request2 either succeeds or fails. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9139) ReplicationHandler getReplicationDetails() returns previous replicationData
[ https://issues.apache.org/jira/browse/SOLR-9139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun Mani updated SOLR-9139: Description: ReplicationHandler has volatile class member snapShootDetails. The variable is not reset on new submission. Usecase: On Core1 running a JVM1, submit a replication request. I poll this thread to check the replication status invoking the handler passing "command=details". Issue: I submit request1 on core1 to create replication. Poll the status using details. Once the replication is complete, i submit the replication request2 on core1 again. When when we poll using handler for replication details, it still has request1 details. I think on new submission, the previous request details(request1 in this eg) should be reset (meaning snapshotdetails= null) on new request. We don't have to wait till the request2 snapshot completes. was: ReplicationHandler has volatile class member snapShootDetails. The variable is not reset to on new submission. Usecase: On Core1 running a JVM1, submit a replication request. I poll this thread to check the replication status invoking the handler passing "command=details". Issue: I submit request1 on core1 to create replication. Poll the status using details. Once the replication is complete, i submit the replication request2 on core1 again. When when we poll using handler for replication details, it still has request1 details. I think on new submission, the previous request details(request1 in this eg) should be reset (meaning snapshotdetails= null) on new request. We don't have to wait till the request2 snapshot completes. > ReplicationHandler getReplicationDetails() returns previous replicationData > --- > > Key: SOLR-9139 > URL: https://issues.apache.org/jira/browse/SOLR-9139 > Project: Solr > Issue Type: Bug > Components: replication (java) >Affects Versions: 5.5 >Reporter: Arun Mani >Priority: Minor > > ReplicationHandler has volatile class member snapShootDetails. > The variable is not reset on new submission. > Usecase: > On Core1 running a JVM1, submit a replication request. > I poll this thread to check the replication status invoking the handler > passing "command=details". > Issue: > I submit request1 on core1 to create replication. Poll the status using > details. > Once the replication is complete, i submit the replication request2 on core1 > again. When when we poll using handler for replication details, it still has > request1 details. > I think on new submission, the previous request details(request1 in this eg) > should be reset (meaning snapshotdetails= null) on new request. > We don't have to wait till the request2 snapshot completes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-9139) ReplicationHandler getReplicationDetails() returns previous replicationData
Arun Mani created SOLR-9139: --- Summary: ReplicationHandler getReplicationDetails() returns previous replicationData Key: SOLR-9139 URL: https://issues.apache.org/jira/browse/SOLR-9139 Project: Solr Issue Type: Bug Components: replication (java) Affects Versions: 5.5 Reporter: Arun Mani Priority: Minor ReplicationHandler has volatile class member snapShootDetails. The variable is not reset to on new submission. Usecase: On Core1 running a JVM1, submit a replication request. I poll this thread to check the replication status invoking the handler passing "command=details". Issue: I submit request1 on core1 to create replication. Poll the status using details. Once the replication is complete, i submit the replication request2 on core1 again. When when we poll using handler for replication details, it still has request1 details. I think on new submission, the previous request details(request1 in this eg) should be reset (meaning snapshotdetails= null) on new request. We don't have to wait till the request2 snapshot completes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8059) NPE distributed DebugComponent
[
https://issues.apache.org/jira/browse/SOLR-8059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15035117#comment-15035117
]
Mani commented on SOLR-8059:
In addition to the above this can be narrowed down to without looking at the
source code *fl=id,score* & *debug=results* NPE is thrown.
*Steps to reproduce*
./bin/solr start -e cloud #2 shards, 1 replica
./bin/solr status
./bin/post -c techproducts example/exampledocs/*.xml
{noformat}
curl
"http://localhost:8983/solr/techproducts/select?q=*%3A*=json=true=true=id,score;
=> NPE thrown
curl
"http://localhost:8983/solr/techproducts/select?q=*%3A*=ruby=true=results=id,score;
=> NPE thrown
{noformat}
Following curl examples works fine
curl
"http://localhost:8983/solr/techproducts/select?q=*%3A*=ruby=true=query=id,score;
curl
"http://localhost:8983/solr/techproducts/select?q=*%3A*=ruby=true=timing=id,score;
curl
"http://localhost:8983/solr/techproducts/select?q=*%3A*=ruby=true=track=id,score;
> NPE distributed DebugComponent
> --
>
> Key: SOLR-8059
> URL: https://issues.apache.org/jira/browse/SOLR-8059
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
>Assignee: Shalin Shekhar Mangar
> Fix For: 5.4
>
>
> The following URL select?debug=true=*:*=id,score yields
> {code}
> java.lang.NullPointerException
> at
> org.apache.solr.handler.component.DebugComponent.finishStage(DebugComponent.java:229)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:416)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:210)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> I can reproduce it everytime. Strange enough fl=*,score, or any other content
> field does not! I have seen this happening in Highlighter as well on the same
> code path. It makes little sense, how would fl influence that piece of code,
> the id is requested in fl afterall.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8059) NPE distributed DebugComponent
[
https://issues.apache.org/jira/browse/SOLR-8059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15035214#comment-15035214
]
Mani commented on SOLR-8059:
[~shalinmangar] Since I do not have enough context/understanding about the
DebugComponent, I have just updated with the reproducer. If you have any
comments with the test let me know I can submit an updated patch.
> NPE distributed DebugComponent
> --
>
> Key: SOLR-8059
> URL: https://issues.apache.org/jira/browse/SOLR-8059
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
>Assignee: Shalin Shekhar Mangar
> Fix For: 5.4
>
>
> The following URL select?debug=true=*:*=id,score yields
> {code}
> java.lang.NullPointerException
> at
> org.apache.solr.handler.component.DebugComponent.finishStage(DebugComponent.java:229)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:416)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:210)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> I can reproduce it everytime. Strange enough fl=*,score, or any other content
> field does not! I have seen this happening in Highlighter as well on the same
> code path. It makes little sense, how would fl influence that piece of code,
> the id is requested in fl afterall.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7948) MapReduceIndexerTool of solr 5.2.1 doesn't work with hadoop 2.7.1
[ https://issues.apache.org/jira/browse/SOLR-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14903353#comment-14903353 ] Mani commented on SOLR-7948: Thank you [~davidchiu] & [~markrmil...@gmail.com] for the suggestions I faced a similar issue and jar harmonization on the client side helped me to resolve. Environment : Solr : 5.2.1 I was running a SolrJ Client Artifact in Jboss 6.2. And httpclient jars (4.2.1) part of system dependencies packaged along with jboss is conflicting & overriding the jars (4.4.1) packaged with my artifact. Using exclusions from [1] in the jboss-deployment-structure.xml one can prevent the server to automatically add the dependencies. [1] https://docs.jboss.org/author/display/AS72/Class+Loading+in+AS7 > MapReduceIndexerTool of solr 5.2.1 doesn't work with hadoop 2.7.1 > - > > Key: SOLR-7948 > URL: https://issues.apache.org/jira/browse/SOLR-7948 > Project: Solr > Issue Type: Bug > Components: contrib - MapReduce >Affects Versions: 5.2.1 > Environment: OS:suse 11 > JDK:java version "1.7.0_65" > Java(TM) SE Runtime Environment (build 1.7.0_65-b17) > Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode) > HADOOP:hadoop 2.7.1 > SOLR:5.2.1 >Reporter: davidchiu >Assignee: Mark Miller > > When I used MapReduceIndexerTool of 5.2.1 to index files, I got follwoing > errors,but I used 4.9.0's MapReduceIndexerTool, it did work with hadoop 2.7.1. > Exception ERROR as following: > INFO - 2015-08-20 11:44:45.155; [ ] org.apache.solr.hadoop.HeartBeater; > Heart beat reporting class is > org.apache.hadoop.mapreduce.task.TaskAttemptContextImpl > INFO - 2015-08-20 11:44:45.161; [ ] > org.apache.solr.hadoop.SolrRecordWriter; Using this unpacked directory as > solr home: > /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip > INFO - 2015-08-20 11:44:45.162; [ ] > org.apache.solr.hadoop.SolrRecordWriter; Creating embedded Solr server with > solrHomeDir: > /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip, > fs: > DFS[DFSClient[clientName=DFSClient_attempt_1440040092614_0004_r_01_0_1678264055_1, > ugi=root (auth:SIMPLE)]], outputShardDir: > hdfs://127.0.0.1:9000/tmp/outdir/reducers/_temporary/1/_temporary/attempt_1440040092614_0004_r_01_0/part-r-1 > INFO - 2015-08-20 11:44:45.194; [ ] > org.apache.solr.core.SolrResourceLoader; new SolrResourceLoader for > directory: > '/usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/' > INFO - 2015-08-20 11:44:45.206; [ ] org.apache.solr.hadoop.HeartBeater; > HeartBeat thread running > INFO - 2015-08-20 11:44:45.207; [ ] org.apache.solr.hadoop.HeartBeater; > Issuing heart beat for 1 threads > INFO - 2015-08-20 11:44:45.418; [ ] > org.apache.solr.hadoop.SolrRecordWriter; Constructed instance information > solr.home > /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip > > (/usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip), > instance dir > /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/, > conf dir > /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/conf/, > writing index to solr.data.dir > hdfs://127.0.0.1:9000/tmp/outdir/reducers/_temporary/1/_temporary/attempt_1440040092614_0004_r_01_0/part-r-1/data, > with permdir > hdfs://127.0.0.10:9000/tmp/outdir/reducers/_temporary/1/_temporary/attempt_1440040092614_0004_r_01_0/part-r-1 > INFO - 2015-08-20 11:44:45.426; [ ] org.apache.solr.core.SolrXmlConfig; > Loading container configuration from > /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/solr.xml > INFO - 2015-08-20 11:44:45.474; [ ] > org.apache.solr.core.CorePropertiesLocator; Config-defined core root > directory: >
