[jira] [Commented] (SOLR-7198) Deleting a collection during leader election results in left over znodes in ZK
[
https://issues.apache.org/jira/browse/SOLR-7198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14350730#comment-14350730
]
Vamsee Yarlagadda commented on SOLR-7198:
-
Thanks for highlighting this. I will update the description to reflect this.
> Deleting a collection during leader election results in left over znodes in
> ZK
> ---
>
> Key: SOLR-7198
> URL: https://issues.apache.org/jira/browse/SOLR-7198
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 4.10.3
>Reporter: Vamsee Yarlagadda
>
> I am seeing this issue while trying to run a collection delete operation in
> the middle of leader election process.
> Contents of ZK (after issuing collection delete and waiting for some time)
> {code}
> /
> /aliases.json
> /clusterstate.json
> /collections
> SolrUpgrade_collection
> leaders
>shard2_1
> /configs
> /live_nodes
> /overseer
> /overseer_elect
> /solr
> /solr.xml
> Contents of znode shard2_1:
> version0
> aversion0
> children_count0
> ctimeThu Mar 05 22:05:28 PST 2015 (1425621928169)
> cversion0
> czxid22815
> ephemeralOwner93427899815755800
> mtimeThu Mar 05 22:05:28 PST 2015 (1425621928169)
> mzxid22815
> pzxid22815
> dataLength194
> {
> "core":"SolrUpgrade_collection_shard2_1_replica2",
> "node_name":"search-testing-c5-ha-1.vpc.cloudera.com:8983_solr",
> "base_url":"http://search-testing-c5-ha-1.vpc.cloudera.com:8983/solr";
> }
> {code}
> Clusterstate.json before running a delete collection
> {code}
> {
> "shards":{
> "shard1":{
> "range":"8000-",
> "state":"active",
> "replicas":{
> "core_node1":{
> "state":"active",
> "core":"SolrUpgrade_collection_shard1_replica2",
> "node_name":"search-testing-c5-ha-4.vpc.cloudera.com:8983_solr",
>
> "base_url":"http://search-testing-c5-ha-4.vpc.cloudera.com:8983/solr";,
> "leader":"true"},
> "core_node2":{
> "state":"active",
> "core":"SolrUpgrade_collection_shard1_replica1",
> "node_name":"search-testing-c5-ha-2.vpc.cloudera.com:8983_solr",
>
> "base_url":"http://search-testing-c5-ha-2.vpc.cloudera.com:8983/solr"}}},
> "shard2_0":{
> "range":"0-3fff",
> "state":"active",
> "replicas":{
> "core_node5":{
> "state":"active",
> "core":"SolrUpgrade_collection_shard2_0_replica1",
> "node_name":"search-testing-c5-ha-3.vpc.cloudera.com:8983_solr",
>
> "base_url":"http://search-testing-c5-ha-3.vpc.cloudera.com:8983/solr";,
> "leader":"true"},
> "core_node7":{
> "state":"active",
> "core":"SolrUpgrade_collection_shard2_0_replica2",
> "node_name":"search-testing-c5-ha-4.vpc.cloudera.com:8983_solr",
>
> "base_url":"http://search-testing-c5-ha-4.vpc.cloudera.com:8983/solr"}}},
> "shard2_1":{
> "range":"4000-7fff",
> "state":"active",
> "replicas":{
> "core_node8":{
> "state":"active",
> "core":"SolrUpgrade_collection_shard2_1_replica2",
> "node_name":"search-testing-c5-ha-1.vpc.cloudera.com:8983_solr",
>
> "base_url":"http://search-testing-c5-ha-1.vpc.cloudera.com:8983/solr"},
> "core_node9":{
> "state":"active",
> "core":"SolrUpgrade_collection_shard2_1_replica3",
> "node_name":"search-testing-c5-ha-1.vpc.cloudera.com:8983_solr",
>
> "base_url":"http://search-testing-c5-ha-1.vpc.cloudera.com:8983/solr",
> "maxShardsPerNode":"10",
> "router":"compositeId",
> "replicationFactor":"2",
> "autoAddReplicas":"false",
> "routerSpec":{"name":"compositeId"}}}
> {code}
> As we can notice, shard (*shard2_1*) doesn't have any leader and i can see
> from the logs that the replicas of the shard just started the leader election
> process. And here are the Solr logs from one of the above replicas which
> eventually becomes the leader and registers in ZK even though the collection
> was deleted.
> {code}
> 2015-03-05 22:05:25,383 INFO
> org.apache.solr.cloud.ShardLeaderElectionContext: Running the leader process
> for shard shard2_1
> 2015-03-05 22:05:25,387 INFO
> org.apache.solr.cloud.ShardLeaderElectionContext: Checking if I
> (core=SolrUpgrade_collection_shard2_1_replica2,coreNodeName=core_node8)
> should try and be the leader.
> 2015-03-05 22:05:25,387 INFO
> org.apache.solr.cloud.ShardLeaderElectionContext: My last published State was
> Active, it's okay to be the leader.
> 2015-03-05 22:05:25,387 INFO
> org.apache.solr.cloud.ShardLeaderElectionContext: I may be the new leader -
> try and sync
> 2015-03-05 22:05:25,506 INF
[jira] [Updated] (SOLR-7198) Deleting a collection during leader election results in left over znodes in ZK
[
https://issues.apache.org/jira/browse/SOLR-7198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsee Yarlagadda updated SOLR-7198:
Description:
I am seeing this issue while trying to run a collection delete operation in the
middle of leader election process.
Contents of ZK (after issuing collection delete and waiting for some time)
{code}
/
/aliases.json
/clusterstate.json
/collections
SolrUpgrade_collection
leaders
shard2_1
/configs
/live_nodes
/overseer
/overseer_elect
/solr
/solr.xml
Contents of znode shard2_1:
version0
aversion0
children_count0
ctimeThu Mar 05 22:05:28 PST 2015 (1425621928169)
cversion0
czxid22815
ephemeralOwner93427899815755800
mtimeThu Mar 05 22:05:28 PST 2015 (1425621928169)
mzxid22815
pzxid22815
dataLength194
{
"core":"SolrUpgrade_collection_shard2_1_replica2",
"node_name":"search-testing-c5-ha-1.vpc.cloudera.com:8983_solr",
"base_url":"http://search-testing-c5-ha-1.vpc.cloudera.com:8983/solr";
}
{code}
Clusterstate.json before running a delete collection
{code}
{
"shards":{
"shard1":{
"range":"8000-",
"state":"active",
"replicas":{
"core_node1":{
"state":"active",
"core":"SolrUpgrade_collection_shard1_replica2",
"node_name":"search-testing-c5-ha-4.vpc.cloudera.com:8983_solr",
"base_url":"http://search-testing-c5-ha-4.vpc.cloudera.com:8983/solr";,
"leader":"true"},
"core_node2":{
"state":"active",
"core":"SolrUpgrade_collection_shard1_replica1",
"node_name":"search-testing-c5-ha-2.vpc.cloudera.com:8983_solr",
"base_url":"http://search-testing-c5-ha-2.vpc.cloudera.com:8983/solr"}}},
"shard2_0":{
"range":"0-3fff",
"state":"active",
"replicas":{
"core_node5":{
"state":"active",
"core":"SolrUpgrade_collection_shard2_0_replica1",
"node_name":"search-testing-c5-ha-3.vpc.cloudera.com:8983_solr",
"base_url":"http://search-testing-c5-ha-3.vpc.cloudera.com:8983/solr";,
"leader":"true"},
"core_node7":{
"state":"active",
"core":"SolrUpgrade_collection_shard2_0_replica2",
"node_name":"search-testing-c5-ha-4.vpc.cloudera.com:8983_solr",
"base_url":"http://search-testing-c5-ha-4.vpc.cloudera.com:8983/solr"}}},
"shard2_1":{
"range":"4000-7fff",
"state":"active",
"replicas":{
"core_node8":{
"state":"active",
"core":"SolrUpgrade_collection_shard2_1_replica2",
"node_name":"search-testing-c5-ha-1.vpc.cloudera.com:8983_solr",
"base_url":"http://search-testing-c5-ha-1.vpc.cloudera.com:8983/solr"},
"core_node9":{
"state":"active",
"core":"SolrUpgrade_collection_shard2_1_replica3",
"node_name":"search-testing-c5-ha-1.vpc.cloudera.com:8983_solr",
"base_url":"http://search-testing-c5-ha-1.vpc.cloudera.com:8983/solr",
"maxShardsPerNode":"10",
"router":"compositeId",
"replicationFactor":"2",
"autoAddReplicas":"false",
"routerSpec":{"name":"compositeId"}}}
{code}
As we can notice, shard (*shard2_1*) doesn't have any leader and i can see from
the logs that the replicas of the shard just started the leader election
process. And here are the Solr logs from one of the above replicas which
eventually becomes the leader and registers in ZK even though the collection
was deleted.
{code}
2015-03-05 22:05:25,383 INFO org.apache.solr.cloud.ShardLeaderElectionContext:
Running the leader process for shard shard2_1
2015-03-05 22:05:25,387 INFO org.apache.solr.cloud.ShardLeaderElectionContext:
Checking if I
(core=SolrUpgrade_collection_shard2_1_replica2,coreNodeName=core_node8) should
try and be the leader.
2015-03-05 22:05:25,387 INFO org.apache.solr.cloud.ShardLeaderElectionContext:
My last published State was Active, it's okay to be the leader.
2015-03-05 22:05:25,387 INFO org.apache.solr.cloud.ShardLeaderElectionContext:
I may be the new leader - try and sync
2015-03-05 22:05:25,506 INFO org.apache.solr.common.cloud.ZkStateReader: A
cluster state change: WatchedEvent state:SyncConnected type:NodeDataChanged
path:/clusterstate.json, has occurred - updating... (live nodes size: 4)
2015-03-05 22:05:25,620 INFO org.apache.solr.core.SolrCore.Request:
[SolrUpgrade_collection_shard2_1_replica2] webapp=/solr path=/select
params={q=*:*&distrib=false&wt=javabin&version=2} hits=118 status=0 QTime=1
2015-03-05 22:05:25,623 INFO org.apache.solr.core.SolrCore.Request:
[SolrUpgrade_collection_shard2_1_replica3] webapp=/solr path=/select
params={q=*:*&distrib=false&wt=javabin&version=2} hits=118 status=0 QTime=0
2015-03-05 22:05:27,392 INFO org.apache.solr.cloud.ElectionContext: canceling
election
/collections/SolrUpgrade_collection/leader_elect/shard2_1/elec
[jira] [Created] (SOLR-7198) Deleting a collection during leader election results in left over znodes in ZK
Vamsee Yarlagadda created SOLR-7198:
---
Summary: Deleting a collection during leader election results in
left over znodes in ZK
Key: SOLR-7198
URL: https://issues.apache.org/jira/browse/SOLR-7198
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.10.3
Reporter: Vamsee Yarlagadda
I am seeing this issue while trying to run a collection delete operation in the
middle of leader election process.
Contents of ZK (after issuing collection delete and waiting for some time)
{code}
/
/aliases.json
/clusterstate.json
/collections
SolrUpgrade_collection
leaders
shard2_1
/configs
/live_nodes
/overseer
/overseer_elect
/solr
/solr.xml
Contents of znode shard2_1:
version0
aversion0
children_count0
ctimeThu Mar 05 22:05:28 PST 2015 (1425621928169)
cversion0
czxid22815
ephemeralOwner93427899815755800
mtimeThu Mar 05 22:05:28 PST 2015 (1425621928169)
mzxid22815
pzxid22815
dataLength194
{
"core":"SolrUpgrade_collection_shard2_1_replica2",
"node_name":"search-testing-c5-ha-1.vpc.cloudera.com:8983_solr",
"base_url":"http://search-testing-c5-ha-1.vpc.cloudera.com:8983/solr";
}
{code}
Clusterstate.json before running a delete collection
{code}
{
"shards":{
"shard1":{
"range":"8000-",
"state":"active",
"replicas":{
"core_node1":{
"state":"active",
"core":"SolrUpgrade_collection_shard1_replica2",
"node_name":"search-testing-c5-ha-4.vpc.cloudera.com:8983_solr",
"base_url":"http://search-testing-c5-ha-4.vpc.cloudera.com:8983/solr";,
"leader":"true"},
"core_node2":{
"state":"active",
"core":"SolrUpgrade_collection_shard1_replica1",
"node_name":"search-testing-c5-ha-2.vpc.cloudera.com:8983_solr",
"base_url":"http://search-testing-c5-ha-2.vpc.cloudera.com:8983/solr"}}},
"shard2_0":{
"range":"0-3fff",
"state":"active",
"replicas":{
"core_node5":{
"state":"active",
"core":"SolrUpgrade_collection_shard2_0_replica1",
"node_name":"search-testing-c5-ha-3.vpc.cloudera.com:8983_solr",
"base_url":"http://search-testing-c5-ha-3.vpc.cloudera.com:8983/solr";,
"leader":"true"},
"core_node7":{
"state":"active",
"core":"SolrUpgrade_collection_shard2_0_replica2",
"node_name":"search-testing-c5-ha-4.vpc.cloudera.com:8983_solr",
"base_url":"http://search-testing-c5-ha-4.vpc.cloudera.com:8983/solr"}}},
"shard2_1":{
"range":"4000-7fff",
"state":"active",
"replicas":{
"core_node8":{
"state":"active",
"core":"SolrUpgrade_collection_shard2_1_replica2",
"node_name":"search-testing-c5-ha-1.vpc.cloudera.com:8983_solr",
"base_url":"http://search-testing-c5-ha-1.vpc.cloudera.com:8983/solr"},
"core_node9":{
"state":"active",
"core":"SolrUpgrade_collection_shard2_1_replica3",
"node_name":"search-testing-c5-ha-1.vpc.cloudera.com:8983_solr",
"base_url":"http://search-testing-c5-ha-1.vpc.cloudera.com:8983/solr",
"maxShardsPerNode":"10",
"router":"compositeId",
"replicationFactor":"2",
"autoAddReplicas":"false",
"routerSpec":{"name":"compositeId"}}}
{code}
As we can notice, shard (*shard2_1*) doesn't have any leader and i can see from
the logs that the replicas of the shard just started the leader election
process. And here are the Solr logs from one of the above replicas which
eventually becomes the leader and registers in ZK even though the collection
was deleted.
{code}
2015-03-05 22:05:25,383 INFO org.apache.solr.cloud.ShardLeaderElectionContext:
Running the leader process for shard shard2_1
2015-03-05 22:05:25,387 INFO org.apache.solr.cloud.ShardLeaderElectionContext:
Checking if I
(core=SolrUpgrade_collection_shard2_1_replica2,coreNodeName=core_node8) should
try and be the leader.
2015-03-05 22:05:25,387 INFO org.apache.solr.cloud.ShardLeaderElectionContext:
My last published State was Active, it's okay to be the leader.
2015-03-05 22:05:25,387 INFO org.apache.solr.cloud.ShardLeaderElectionContext:
I may be the new leader - try and sync
2015-03-05 22:05:25,506 INFO org.apache.solr.common.cloud.ZkStateReader: A
cluster state change: WatchedEvent state:SyncConnected type:NodeDataChanged
path:/clusterstate.json, has occurred - updating... (live nodes size: 4)
2015-03-05 22:05:25,620 INFO org.apache.solr.core.SolrCore.Request:
[SolrUpgrade_collection_shard2_1_replica2] webapp=/solr path=/select
params={q=*:*&distrib=false&wt=javabin&version=2} hits=118 status=0 QTime=1
2015-03-05 22:05:25,623 INFO org.apache.solr.core.SolrCore.Request:
[SolrUpgrade_collection_shard2_1_replica3] webapp=/solr path=/select
params={
[jira] [Commented] (SOLR-7177) ConcurrentUpdateSolrClient should log connection information on http failures
[
https://issues.apache.org/jira/browse/SOLR-7177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14346028#comment-14346028
]
Vamsee Yarlagadda commented on SOLR-7177:
-
bq. In that case you know the URL - you had to init the class with it and this
is part of your client code. You can log whatever you want if the call fails on
the client side.
True. But at the same time we would have to add this logic of adding url
information at multiple places right (one at the server, one at the solrj
client)? If this is considered as the most basic info to be attached to the
exception we can do it at the ConcurrentUpdateSolrClient. If we need to add
some extra information on top of adding url info then this extra work can be
done at the place where we are init'ing the class. Thoughts?
> ConcurrentUpdateSolrClient should log connection information on http failures
> --
>
> Key: SOLR-7177
> URL: https://issues.apache.org/jira/browse/SOLR-7177
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.10.3, 5.0
>Reporter: Vamsee Yarlagadda
>Priority: Minor
> Attachments: SOLR-7177.patch, SOLR-7177v2.patch
>
>
> I notice when there is an http connection failure, we simply log the error
> but not the connection information. It would be good to log this info to make
> debugging easier.
> e.g:
> 1.
> {code}
> 2015-02-27 08:56:51,503 ERROR org.apache.solr.update.StreamingSolrServers:
> error
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:196)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at
> org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:166)
> at
> org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:90)
> at
> org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:281)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:92)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:62)
> at
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
> at
> org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
> at
> org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
> at
> org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
> at
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
> at
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
> at
> org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner.run(ConcurrentUpdateSolrServer.java:235)
> {code}
>
> 2.
> {code}
> 2015-02-27 10:26:12,363 ERROR org.apache.solr.update.StreamingSolrServers:
> error
> org.apache.http.NoHttpResponseException: The target server failed to respond
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:95)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:62)
> at
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
> at
> org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
> at
> org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
> at
> org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
> at
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
> at
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
> at
> org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:5
[jira] [Commented] (SOLR-7180) MiniSolrCloudCluster should startup and shutdown its jetties in parallel
[
https://issues.apache.org/jira/browse/SOLR-7180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14344457#comment-14344457
]
Vamsee Yarlagadda commented on SOLR-7180:
-
LGTM. One small concern.
{quote}
executor.invokeAll(startups);
executor.invokeAll(shutdowns);
{quote}
How do we know whether all the jetty runners came up/shutdown properly?
invokeAll will return once the Future.isDone() on every task right. But it
doesn't guarantee that there are no exceptions in the process.
> MiniSolrCloudCluster should startup and shutdown its jetties in parallel
>
>
> Key: SOLR-7180
> URL: https://issues.apache.org/jira/browse/SOLR-7180
> Project: Solr
> Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Attachments: SOLR-7180.patch
>
>
> Followup to SOLR-7179. Now JettySolrRunner doesn't use sysprops to pass
> configuration, we can start up multiple runners in parallel.
--
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] (LUCENE-6327) ArrayIndexOutOfBoundsException in reading a lucene block
Vamsee Yarlagadda created LUCENE-6327:
-
Summary: ArrayIndexOutOfBoundsException in reading a lucene block
Key: LUCENE-6327
URL: https://issues.apache.org/jira/browse/LUCENE-6327
Project: Lucene - Core
Issue Type: Bug
Reporter: Vamsee Yarlagadda
Priority: Minor
I notice this error while trying to do heavy indexing in Solr. This error was
seen in testing Cloudera Search (Solr 4.4 with lots of SolrCloud, other
critical bug fixes)
{code}
2015-02-27 04:21:46,644 INFO org.apache.solr.core.SolrCore.Request:
[crunch_sequence_collection_shard2_replica5] webapp=/solr path=/update
params={distrib.from=http://search-15.vpc.cloudera.com:8983/solr/crunch_sequence_collection_shard2_replica2/&update.distrib=FROMLEADER&wt=javabin&version=2}
status=0 QTime=246
2015-02-27 04:21:46,773 ERROR org.apache.solr.core.SolrCore:
java.lang.ArrayIndexOutOfBoundsException
at
org.apache.lucene.codecs.BlockTreeTermsReader$FieldReader$SegmentTermsEnum$Frame.fillTerm(BlockTreeTermsReader.java:2934)
at
org.apache.lucene.codecs.BlockTreeTermsReader$FieldReader$SegmentTermsEnum$Frame.scanToTermLeaf(BlockTreeTermsReader.java:2743)
at
org.apache.lucene.codecs.BlockTreeTermsReader$FieldReader$SegmentTermsEnum$Frame.scanToTerm(BlockTreeTermsReader.java:2662)
at
org.apache.lucene.codecs.BlockTreeTermsReader$FieldReader$SegmentTermsEnum.seekExact(BlockTreeTermsReader.java:1695)
at
org.apache.solr.search.SolrIndexSearcher.lookupId(SolrIndexSearcher.java:746)
at
org.apache.solr.update.VersionInfo.getVersionFromIndex(VersionInfo.java:193)
at org.apache.solr.update.UpdateLog.lookupVersion(UpdateLog.java:739)
at
org.apache.solr.update.VersionInfo.lookupVersion(VersionInfo.java:183)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:716)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:459)
at
org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:247)
at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:174)
at
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:92)
at
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1953)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:766)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.solr.servlet.SolrHadoopAuthenticationFilter$2.doFilter(SolrHadoopAuthenticationFilter.java:272)
at
org.apache.hadoop.security.authentication.server.AuthenticationFilter.doFilter(AuthenticationFilter.java:592)
at
org.apache.hadoop.security.token.delegation.web.DelegationTokenAuthenticationFilter.doFilter(DelegationTokenAuthenticationFilter.java:277)
at
org.apache.hadoop.security.authentication.server.AuthenticationFilter.doFilter(AuthenticationFilter.java:555)
at
org.apache.solr.servlet.SolrHadoopAuthenticationFilter.doFilter(SolrHadoopAuthenticationFilter.java:277)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.solr.servlet.HostnameFilter.doFilter(HostnameFilter.java:86)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:861)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHan
[jira] [Updated] (SOLR-7177) ConcurrentUpdateSolrClient should log connection information on http failures
[
https://issues.apache.org/jira/browse/SOLR-7177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsee Yarlagadda updated SOLR-7177:
Attachment: SOLR-7177v2.patch
Here is another revision of the patch.
We are now wrapping up the original exception in SolrServerException with
additional information.
> ConcurrentUpdateSolrClient should log connection information on http failures
> --
>
> Key: SOLR-7177
> URL: https://issues.apache.org/jira/browse/SOLR-7177
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.10.3, 5.0
>Reporter: Vamsee Yarlagadda
>Priority: Minor
> Attachments: SOLR-7177.patch, SOLR-7177v2.patch
>
>
> I notice when there is an http connection failure, we simply log the error
> but not the connection information. It would be good to log this info to make
> debugging easier.
> e.g:
> 1.
> {code}
> 2015-02-27 08:56:51,503 ERROR org.apache.solr.update.StreamingSolrServers:
> error
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:196)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at
> org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:166)
> at
> org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:90)
> at
> org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:281)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:92)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:62)
> at
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
> at
> org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
> at
> org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
> at
> org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
> at
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
> at
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
> at
> org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner.run(ConcurrentUpdateSolrServer.java:235)
> {code}
>
> 2.
> {code}
> 2015-02-27 10:26:12,363 ERROR org.apache.solr.update.StreamingSolrServers:
> error
> org.apache.http.NoHttpResponseException: The target server failed to respond
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:95)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:62)
> at
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
> at
> org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
> at
> org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
> at
> org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
> at
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
> at
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
> at
> org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner.run(ConcurrentUpdateSolrServer.java:235)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.ja
[jira] [Commented] (SOLR-7177) ConcurrentUpdateSolrClient should log connection information on http failures
[
https://issues.apache.org/jira/browse/SOLR-7177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14344152#comment-14344152
]
Vamsee Yarlagadda commented on SOLR-7177:
-
bq. I think it makes more sense to wrap the whole Exception in another
IOException with a message including the URL?
+1. This looks much cleaner. I am planning to use SolrServerException (as this
captures more of communication related errors).
bq. Why not just add this info where the exception is first thrown in solr cmd
distributor?
1. ConcurrentUpdateSolrClient is part of SolrJ right. Adding this info at this
class will also benefit all the end users who are directly using solrj api to
talk with Solr service. Adding this at SolrCmdDistributor will only expose this
to internal solr server log.
2. Moreover, ConcurrentUpdateSolrClient already does something similar to the
above proposed idea. We are just trying to extend the same idea.
https://github.com/apache/lucene-solr/blob/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/impl/ConcurrentUpdateSolrClient.java#L242
> ConcurrentUpdateSolrClient should log connection information on http failures
> --
>
> Key: SOLR-7177
> URL: https://issues.apache.org/jira/browse/SOLR-7177
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.10.3, 5.0
>Reporter: Vamsee Yarlagadda
>Priority: Minor
> Attachments: SOLR-7177.patch
>
>
> I notice when there is an http connection failure, we simply log the error
> but not the connection information. It would be good to log this info to make
> debugging easier.
> e.g:
> 1.
> {code}
> 2015-02-27 08:56:51,503 ERROR org.apache.solr.update.StreamingSolrServers:
> error
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:196)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at
> org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:166)
> at
> org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:90)
> at
> org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:281)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:92)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:62)
> at
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
> at
> org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
> at
> org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
> at
> org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
> at
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
> at
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
> at
> org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner.run(ConcurrentUpdateSolrServer.java:235)
> {code}
>
> 2.
> {code}
> 2015-02-27 10:26:12,363 ERROR org.apache.solr.update.StreamingSolrServers:
> error
> org.apache.http.NoHttpResponseException: The target server failed to respond
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:95)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:62)
> at
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
> at
> org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
> at
> org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
> at
> org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
> at
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
> at
> org.apache.http.protocol.HttpRequestEx
[jira] [Commented] (SOLR-6815) Issue with Collections in field value while indexing a document.
[
https://issues.apache.org/jira/browse/SOLR-6815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14341445#comment-14341445
]
Vamsee Yarlagadda commented on SOLR-6815:
-
Well thinking about this case more, it looks like may be it is intentional to
have setValue() simply take the object passed without making a copy of it (as
an optimization instead of redoing all the work to create a copy) and at the
same time we have addValue() which basically follows the typical way of creates
a copy. Thoughts?
> Issue with Collections in field value while indexing a document.
>
>
> Key: SOLR-6815
> URL: https://issues.apache.org/jira/browse/SOLR-6815
> Project: Solr
> Issue Type: Bug
> Components: clients - java
>Affects Versions: 4.9
>Reporter: Kiran Kumar Dontam
>Priority: Minor
> Attachments: SolrIndexingTest.java
>
>
> Issue with {{SolrInputDocument.addField()}} method.
> If this method is called for the first time for a field, it will call
> {{setField}} method, which calls {{SolrInputField.setValue}}.
> Assume that the value is a Collection in this flow. The value's reference is
> added to the field in the doc. If we add another value to the same field
> (using {{addField}}), it will be added to the original collection.
> This is incorrect because we are modifying user's original collection.
> This will break in the following cases:
> 1. If the original collection is unmodifiable. This will throw
> {{UnsupportedOperationException}} while adding 2nd value.
> 2. If the user wants to add the same value (Collection) to different fields,
> those fields may get corrupted. Adding more values to one fields will add
> them to other fields as well. (This is how I found the issue).
> One solution:
> In {{SolrInputField.setValue}} we can always create a new Collection
> (ArrayList) if the incoming value is a Collection.
--
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] [Comment Edited] (SOLR-6815) Issue with Collections in field value while indexing a document.
[
https://issues.apache.org/jira/browse/SOLR-6815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14341428#comment-14341428
]
Vamsee Yarlagadda edited comment on SOLR-6815 at 2/28/15 9:40 AM:
--
bq. 2. If the user wants to add the same value (Collection) to different
fields, those fields may get corrupted. Adding more values to one fields will
add them to other fields as well. (This is how I found the issue).
I agree. This is certainly a problem. I don't understand why this case was not
included in the first place.
https://github.com/apache/lucene-solr/blob/trunk/solr/solrj/src/java/org/apache/solr/common/SolrInputField.java#L60
This issue can be solved by creating a copy of the collection in setValue
method. In fact, we can move this section from addValue() itself.
Let me know if this makes sense. I can help putting up a patch.
was (Author: vamsee):
bq. 2. If the user wants to add the same value (Collection) to different
fields, those fields may get corrupted. Adding more values to one fields will
add them to other fields as well. (This is how I found the issue).
I agree. This is certainly a problem. I don't understand why this case was not
included in the first place.
https://github.com/apache/lucene-solr/blob/trunk/solr/solrj/src/java/org/apache/solr/common/SolrInputField.java#L60
This issue can be solved by creating a copy of the collection in setField
method. In fact, we can move this section from addField() itself.
Let me know if this makes sense. I can help putting up a patch.
> Issue with Collections in field value while indexing a document.
>
>
> Key: SOLR-6815
> URL: https://issues.apache.org/jira/browse/SOLR-6815
> Project: Solr
> Issue Type: Bug
> Components: clients - java
>Affects Versions: 4.9
>Reporter: Kiran Kumar Dontam
>Priority: Minor
> Attachments: SolrIndexingTest.java
>
>
> Issue with {{SolrInputDocument.addField()}} method.
> If this method is called for the first time for a field, it will call
> {{setField}} method, which calls {{SolrInputField.setValue}}.
> Assume that the value is a Collection in this flow. The value's reference is
> added to the field in the doc. If we add another value to the same field
> (using {{addField}}), it will be added to the original collection.
> This is incorrect because we are modifying user's original collection.
> This will break in the following cases:
> 1. If the original collection is unmodifiable. This will throw
> {{UnsupportedOperationException}} while adding 2nd value.
> 2. If the user wants to add the same value (Collection) to different fields,
> those fields may get corrupted. Adding more values to one fields will add
> them to other fields as well. (This is how I found the issue).
> One solution:
> In {{SolrInputField.setValue}} we can always create a new Collection
> (ArrayList) if the incoming value is a Collection.
--
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-6815) Issue with Collections in field value while indexing a document.
[
https://issues.apache.org/jira/browse/SOLR-6815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14341428#comment-14341428
]
Vamsee Yarlagadda commented on SOLR-6815:
-
bq. 2. If the user wants to add the same value (Collection) to different
fields, those fields may get corrupted. Adding more values to one fields will
add them to other fields as well. (This is how I found the issue).
I agree. This is certainly a problem. I don't understand why this case was not
included in the first place.
https://github.com/apache/lucene-solr/blob/trunk/solr/solrj/src/java/org/apache/solr/common/SolrInputField.java#L60
This issue can be solved by creating a copy of the collection in setField
method. In fact, we can move this section from addField() itself.
Let me know if this makes sense. I can help putting up a patch.
> Issue with Collections in field value while indexing a document.
>
>
> Key: SOLR-6815
> URL: https://issues.apache.org/jira/browse/SOLR-6815
> Project: Solr
> Issue Type: Bug
> Components: clients - java
>Affects Versions: 4.9
>Reporter: Kiran Kumar Dontam
>Priority: Minor
> Attachments: SolrIndexingTest.java
>
>
> Issue with {{SolrInputDocument.addField()}} method.
> If this method is called for the first time for a field, it will call
> {{setField}} method, which calls {{SolrInputField.setValue}}.
> Assume that the value is a Collection in this flow. The value's reference is
> added to the field in the doc. If we add another value to the same field
> (using {{addField}}), it will be added to the original collection.
> This is incorrect because we are modifying user's original collection.
> This will break in the following cases:
> 1. If the original collection is unmodifiable. This will throw
> {{UnsupportedOperationException}} while adding 2nd value.
> 2. If the user wants to add the same value (Collection) to different fields,
> those fields may get corrupted. Adding more values to one fields will add
> them to other fields as well. (This is how I found the issue).
> One solution:
> In {{SolrInputField.setValue}} we can always create a new Collection
> (ArrayList) if the incoming value is a Collection.
--
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-7177) ConcurrentUpdateSolrClient should log connection information on http failures
[
https://issues.apache.org/jira/browse/SOLR-7177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsee Yarlagadda updated SOLR-7177:
Affects Version/s: 5.0
> ConcurrentUpdateSolrClient should log connection information on http failures
> --
>
> Key: SOLR-7177
> URL: https://issues.apache.org/jira/browse/SOLR-7177
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.10.3, 5.0
>Reporter: Vamsee Yarlagadda
>Priority: Minor
> Attachments: SOLR-7177.patch
>
>
> I notice when there is an http connection failure, we simply log the error
> but not the connection information. It would be good to log this info to make
> debugging easier.
> e.g:
> 1.
> {code}
> 2015-02-27 08:56:51,503 ERROR org.apache.solr.update.StreamingSolrServers:
> error
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:196)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at
> org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:166)
> at
> org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:90)
> at
> org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:281)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:92)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:62)
> at
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
> at
> org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
> at
> org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
> at
> org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
> at
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
> at
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
> at
> org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner.run(ConcurrentUpdateSolrServer.java:235)
> {code}
>
> 2.
> {code}
> 2015-02-27 10:26:12,363 ERROR org.apache.solr.update.StreamingSolrServers:
> error
> org.apache.http.NoHttpResponseException: The target server failed to respond
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:95)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:62)
> at
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
> at
> org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
> at
> org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
> at
> org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
> at
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
> at
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
> at
> org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner.run(ConcurrentUpdateSolrServer.java:235)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> As
[jira] [Updated] (SOLR-7177) ConcurrentUpdateSolrClient should log connection information on http failures
[
https://issues.apache.org/jira/browse/SOLR-7177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsee Yarlagadda updated SOLR-7177:
Attachment: SOLR-7177.patch
Here is the first revision of the patch.
I tried to preserve the original behavior by catching the exception, logging
the required details, and then throwing the same exception again.
> ConcurrentUpdateSolrClient should log connection information on http failures
> --
>
> Key: SOLR-7177
> URL: https://issues.apache.org/jira/browse/SOLR-7177
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.10.3
>Reporter: Vamsee Yarlagadda
>Priority: Minor
> Attachments: SOLR-7177.patch
>
>
> I notice when there is an http connection failure, we simply log the error
> but not the connection information. It would be good to log this info to make
> debugging easier.
> e.g:
> 1.
> {code}
> 2015-02-27 08:56:51,503 ERROR org.apache.solr.update.StreamingSolrServers:
> error
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:196)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at
> org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:166)
> at
> org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:90)
> at
> org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:281)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:92)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:62)
> at
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
> at
> org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
> at
> org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
> at
> org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
> at
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
> at
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
> at
> org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner.run(ConcurrentUpdateSolrServer.java:235)
> {code}
>
> 2.
> {code}
> 2015-02-27 10:26:12,363 ERROR org.apache.solr.update.StreamingSolrServers:
> error
> org.apache.http.NoHttpResponseException: The target server failed to respond
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:95)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:62)
> at
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
> at
> org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
> at
> org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
> at
> org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
> at
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
> at
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
> at
> org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner.run(ConcurrentUpdateSolrServer.java:235)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker
[jira] [Commented] (SOLR-7177) ConcurrentUpdateSolrClient should log connection information on http failures
[
https://issues.apache.org/jira/browse/SOLR-7177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14341311#comment-14341311
]
Vamsee Yarlagadda commented on SOLR-7177:
-
It might be costly to always log this connection info before every request.
https://github.com/apache/lucene-solr/blob/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/impl/ConcurrentUpdateSolrClient.java#L234
I will try to make sure we only log if there is an exception from the above
line.
> ConcurrentUpdateSolrClient should log connection information on http failures
> --
>
> Key: SOLR-7177
> URL: https://issues.apache.org/jira/browse/SOLR-7177
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.10.3
>Reporter: Vamsee Yarlagadda
>Priority: Minor
>
> I notice when there is an http connection failure, we simply log the error
> but not the connection information. It would be good to log this info to make
> debugging easier.
> e.g:
> 1.
> {code}
> 2015-02-27 08:56:51,503 ERROR org.apache.solr.update.StreamingSolrServers:
> error
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:196)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at
> org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:166)
> at
> org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:90)
> at
> org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:281)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:92)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:62)
> at
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
> at
> org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
> at
> org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
> at
> org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
> at
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
> at
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
> at
> org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner.run(ConcurrentUpdateSolrServer.java:235)
> {code}
>
> 2.
> {code}
> 2015-02-27 10:26:12,363 ERROR org.apache.solr.update.StreamingSolrServers:
> error
> org.apache.http.NoHttpResponseException: The target server failed to respond
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:95)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:62)
> at
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
> at
> org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
> at
> org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
> at
> org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
> at
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
> at
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
> at
> org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner.run(C
[jira] [Created] (SOLR-7177) ConcurrentUpdateSolrClient should log connection information on http failures
Vamsee Yarlagadda created SOLR-7177:
---
Summary: ConcurrentUpdateSolrClient should log connection
information on http failures
Key: SOLR-7177
URL: https://issues.apache.org/jira/browse/SOLR-7177
Project: Solr
Issue Type: Improvement
Affects Versions: 4.10.3
Reporter: Vamsee Yarlagadda
Priority: Minor
I notice when there is an http connection failure, we simply log the error but
not the connection information. It would be good to log this info to make
debugging easier.
e.g:
1.
{code}
2015-02-27 08:56:51,503 ERROR org.apache.solr.update.StreamingSolrServers: error
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at
org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:166)
at
org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:90)
at
org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:281)
at
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:92)
at
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:62)
at
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
at
org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
at
org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
at
org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
at
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
at
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
at
org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
at
org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner.run(ConcurrentUpdateSolrServer.java:235)
{code}
2.
{code}
2015-02-27 10:26:12,363 ERROR org.apache.solr.update.StreamingSolrServers: error
org.apache.http.NoHttpResponseException: The target server failed to respond
at
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:95)
at
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:62)
at
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
at
org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
at
org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
at
org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
at
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
at
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
at
org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
at
org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner.run(ConcurrentUpdateSolrServer.java:235)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}
As we can notice, we can see the exception but we don't have any information
around which server is the end point.
--
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-7124) Add "delconfig" command to zkcli
[ https://issues.apache.org/jira/browse/SOLR-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14341217#comment-14341217 ] Vamsee Yarlagadda commented on SOLR-7124: - bq. It would not be required on upconfig, because upconfig will not delete any files from an existing config, it will only add or overwrite. You are right. I am not aware of this. I was under the impression that it will throw an error if config already exists. However as you pointed out, it will not delete any files as part of this operation. But there is a chance that we can end up with a mix of both old and new configs. Let's say if the old config has a file foo.txt and the new config is missing it then the updated configs in ZK contains all the files from new config + foo.txt. I am not sure whether this is a separate bug we need to fix. bq. A slightly different check (making sure the config actually exists) might need to be performed for linkconfig. Makes sense. > Add "delconfig" command to zkcli > > > Key: SOLR-7124 > URL: https://issues.apache.org/jira/browse/SOLR-7124 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Affects Versions: 5.0 >Reporter: Shawn Heisey >Priority: Minor > Fix For: 5.1 > > > As far as I know, there is no functionality included with Solr that can > delete a SolrCloud config in zookeeper. > A "delconfig" command should be added to ZkCli and the zkcli script that can > accomplish this. It should refuse to delete a config that is in use by any > current collection. -- 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-7100) SpellCheckComponent should throw error if queryAnalyzerFieldType provided doesn't exist
[ https://issues.apache.org/jira/browse/SOLR-7100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14339775#comment-14339775 ] Vamsee Yarlagadda commented on SOLR-7100: - I am trying to understand why we ended up defaulting to "WhitespaceTokenizer" in the first place. I don't see any documentation that refers to this. bq. This should really be an error. Makes sense. We should also keep in mind that with this change we might be breaking compatibility with existing solrconfig.xml. If you think this is not a concern, then i am good with the proposal. > SpellCheckComponent should throw error if queryAnalyzerFieldType provided > doesn't exist > --- > > Key: SOLR-7100 > URL: https://issues.apache.org/jira/browse/SOLR-7100 > Project: Solr > Issue Type: Bug > Components: spellchecker >Affects Versions: 4.10.2 >Reporter: David Smiley >Priority: Minor > > If you typo or otherwise mess up the queryAnalyzerFieldType setting in > solrconfig.xml for the spellcheck component, you will not get an error. > Instead, the code falls back to the default (WhitespaceTokenizer). This > should really be an error. -- 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-7146) MiniSolrCloudCluster based tests can fail with ZooKeeperException NoNode for /live_nodes
[
https://issues.apache.org/jira/browse/SOLR-7146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsee Yarlagadda updated SOLR-7146:
Attachment: SOLR-7146v2.patch
Added check to see if /solr/live_nodes exist before getting the list of live
solr servers.
> MiniSolrCloudCluster based tests can fail with ZooKeeperException NoNode for
> /live_nodes
>
>
> Key: SOLR-7146
> URL: https://issues.apache.org/jira/browse/SOLR-7146
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud, Tests
>Reporter: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: Trunk, 5.1
>
> Attachments: SOLR-7146.patch, SOLR-7146v2.patch
>
>
> MiniSolrCloudCluster based tests can fail with the following exception:
> {code}
> org.apache.solr.common.cloud.ZooKeeperException:
> at
> __randomizedtesting.SeedInfo.seed([3F3D838A8ADC9385:F153ADFBF163EC6D]:0)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:463)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:763)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:752)
> at
> org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:193)
> at
> org.apache.solr.handler.component.TestTwoPhaseDistributedQuery.testNoExtraFieldsRequestedFromShardsInPhaseOne(TestTwoPhaseDistributedQuery.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
> at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
[jira] [Commented] (SOLR-7146) MiniSolrCloudCluster based tests can fail with ZooKeeperException NoNode for /live_nodes
[
https://issues.apache.org/jira/browse/SOLR-7146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14339726#comment-14339726
]
Vamsee Yarlagadda commented on SOLR-7146:
-
oops. I didn't handle the case to check if live_nodes exists in the first
place. Let me update the patch.
> MiniSolrCloudCluster based tests can fail with ZooKeeperException NoNode for
> /live_nodes
>
>
> Key: SOLR-7146
> URL: https://issues.apache.org/jira/browse/SOLR-7146
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud, Tests
>Reporter: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: Trunk, 5.1
>
> Attachments: SOLR-7146.patch
>
>
> MiniSolrCloudCluster based tests can fail with the following exception:
> {code}
> org.apache.solr.common.cloud.ZooKeeperException:
> at
> __randomizedtesting.SeedInfo.seed([3F3D838A8ADC9385:F153ADFBF163EC6D]:0)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:463)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:763)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:752)
> at
> org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:193)
> at
> org.apache.solr.handler.component.TestTwoPhaseDistributedQuery.testNoExtraFieldsRequestedFromShardsInPhaseOne(TestTwoPhaseDistributedQuery.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
> at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAd
[jira] [Updated] (SOLR-7146) MiniSolrCloudCluster based tests can fail with ZooKeeperException NoNode for /live_nodes
[
https://issues.apache.org/jira/browse/SOLR-7146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsee Yarlagadda updated SOLR-7146:
Attachment: SOLR-7146.patch
Here is the first revision of the patch. I added logic to wait for maximum of
10 seconds before giving up.
> MiniSolrCloudCluster based tests can fail with ZooKeeperException NoNode for
> /live_nodes
>
>
> Key: SOLR-7146
> URL: https://issues.apache.org/jira/browse/SOLR-7146
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud, Tests
>Reporter: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: Trunk, 5.1
>
> Attachments: SOLR-7146.patch
>
>
> MiniSolrCloudCluster based tests can fail with the following exception:
> {code}
> org.apache.solr.common.cloud.ZooKeeperException:
> at
> __randomizedtesting.SeedInfo.seed([3F3D838A8ADC9385:F153ADFBF163EC6D]:0)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:463)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:763)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:752)
> at
> org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:193)
> at
> org.apache.solr.handler.component.TestTwoPhaseDistributedQuery.testNoExtraFieldsRequestedFromShardsInPhaseOne(TestTwoPhaseDistributedQuery.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
> at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Statement
[jira] [Commented] (SOLR-7124) Add "delconfig" command to zkcli
[ https://issues.apache.org/jira/browse/SOLR-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14339702#comment-14339702 ] Vamsee Yarlagadda commented on SOLR-7124: - Looks like "zkcli .. -cmd clear " can delete the znodes recursively. So a user can call this for /solr/configs/ to delete a config. https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/cloud/ZkCLI.java#L236 I agree the users didn't have the direct option to delete the config (similar to upconfig, downconfig). It would be good to have one. bq. It should refuse to delete a config that is in use by any current collection. We should also keep in mind that a user can replace existing configs for a collection and call collection RELOAD. So adding this check can prevent one from easily replacing configs. Thoughts? > Add "delconfig" command to zkcli > > > Key: SOLR-7124 > URL: https://issues.apache.org/jira/browse/SOLR-7124 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Affects Versions: 5.0 >Reporter: Shawn Heisey >Priority: Minor > Fix For: 5.1 > > > As far as I know, there is no functionality included with Solr that can > delete a SolrCloud config in zookeeper. > A "delconfig" command should be added to ZkCli and the zkcli script that can > accomplish this. It should refuse to delete a config that is in use by any > current collection. -- 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-7146) MiniSolrCloudCluster based tests can fail with ZooKeeperException NoNode for /live_nodes
[
https://issues.apache.org/jira/browse/SOLR-7146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14339675#comment-14339675
]
Vamsee Yarlagadda commented on SOLR-7146:
-
May be we can add a check at this line to wait for # of znodes under
/solr/live_nodes to match up the number of servers being started?
https://github.com/apache/lucene-solr/blob/trunk/solr/test-framework/src/java/org/apache/solr/cloud/MiniSolrCloudCluster.java#L116
Of course, we need to have a timeout though rather than waiting indefinitely. I
can work on it if the above approach sounds good?
> MiniSolrCloudCluster based tests can fail with ZooKeeperException NoNode for
> /live_nodes
>
>
> Key: SOLR-7146
> URL: https://issues.apache.org/jira/browse/SOLR-7146
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud, Tests
>Reporter: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: Trunk, 5.1
>
>
> MiniSolrCloudCluster based tests can fail with the following exception:
> {code}
> org.apache.solr.common.cloud.ZooKeeperException:
> at
> __randomizedtesting.SeedInfo.seed([3F3D838A8ADC9385:F153ADFBF163EC6D]:0)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:463)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:763)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:752)
> at
> org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:193)
> at
> org.apache.solr.handler.component.TestTwoPhaseDistributedQuery.testNoExtraFieldsRequestedFromShardsInPhaseOne(TestTwoPhaseDistributedQuery.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
> at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoSha
[jira] [Updated] (SOLR-7159) Add httpclient connection stats to JMX report
[
https://issues.apache.org/jira/browse/SOLR-7159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsee Yarlagadda updated SOLR-7159:
Attachment: SOLR-7159v4.patch
Updated the patch with recommended code style.
[~markrmil...@gmail.com] Let me know if they if there is still something
specifically wrong with the formatting.
> Add httpclient connection stats to JMX report
> -
>
> Key: SOLR-7159
> URL: https://issues.apache.org/jira/browse/SOLR-7159
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.10.3
>Reporter: Vamsee Yarlagadda
>Priority: Minor
> Attachments: SOLR-7159.patch, SOLR-7159v2.patch, SOLR-7159v3.patch,
> SOLR-7159v4.patch, Screen Shot 2015-02-25 at 2.05.34 PM.png, Screen Shot
> 2015-02-25 at 7.17.05 PM.png, Screen Shot 2015-02-25 at 7.18.17 PM.png,
> Screen Shot 2015-02-25 at 7.20.52 PM.png, Screen Shot 2015-02-25 at 7.21.09
> PM.png, jmx-layout.png
>
>
> Currently, we are logging the stats of httpclient as part of debug level.
> bq. 2015-01-20 13:47:48,640 DEBUG
> org.apache.http.impl.conn.PoolingClientConnectionManager: Connection request:
> [route: {}->http://plh04.wil.csc.local:8983][total kept alive: 254; route
> allocated: 100 of 100; total allocated: 462 of 1]
> Instead, it would be good to expose these metrics via JMX for easy checking.
--
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-7159) Add httpclient connection stats to JMX report
[
https://issues.apache.org/jira/browse/SOLR-7159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsee Yarlagadda updated SOLR-7159:
Attachment: Screen Shot 2015-02-25 at 7.21.09 PM.png
Screen Shot 2015-02-25 at 7.20.52 PM.png
Screen Shot 2015-02-25 at 7.18.17 PM.png
Screen Shot 2015-02-25 at 7.17.05 PM.png
SOLR-7159v3.patch
Updated the patch to display:
* httpclient stats as individual attributes instead of printing it as one long
string.
* query, update stats are moved from CORE to resective QUERYHANDLER,
UPDATEHANDLER category.
Screen shots attached to show how the JMX and Solr admin UI looks like with
these stats.
> Add httpclient connection stats to JMX report
> -
>
> Key: SOLR-7159
> URL: https://issues.apache.org/jira/browse/SOLR-7159
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.10.3
>Reporter: Vamsee Yarlagadda
>Priority: Minor
> Attachments: SOLR-7159.patch, SOLR-7159v2.patch, SOLR-7159v3.patch,
> Screen Shot 2015-02-25 at 2.05.34 PM.png, Screen Shot 2015-02-25 at 7.17.05
> PM.png, Screen Shot 2015-02-25 at 7.18.17 PM.png, Screen Shot 2015-02-25 at
> 7.20.52 PM.png, Screen Shot 2015-02-25 at 7.21.09 PM.png, jmx-layout.png
>
>
> Currently, we are logging the stats of httpclient as part of debug level.
> bq. 2015-01-20 13:47:48,640 DEBUG
> org.apache.http.impl.conn.PoolingClientConnectionManager: Connection request:
> [route: {}->http://plh04.wil.csc.local:8983][total kept alive: 254; route
> allocated: 100 of 100; total allocated: 462 of 1]
> Instead, it would be good to expose these metrics via JMX for easy checking.
--
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-7159) Add httpclient connection stats to JMX report
[
https://issues.apache.org/jira/browse/SOLR-7159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsee Yarlagadda updated SOLR-7159:
Attachment: (was: Screen Shot 2015-02-25 at 2.05.45 PM.png)
> Add httpclient connection stats to JMX report
> -
>
> Key: SOLR-7159
> URL: https://issues.apache.org/jira/browse/SOLR-7159
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.10.3
>Reporter: Vamsee Yarlagadda
>Priority: Minor
> Attachments: SOLR-7159.patch, SOLR-7159v2.patch, SOLR-7159v3.patch,
> Screen Shot 2015-02-25 at 2.05.34 PM.png, Screen Shot 2015-02-25 at 7.17.05
> PM.png, Screen Shot 2015-02-25 at 7.18.17 PM.png, Screen Shot 2015-02-25 at
> 7.20.52 PM.png, Screen Shot 2015-02-25 at 7.21.09 PM.png, jmx-layout.png
>
>
> Currently, we are logging the stats of httpclient as part of debug level.
> bq. 2015-01-20 13:47:48,640 DEBUG
> org.apache.http.impl.conn.PoolingClientConnectionManager: Connection request:
> [route: {}->http://plh04.wil.csc.local:8983][total kept alive: 254; route
> allocated: 100 of 100; total allocated: 462 of 1]
> Instead, it would be good to expose these metrics via JMX for easy checking.
--
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-7159) Add httpclient connection stats to JMX report
[
https://issues.apache.org/jira/browse/SOLR-7159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsee Yarlagadda updated SOLR-7159:
Attachment: (was: Screen Shot 2015-02-25 at 3.37.06 AM.png)
> Add httpclient connection stats to JMX report
> -
>
> Key: SOLR-7159
> URL: https://issues.apache.org/jira/browse/SOLR-7159
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.10.3
>Reporter: Vamsee Yarlagadda
>Priority: Minor
> Attachments: SOLR-7159.patch, SOLR-7159v2.patch, Screen Shot
> 2015-02-25 at 2.05.34 PM.png, Screen Shot 2015-02-25 at 2.05.45 PM.png
>
>
> Currently, we are logging the stats of httpclient as part of debug level.
> bq. 2015-01-20 13:47:48,640 DEBUG
> org.apache.http.impl.conn.PoolingClientConnectionManager: Connection request:
> [route: {}->http://plh04.wil.csc.local:8983][total kept alive: 254; route
> allocated: 100 of 100; total allocated: 462 of 1]
> Instead, it would be good to expose these metrics via JMX for easy checking.
--
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-7159) Add httpclient connection stats to JMX report
[
https://issues.apache.org/jira/browse/SOLR-7159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsee Yarlagadda updated SOLR-7159:
Attachment: SOLR-7159v2.patch
Screen Shot 2015-02-25 at 2.05.45 PM.png
Screen Shot 2015-02-25 at 2.05.34 PM.png
[~elyograg] Thanks for the feedback.
* Updated my patch to refer to the trunk.
* The reason why i ended up putting under core is because every core instance
has its own update and query httpclients. So i thought having it as part of
core stats makes more sense. I am open for more feedback here.
* I followed this wiki (https://wiki.apache.org/solr/SolrJmx) to see the JMX
stats (latest screenshots attached)
* Looks like even Solr admin web ui uses the MBeans to populate the stats. That
being said, the existing patch also shows stats on the solr web ui :)
(screenshot attached)
> Add httpclient connection stats to JMX report
> -
>
> Key: SOLR-7159
> URL: https://issues.apache.org/jira/browse/SOLR-7159
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.10.3
>Reporter: Vamsee Yarlagadda
>Priority: Minor
> Attachments: SOLR-7159.patch, SOLR-7159v2.patch, Screen Shot
> 2015-02-25 at 2.05.34 PM.png, Screen Shot 2015-02-25 at 2.05.45 PM.png
>
>
> Currently, we are logging the stats of httpclient as part of debug level.
> bq. 2015-01-20 13:47:48,640 DEBUG
> org.apache.http.impl.conn.PoolingClientConnectionManager: Connection request:
> [route: {}->http://plh04.wil.csc.local:8983][total kept alive: 254; route
> allocated: 100 of 100; total allocated: 462 of 1]
> Instead, it would be good to expose these metrics via JMX for easy checking.
--
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-7159) Add httpclient connection stats to JMX report
[
https://issues.apache.org/jira/browse/SOLR-7159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsee Yarlagadda updated SOLR-7159:
Attachment: Screen Shot 2015-02-25 at 3.37.06 AM.png
SOLR-7159.patch
Here is the first draft of the patch.
As per the latest 4.10 release, we have two separate http connection pools -
UpdateShardHandler (handles all the updates) and
HttpShardHandler/HttpShardHandlerFactory (handles all queries). And these two
classes are created for every core setup. So i ended up adding the logic to the
existing MBean of every core to display the httpclient connection stats.
(Screenshot attached).
Kindly let me know with any suggestions or comments. I will refine the patch
accordingly.
> Add httpclient connection stats to JMX report
> -
>
> Key: SOLR-7159
> URL: https://issues.apache.org/jira/browse/SOLR-7159
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.10.3
>Reporter: Vamsee Yarlagadda
>Priority: Minor
> Attachments: SOLR-7159.patch, Screen Shot 2015-02-25 at 3.37.06 AM.png
>
>
> Currently, we are logging the stats of httpclient as part of debug level.
> bq. 2015-01-20 13:47:48,640 DEBUG
> org.apache.http.impl.conn.PoolingClientConnectionManager: Connection request:
> [route: {}->http://plh04.wil.csc.local:8983][total kept alive: 254; route
> allocated: 100 of 100; total allocated: 462 of 1]
> Instead, it would be good to expose these metrics via JMX for easy checking.
--
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-7159) Add httpclient connection stats to JMX report
Vamsee Yarlagadda created SOLR-7159:
---
Summary: Add httpclient connection stats to JMX report
Key: SOLR-7159
URL: https://issues.apache.org/jira/browse/SOLR-7159
Project: Solr
Issue Type: Improvement
Affects Versions: 4.10.3
Reporter: Vamsee Yarlagadda
Priority: Minor
Currently, we are logging the stats of httpclient as part of debug level.
bq. 2015-01-20 13:47:48,640 DEBUG
org.apache.http.impl.conn.PoolingClientConnectionManager: Connection request:
[route: {}->http://plh04.wil.csc.local:8983][total kept alive: 254; route
allocated: 100 of 100; total allocated: 462 of 1]
Instead, it would be good to expose these metrics via JMX for easy checking.
--
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-7113) Solr indexing throws errors around closing transaction log
Vamsee Yarlagadda created SOLR-7113:
---
Summary: Solr indexing throws errors around closing transaction log
Key: SOLR-7113
URL: https://issues.apache.org/jira/browse/SOLR-7113
Project: Solr
Issue Type: Bug
Reporter: Vamsee Yarlagadda
I notice this issue while trying to do some heavy indexing into Solr. (700K
docs per minute)
Solr log errors
{code}
15:42:47
ERROR
HdfsTransactionLog
Exception closing tlog.
java.io.IOException: Filesystem closed
at org.apache.hadoop.hdfs.DFSClient.checkOpen(DFSClient.java:765)
at
org.apache.hadoop.hdfs.DFSOutputStream.flushOrSync(DFSOutputStream.java:1898)
at
org.apache.hadoop.hdfs.DFSOutputStream.hflush(DFSOutputStream.java:1859)
at
org.apache.hadoop.fs.FSDataOutputStream.hflush(FSDataOutputStream.java:130)
at
org.apache.solr.update.HdfsTransactionLog.close(HdfsTransactionLog.java:303)
at org.apache.solr.update.TransactionLog.decref(TransactionLog.java:504)
at org.apache.solr.update.UpdateLog.addOldLog(UpdateLog.java:335)
at org.apache.solr.update.UpdateLog.postCommit(UpdateLog.java:628)
at
org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:600)
at org.apache.solr.update.CommitTracker.run(CommitTracker.java:216)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
15:42:47
ERROR
CommitTracker
auto commit error...:org.apache.solr.common.SolrException: java.io.IOException:
Filesystem closed
auto commit error...:org.apache.solr.common.SolrException: java.io.IOException:
Filesystem closed
{code}
--
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-6962) bin/solr stop -a should complain about missing parameter
[ https://issues.apache.org/jira/browse/SOLR-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsee Yarlagadda updated SOLR-6962: Attachment: SOLR-6962v2.patch [~anshumg] Good catch. Thanks for highlighting this. Updated the patch with fix for both Unix and Windows. > bin/solr stop -a should complain about missing parameter > > > Key: SOLR-6962 > URL: https://issues.apache.org/jira/browse/SOLR-6962 > Project: Solr > Issue Type: Improvement > Components: scripts and tools >Affects Versions: 5.0 >Reporter: Alexandre Rafalovitch >Priority: Minor > Attachments: SOLR-6962.patch, SOLR-6962v2.patch > > > *bin/solr* has a *-a* option that expects a second parameter. If one is not > provided, it hangs. It should complain and exit just like *-e* option does. > The most common time I hit this is when I try to do *bin/solr stop \-all* and > instead just type *bin/solr stop \-a* as I am more used to give full name > options with double-dash prefix (Unix conventions, I guess). -- 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-6619) Improperly handle the InteruptedException in ConccurentUpdateSolrServer
[
https://issues.apache.org/jira/browse/SOLR-6619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsee Yarlagadda updated SOLR-6619:
Attachment: SOLR-6619.patch
Here is the patch to write "" as part of finally block.
> Improperly handle the InteruptedException in ConccurentUpdateSolrServer
>
>
> Key: SOLR-6619
> URL: https://issues.apache.org/jira/browse/SOLR-6619
> Project: Solr
> Issue Type: Bug
>Reporter: Junhao Li
>Priority: Minor
> Attachments: SOLR-6619.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> ConccurentUpdateSolrServer
> """
> if (isXml) {
> out.write("".getBytes(StandardCharsets.UTF_8));
> }
> """
> should be moved to the finally statement.
> If InteruptedException is raised, it will send the wrong xml document without
> "" to the server.
--
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-6962) bin/solr stop -a should complain about missing parameter
[ https://issues.apache.org/jira/browse/SOLR-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsee Yarlagadda updated SOLR-6962: Attachment: SOLR-6962.patch Here is the patch to raise an error if -a, -k options are supplied without passing values. > bin/solr stop -a should complain about missing parameter > > > Key: SOLR-6962 > URL: https://issues.apache.org/jira/browse/SOLR-6962 > Project: Solr > Issue Type: Improvement > Components: scripts and tools >Affects Versions: 5.0 >Reporter: Alexandre Rafalovitch >Priority: Minor > Attachments: SOLR-6962.patch > > > *bin/solr* has a *-a* option that expects a second parameter. If one is not > provided, it hangs. It should complain and exit just like *-e* option does. > The most common time I hit this is when I try to do *bin/solr stop \-all* and > instead just type *bin/solr stop \-a* as I am more used to give full name > options with double-dash prefix (Unix conventions, I guess). -- 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-3203) SolrCloud should demand that the schema has the _version_ field
[ https://issues.apache.org/jira/browse/SOLR-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14112078#comment-14112078 ] Vamsee Yarlagadda commented on SOLR-3203: - This issue has been resolved as part of https://issues.apache.org/jira/browse/SOLR-3745. That being said, we can resolve this Jira. > SolrCloud should demand that the schema has the _version_ field > > > Key: SOLR-3203 > URL: https://issues.apache.org/jira/browse/SOLR-3203 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Lance Norskog >Priority: Minor > Fix For: 4.9, 5.0 > > > SolrCloud does not function correctly without the _version_ field. It should > fail at startup if this is not in the schema. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6440) Core status should throw an error if core doesn't exist
[
https://issues.apache.org/jira/browse/SOLR-6440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsee Yarlagadda updated SOLR-6440:
Attachment: SOLR-6440.patch
Here is the first revision of the patch.
Note: This patch will still honor the
https://issues.apache.org/jira/browse/SOLR-3634 for reporting back info about
initialization failures
> Core status should throw an error if core doesn't exist
> ---
>
> Key: SOLR-6440
> URL: https://issues.apache.org/jira/browse/SOLR-6440
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other
>Affects Versions: 5.0
>Reporter: Vamsee Yarlagadda
>Priority: Minor
> Attachments: SOLR-6440.patch
>
>
> Current version of Core STATUS returns an empty response if requested core
> doesn't exist.
> e.q:
> http://localhost:8900/solr/admin/cores?action=STATUS&core=abc
> {code}
>
>
> 0
> 1
>
>
>
>
>
> {code}
> Instead, it would be good to return an error message stating that the core
> doesn't exist.
> e.g
> {code}
>
>
> 400
> 27
>
>
>
> Core [abc] does not exist
> 400
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6440) Core status should throw an error if core doesn't exist
Vamsee Yarlagadda created SOLR-6440:
---
Summary: Core status should throw an error if core doesn't exist
Key: SOLR-6440
URL: https://issues.apache.org/jira/browse/SOLR-6440
Project: Solr
Issue Type: Bug
Components: SearchComponents - other
Affects Versions: 5.0
Reporter: Vamsee Yarlagadda
Priority: Minor
Current version of Core STATUS returns an empty response if requested core
doesn't exist.
e.q:
http://localhost:8900/solr/admin/cores?action=STATUS&core=abc
{code}
0
1
{code}
Instead, it would be good to return an error message stating that the core
doesn't exist.
e.g
{code}
400
27
Core [abc] does not exist
400
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6314) Multi-threaded facet counts differ when SolrCloud has >1 shard
[
https://issues.apache.org/jira/browse/SOLR-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14103564#comment-14103564
]
Vamsee Yarlagadda commented on SOLR-6314:
-
The patch looks good to me.
Thanks [~erickerickson].
> Multi-threaded facet counts differ when SolrCloud has >1 shard
> --
>
> Key: SOLR-6314
> URL: https://issues.apache.org/jira/browse/SOLR-6314
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other, SolrCloud
>Affects Versions: 5.0
>Reporter: Vamsee Yarlagadda
>Assignee: Erick Erickson
> Fix For: 5.0, 4.10
>
> Attachments: SOLR-6314.patch, SOLR-6314.patch, SOLR-6314.patch
>
>
> I am trying to work with multi-threaded faceting on SolrCloud and in the
> process i was hit by some issues.
> I am currently running the below upstream test on different SolrCloud
> configurations and i am getting a different result set per configuration.
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/test/org/apache/solr/request/TestFaceting.java#L654
> Setup:
> - *Indexed 50 docs into SolrCloud.*
> - *If the SolrCloud has only 1 shard, the facet field query has the below
> output (which matches with the expected upstream test output - # facet fields
> ~ 50).*
> {code}
> $ curl
> "http://localhost:8983/solr/collection1/select?facet=true&fl=id&indent=true&q=id%3A*&facet.limit=-1&facet.threads=1000&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&rows=1&wt=xml";
>
>
>
> 0
> 21
>
> true
> id
> true
> id:*
> -1
> 1000
>
> f0_ws
> f0_ws
> f0_ws
> f0_ws
> f0_ws
> f1_ws
> f1_ws
> f1_ws
> f1_ws
> f1_ws
> f2_ws
> f2_ws
> f2_ws
> f2_ws
> f2_ws
> f3_ws
> f3_ws
> f3_ws
> f3_ws
> f3_ws
> f4_ws
> f4_ws
> f4_ws
> f4_ws
> f4_ws
> f5_ws
> f5_ws
> f5_ws
> f5_ws
> f5_ws
> f6_ws
> f6_ws
> f6_ws
> f6_ws
> f6_ws
> f7_ws
> f7_ws
> f7_ws
> f7_ws
> f7_ws
> f8_ws
> f8_ws
> f8_ws
> f8_ws
> f8_ws
> f9_ws
> f9_ws
> f9_ws
> f9_ws
> f9_ws
>
> xml
> 1
>
>
>
>
> 0.0
>
>
>
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 42
> 8
>
>
> 42
> 8
>
>
> 42
> 8
>
>
> 42
> 8
>
>
> 42
> 8
>
>
> 43
> 7
>
>
> 43
> 7
>
>
> 43
> 7
>
>
> 43
> 7
>
>
> 43
> 7
>
>
> 44
> 6
>
>
> 44
> 6
>
>
> 44
> 6
>
>
> 44
> 6
>
>
> 44
> 6
>
>
> 45
> 5
>
>
> 45
> 5
>
>
> 45
> 5
>
>
> 45
> 5
>
>
> 45
> 5
>
>
>
[jira] [Created] (SOLR-6375) facet_ranges count for before,after,between differ if #shards>1
Vamsee Yarlagadda created SOLR-6375:
---
Summary: facet_ranges count for before,after,between differ if
#shards>1
Key: SOLR-6375
URL: https://issues.apache.org/jira/browse/SOLR-6375
Project: Solr
Issue Type: Bug
Components: SearchComponents - other, SolrCloud
Affects Versions: 5.0
Reporter: Vamsee Yarlagadda
I am currently running the test
https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/test/org/apache/solr/request/SimpleFacetsTest.java#L859
on multi shard environment and i notice some discrepancies with facet_range
count for after,before, and between tags if the # of shards !=1
Running the
query(https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/test/org/apache/solr/request/SimpleFacetsTest.java#L874)
on #shards = 1 and matches the expected output
{code}
0
12
lower
all
true
true
*:*
1976-07-01T00:00:00.000Z
a_tdt
1976-07-16T00:00:00.000Z
+1DAY
xml
0
1
0
0
1
2
0
1
0
0
0
0
0
2
0
1
+1DAY
1976-07-01T00:00:00Z
1976-07-16T00:00:00Z
1
1
8
{code}
Running the same above on #shards > 1 (facet_range count for
after,before,between differs)
{code}
0
7
lower
all
true
true
*:*
1976-07-01T00:00:00.000Z
a_tdt
1976-07-16T00:00:00.000Z
+1DAY
xml
0
1
0
0
1
2
0
1
0
0
0
0
0
2
0
1
+1DAY
1976-07-01T00:00:00Z
1976-07-16T00:00:00Z
1
0
3
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4895) Throw an error when a rollback is attempted in SolrCloud mode.
[ https://issues.apache.org/jira/browse/SOLR-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsee Yarlagadda updated SOLR-4895: Attachment: SOLR-4895-v2.patch You are right, Mark. Moved the functionality to DirectUpdateHandler2 as processors can be skipped unless they implement UpdateRequestProcessorFactory.RunAlways > Throw an error when a rollback is attempted in SolrCloud mode. > -- > > Key: SOLR-4895 > URL: https://issues.apache.org/jira/browse/SOLR-4895 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.9, 5.0 > > Attachments: SOLR-4895-v2.patch, SOLR-4895.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4895) Throw an error when a rollback is attempted in SolrCloud mode.
[ https://issues.apache.org/jira/browse/SOLR-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsee Yarlagadda updated SOLR-4895: Attachment: SOLR-4895.patch Sorry for the late response [~markrmil...@gmail.com]. Here is the patch for throwing out an error if rollback is called. > Throw an error when a rollback is attempted in SolrCloud mode. > -- > > Key: SOLR-4895 > URL: https://issues.apache.org/jira/browse/SOLR-4895 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.9, 5.0 > > Attachments: SOLR-4895.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6314) Multi-threaded facet counts differ when SolrCloud has >1 shard
[
https://issues.apache.org/jira/browse/SOLR-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14088833#comment-14088833
]
Vamsee Yarlagadda commented on SOLR-6314:
-
Thanks [~erickerickson] for looking into this.
Yes, you are right. It makes perfect sense to return a count for every unique
facet request rather than repeating the facets over and over. It might be the
case that the facet result that's returned in the case of multi-shard (by going
through the aggregating code) is the right thing to do. Perhaps, we may want to
fix the behavior for single shard system and make changes to the unit tests to
reflect the same.
I can't think of any particular reason why the initial implementation of
multithreaded faceting created a test that will check for duplicate facet
counts. It might be a test bug too?
https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/test/org/apache/solr/request/TestFaceting.java#L654
Thoughts?
> Multi-threaded facet counts differ when SolrCloud has >1 shard
> --
>
> Key: SOLR-6314
> URL: https://issues.apache.org/jira/browse/SOLR-6314
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other, SolrCloud
>Affects Versions: 5.0
>Reporter: Vamsee Yarlagadda
>Assignee: Erick Erickson
>
> I am trying to work with multi-threaded faceting on SolrCloud and in the
> process i was hit by some issues.
> I am currently running the below upstream test on different SolrCloud
> configurations and i am getting a different result set per configuration.
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/test/org/apache/solr/request/TestFaceting.java#L654
> Setup:
> - *Indexed 50 docs into SolrCloud.*
> - *If the SolrCloud has only 1 shard, the facet field query has the below
> output (which matches with the expected upstream test output - # facet fields
> ~ 50).*
> {code}
> $ curl
> "http://localhost:8983/solr/collection1/select?facet=true&fl=id&indent=true&q=id%3A*&facet.limit=-1&facet.threads=1000&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&rows=1&wt=xml";
>
>
>
> 0
> 21
>
> true
> id
> true
> id:*
> -1
> 1000
>
> f0_ws
> f0_ws
> f0_ws
> f0_ws
> f0_ws
> f1_ws
> f1_ws
> f1_ws
> f1_ws
> f1_ws
> f2_ws
> f2_ws
> f2_ws
> f2_ws
> f2_ws
> f3_ws
> f3_ws
> f3_ws
> f3_ws
> f3_ws
> f4_ws
> f4_ws
> f4_ws
> f4_ws
> f4_ws
> f5_ws
> f5_ws
> f5_ws
> f5_ws
> f5_ws
> f6_ws
> f6_ws
> f6_ws
> f6_ws
> f6_ws
> f7_ws
> f7_ws
> f7_ws
> f7_ws
> f7_ws
> f8_ws
> f8_ws
> f8_ws
> f8_ws
> f8_ws
> f9_ws
> f9_ws
> f9_ws
> f9_ws
> f9_ws
>
> xml
> 1
>
>
>
>
> 0.0
>
>
>
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 42
> 8
>
>
> 42
> 8
>
>
> 42
>
[jira] [Commented] (SOLR-6314) Multi-threaded facet counts differ when SolrCloud has >1 shard
[
https://issues.apache.org/jira/browse/SOLR-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083726#comment-14083726
]
Vamsee Yarlagadda commented on SOLR-6314:
-
Thanks @Erick. I was able to replicate the issue on Solr trunk (5.0)
Let me know if there is anything I can do to help in the process.
> Multi-threaded facet counts differ when SolrCloud has >1 shard
> --
>
> Key: SOLR-6314
> URL: https://issues.apache.org/jira/browse/SOLR-6314
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other, SolrCloud
>Affects Versions: 5.0
>Reporter: Vamsee Yarlagadda
>Assignee: Erick Erickson
>
> I am trying to work with multi-threaded faceting on SolrCloud and in the
> process i was hit by some issues.
> I am currently running the below upstream test on different SolrCloud
> configurations and i am getting a different result set per configuration.
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/test/org/apache/solr/request/TestFaceting.java#L654
> Setup:
> - *Indexed 50 docs into SolrCloud.*
> - *If the SolrCloud has only 1 shard, the facet field query has the below
> output (which matches with the expected upstream test output - # facet fields
> ~ 50).*
> {code}
> $ curl
> "http://localhost:8983/solr/collection1/select?facet=true&fl=id&indent=true&q=id%3A*&facet.limit=-1&facet.threads=1000&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&rows=1&wt=xml";
>
>
>
> 0
> 21
>
> true
> id
> true
> id:*
> -1
> 1000
>
> f0_ws
> f0_ws
> f0_ws
> f0_ws
> f0_ws
> f1_ws
> f1_ws
> f1_ws
> f1_ws
> f1_ws
> f2_ws
> f2_ws
> f2_ws
> f2_ws
> f2_ws
> f3_ws
> f3_ws
> f3_ws
> f3_ws
> f3_ws
> f4_ws
> f4_ws
> f4_ws
> f4_ws
> f4_ws
> f5_ws
> f5_ws
> f5_ws
> f5_ws
> f5_ws
> f6_ws
> f6_ws
> f6_ws
> f6_ws
> f6_ws
> f7_ws
> f7_ws
> f7_ws
> f7_ws
> f7_ws
> f8_ws
> f8_ws
> f8_ws
> f8_ws
> f8_ws
> f9_ws
> f9_ws
> f9_ws
> f9_ws
> f9_ws
>
> xml
> 1
>
>
>
>
> 0.0
>
>
>
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 42
> 8
>
>
> 42
> 8
>
>
> 42
> 8
>
>
> 42
> 8
>
>
> 42
> 8
>
>
> 43
> 7
>
>
> 43
> 7
>
>
> 43
> 7
>
>
> 43
> 7
>
>
> 43
> 7
>
>
> 44
> 6
>
>
> 44
> 6
>
>
> 44
> 6
>
>
> 44
> 6
>
>
> 44
> 6
>
>
> 45
> 5
>
>
> 45
> 5
>
>
> 45
> 5
>
>
> 45
> 5
>
>
> 45
> 5
>
>
> 45
> 5
>
>
[jira] [Updated] (SOLR-6300) facet.mincount fails to work if SolrCloud distrib=true is set
[
https://issues.apache.org/jira/browse/SOLR-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsee Yarlagadda updated SOLR-6300:
Component/s: SearchComponents - other
> facet.mincount fails to work if SolrCloud distrib=true is set
> -
>
> Key: SOLR-6300
> URL: https://issues.apache.org/jira/browse/SOLR-6300
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other, SolrCloud
>Affects Versions: 5.0
>Reporter: Vamsee Yarlagadda
>
> I notice that using facet.mincount in SolrCloud mode with distrib=true fails
> to filter the facets based on the count. However, the same query with
> distrib=false works as expected.
> * Indexed some data as provided by the upstream test.
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/test/org/apache/solr/request/SimpleFacetsTest.java#L633
> * Test being run:
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/test/org/apache/solr/request/SimpleFacetsTest.java#L657
> * Running in SolrCloud mode with distrib=false (facet.mincount works as
> expected)
> {code}
> $ curl
> "http://search-testing-c5-3.ent.cloudera.com:8983/solr/simple_faceting_coll/select?facet.date.start=1976-07-01T00%3A00%3A00.000Z&facet=true&facet.mincount=1&q=*%3A*&facet.date=bday&facet.date.other=all&facet.date.gap=%2B1DAY&facet.date.end=1976-07-01T00%3A00%3A00.000Z%2B1MONTH&rows=0&indent=true&wt=xml&distrib=false";
>
>
>
> 0
> 3
>
> 1976-07-01T00:00:00.000Z
> true
> true
> 1
> *:*
> bday
> false
> +1DAY
> all
> xml
> 1976-07-01T00:00:00.000Z+1MONTH
> 0
>
>
>
>
>
>
>
>
>
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> +1DAY
> 1976-07-01T00:00:00Z
> 1976-08-01T00:00:00Z
> 2
> 0
> 6
>
>
>
>
>
> {code}
> * SolrCloud mode with distrib=true (facet.mincount fails to show effect)
> {code}
> $ curl
> "http://search-testing-c5-3.ent.cloudera.com:8983/solr/simple_faceting_coll/select?facet.date.start=1976-07-01T00%3A00%3A00.000Z&facet=true&facet.mincount=1&q=*%3A*&facet.date=bday&facet.date.other=all&facet.date.gap=%2B1DAY&facet.date.end=1976-07-01T00%3A00%3A00.000Z%2B1MONTH&rows=0&indent=true&wt=xml&distrib=true";
>
>
>
> 0
> 12
>
> 1976-07-01T00:00:00.000Z
> true
> true
> 1
> *:*
> bday
> true
> +1DAY
> all
> xml
> 1976-07-01T00:00:00.000Z+1MONTH
> 0
>
>
>
>
>
>
>
>
>
> 0
> 0
> 2
> 2
> 2
> 0
> 0
> 0
> 0
> 0
> 0
> 1
> 1
> 0
> 2
> 0
> 0
> 0
> 0
> 0
> 1
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 1
> 0
> +1DAY
> 1976-07-01T00:00:00Z
> 1976-08-01T00:00:00Z
> 2
> 1
> 11
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6299) Facet count on facet queries returns different results if #shards > 1
[
https://issues.apache.org/jira/browse/SOLR-6299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsee Yarlagadda resolved SOLR-6299.
-
Resolution: Not a Problem
Thanks for the insight, [~tomasflobbe].
Looks like we either have to do custom sharding to make sure all the docs which
relevant to the query are in the same shard to run a grouping request or just
have a single sharded system.
Resolving this Jira as not a bug.
> Facet count on facet queries returns different results if #shards > 1
> -
>
> Key: SOLR-6299
> URL: https://issues.apache.org/jira/browse/SOLR-6299
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 5.0
>Reporter: Vamsee Yarlagadda
> Labels: faceting
>
> I am trying to run some facet counts on facet queries and looks like i am
> getting different counts if i use >1 shards in the SolrCloud cluster.
> Here is the upstream unit test:
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/test/org/apache/solr/request/SimpleFacetsTest.java#L173
> Setup:
> * Ingested 5 solr docs.
> {code}
> {
> "responseHeader": {
> "status": 0,
> "QTime": 22,
> "params": {
> "indent": "true",
> "q": "*:*",
> "_": "1406346687337",
> "wt": "json"
> }
> },
> "response": {
> "numFound": 5,
> "start": 0,
> "maxScore": 1,
> "docs": [
> {
> "id": 2004,
> "range_facet_l": [
> 2004
> ],
> "hotel_s1": "b",
> "airport_s1": "ams",
> "duration_i1": 5,
> "_version_": 1474661321774465000,
> "timestamp": "2014-07-26T03:50:27.975Z",
> "multiDefault": [
> "muLti-Default"
> ],
> "intDefault": 42
> },
> {
> "id": 2000,
> "range_facet_l": [
> 2000
> ],
> "hotel_s1": "a",
> "airport_s1": "ams",
> "duration_i1": 5,
> "_version_": 1474661323604230100,
> "timestamp": "2014-07-26T03:50:29.734Z",
> "multiDefault": [
> "muLti-Default"
> ],
> "intDefault": 42
> },
> {
> "id": 2003,
> "range_facet_l": [
> 2003
> ],
> "hotel_s1": "b",
> "airport_s1": "ams",
> "duration_i1": 5,
> "_version_": 1474661326312702000,
> "timestamp": "2014-07-26T03:50:32.317Z",
> "multiDefault": [
> "muLti-Default"
> ],
> "intDefault": 42
> },
> {
> "id": 2001,
> "range_facet_l": [
> 2001
> ],
> "hotel_s1": "a",
> "airport_s1": "dus",
> "duration_i1": 10,
> "_version_": 1474661326389248000,
> "timestamp": "2014-07-26T03:50:32.375Z",
> "multiDefault": [
> "muLti-Default"
> ],
> "intDefault": 42
> },
> {
> "id": 2002,
> "range_facet_l": [
> 2002
> ],
> "hotel_s1": "b",
> "airport_s1": "ams",
> "duration_i1": 10,
> "_version_": 1474661326464745500,
> "timestamp": "2014-07-26T03:50:32.446Z",
> "multiDefault": [
> "muLti-Default"
> ],
> "intDefault": 42
> }
> ]
> }
> }
> {code}
> Here is the query being run:
> {code}
> Test code:
> assertQ(
> req(
> "q", "*:*",
> "fq", "id:[2000 TO 2004]",
> "group", "true",
> "group.facet", "true",
> "group.field", "hotel_s1",
> "facet", "true",
> "facet.limit", facetLimit,
> "facet.query", "airport_s1:ams"
> ),
> "//lst[@name='facet_queries']/int[@name='airport_s1:ams'][.='2']"
> );
> $ curl
> "http://localhost:8983/solr/collection1/select?facet=true&facet.query=airport_s1%3Aams&q=*%3A*&facet.limit=-100&group.field=hotel_s1&group=true&group.facet=true&fq=id%3A%5B2000+TO+2004%5D&indent=true&wt=xml";
>
> {code}
> Now, if i issue a query statement - On *1* shard system (Works as expected)
> {code}
> $ curl
> "http://localhost:8983/solr/collection1/select?facet=true&facet.query=airport_s1%3Aams&q=*%3A*&facet.limit=-100&group.field=hotel_s1&group=true&group.facet=true&fq=id%3A%5B2000+TO+2004%5D&indent=true&wt=xml";
>
>
>
>
> 0
> 17
>
> true
> true
> airport_s1:ams
> *:*
> -100
> hotel_s1
> true
> xml
> id:[2000 TO 2004]
> true
>
>
>
>
> 5
>
>
> a
>
>
> 2001
>
> 2001
>
> a
> dus
> 10
> 1474989437819551744
> 2014-07-29T18:45:43.819Z
>
> muLti-Defa
[jira] [Created] (SOLR-6314) Multi-threaded facet counts differ when SolrCloud has >1 shard
Vamsee Yarlagadda created SOLR-6314:
---
Summary: Multi-threaded facet counts differ when SolrCloud has >1
shard
Key: SOLR-6314
URL: https://issues.apache.org/jira/browse/SOLR-6314
Project: Solr
Issue Type: Bug
Components: SearchComponents - other, SolrCloud
Affects Versions: 5.0
Reporter: Vamsee Yarlagadda
I am trying to work with multi-threaded faceting on SolrCloud and in the
process i was hit by some issues.
I am currently running the below upstream test on different SolrCloud
configurations and i am getting a different result set per configuration.
https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/test/org/apache/solr/request/TestFaceting.java#L654
Setup:
- *Indexed 50 docs into SolrCloud.*
- *If the SolrCloud has only 1 shard, the facet field query has the below
output (which matches with the expected upstream test output - # facet fields ~
50).*
{code}
$ curl
"http://localhost:8983/solr/collection1/select?facet=true&fl=id&indent=true&q=id%3A*&facet.limit=-1&facet.threads=1000&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&rows=1&wt=xml";
0
21
true
id
true
id:*
-1
1000
f0_ws
f0_ws
f0_ws
f0_ws
f0_ws
f1_ws
f1_ws
f1_ws
f1_ws
f1_ws
f2_ws
f2_ws
f2_ws
f2_ws
f2_ws
f3_ws
f3_ws
f3_ws
f3_ws
f3_ws
f4_ws
f4_ws
f4_ws
f4_ws
f4_ws
f5_ws
f5_ws
f5_ws
f5_ws
f5_ws
f6_ws
f6_ws
f6_ws
f6_ws
f6_ws
f7_ws
f7_ws
f7_ws
f7_ws
f7_ws
f8_ws
f8_ws
f8_ws
f8_ws
f8_ws
f9_ws
f9_ws
f9_ws
f9_ws
f9_ws
xml
1
0.0
25
25
25
25
25
25
25
25
25
25
33
17
33
17
33
17
33
17
33
17
37
13
37
13
37
13
37
13
37
13
40
10
40
10
40
10
40
10
40
10
41
9
41
9
41
9
41
9
41
9
42
8
42
8
42
8
42
8
42
8
43
7
43
7
43
7
43
7
43
7
44
6
44
6
44
6
44
6
44
6
45
5
45
5
45
5
45
5
45
5
45
5
45
5
45
5
45
5
45
5
{code}
- *Now, if a create a new collection with 2 shards (>1 shard SolrCloud), the
same above query results in a different output. (# facet fields ~ 10 ;
Expected 50)*
{code}
$ curl
"http://localhost:8983/solr/collection1/select?facet=true&fl=id&indent=true&q=id%3A*&facet.limit=-1&facet.threads=1000&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f
[jira] [Commented] (SOLR-6313) Improve SolrCloud cloud-dev scripts.
[ https://issues.apache.org/jira/browse/SOLR-6313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083140#comment-14083140 ] Vamsee Yarlagadda commented on SOLR-6313: - +1 on the patch. I tried running the scripts in my local system and everything works as expected. Thanks for the effort, Mark. > Improve SolrCloud cloud-dev scripts. > > > Key: SOLR-6313 > URL: https://issues.apache.org/jira/browse/SOLR-6313 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Attachments: SOLR-6313.patch > > > I've been improving the cloud-dev scripts to help with manual testing. I've > been doing this mostly as part of SOLR-5656, but I'd like to spin in out into > it's own issue. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6300) facet.mincount fails to work if SolrCloud distrib=true is set
Vamsee Yarlagadda created SOLR-6300:
---
Summary: facet.mincount fails to work if SolrCloud distrib=true is
set
Key: SOLR-6300
URL: https://issues.apache.org/jira/browse/SOLR-6300
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 5.0
Reporter: Vamsee Yarlagadda
I notice that using facet.mincount in SolrCloud mode with distrib=true fails to
filter the facets based on the count. However, the same query with
distrib=false works as expected.
* Indexed some data as provided by the upstream test.
https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/test/org/apache/solr/request/SimpleFacetsTest.java#L633
* Test being run:
https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/test/org/apache/solr/request/SimpleFacetsTest.java#L657
* Running in SolrCloud mode with distrib=false (facet.mincount works as
expected)
{code}
$ curl
"http://search-testing-c5-3.ent.cloudera.com:8983/solr/simple_faceting_coll/select?facet.date.start=1976-07-01T00%3A00%3A00.000Z&facet=true&facet.mincount=1&q=*%3A*&facet.date=bday&facet.date.other=all&facet.date.gap=%2B1DAY&facet.date.end=1976-07-01T00%3A00%3A00.000Z%2B1MONTH&rows=0&indent=true&wt=xml&distrib=false";
0
3
1976-07-01T00:00:00.000Z
true
true
1
*:*
bday
false
+1DAY
all
xml
1976-07-01T00:00:00.000Z+1MONTH
0
1
1
1
1
1
1
1
+1DAY
1976-07-01T00:00:00Z
1976-08-01T00:00:00Z
2
0
6
{code}
* SolrCloud mode with distrib=true (facet.mincount fails to show effect)
{code}
$ curl
"http://search-testing-c5-3.ent.cloudera.com:8983/solr/simple_faceting_coll/select?facet.date.start=1976-07-01T00%3A00%3A00.000Z&facet=true&facet.mincount=1&q=*%3A*&facet.date=bday&facet.date.other=all&facet.date.gap=%2B1DAY&facet.date.end=1976-07-01T00%3A00%3A00.000Z%2B1MONTH&rows=0&indent=true&wt=xml&distrib=true";
0
12
1976-07-01T00:00:00.000Z
true
true
1
*:*
bday
true
+1DAY
all
xml
1976-07-01T00:00:00.000Z+1MONTH
0
0
0
2
2
2
0
0
0
0
0
0
1
1
0
2
0
0
0
0
0
1
0
0
0
0
0
0
0
0
1
0
+1DAY
1976-07-01T00:00:00Z
1976-08-01T00:00:00Z
2
1
11
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6299) Facet count on facet queries returns different results if #shards > 1
Vamsee Yarlagadda created SOLR-6299:
---
Summary: Facet count on facet queries returns different results if
#shards > 1
Key: SOLR-6299
URL: https://issues.apache.org/jira/browse/SOLR-6299
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 5.0
Reporter: Vamsee Yarlagadda
I am trying to run some facet counts on facet queries and looks like i am
getting different counts if i use >1 shards in the SolrCloud cluster.
Here is the upstream unit test:
https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/test/org/apache/solr/request/SimpleFacetsTest.java#L173
Setup:
* Ingested 5 solr docs.
{code}
{
"responseHeader": {
"status": 0,
"QTime": 22,
"params": {
"indent": "true",
"q": "*:*",
"_": "1406346687337",
"wt": "json"
}
},
"response": {
"numFound": 5,
"start": 0,
"maxScore": 1,
"docs": [
{
"id": 2004,
"range_facet_l": [
2004
],
"hotel_s1": "b",
"airport_s1": "ams",
"duration_i1": 5,
"_version_": 1474661321774465000,
"timestamp": "2014-07-26T03:50:27.975Z",
"multiDefault": [
"muLti-Default"
],
"intDefault": 42
},
{
"id": 2000,
"range_facet_l": [
2000
],
"hotel_s1": "a",
"airport_s1": "ams",
"duration_i1": 5,
"_version_": 1474661323604230100,
"timestamp": "2014-07-26T03:50:29.734Z",
"multiDefault": [
"muLti-Default"
],
"intDefault": 42
},
{
"id": 2003,
"range_facet_l": [
2003
],
"hotel_s1": "b",
"airport_s1": "ams",
"duration_i1": 5,
"_version_": 1474661326312702000,
"timestamp": "2014-07-26T03:50:32.317Z",
"multiDefault": [
"muLti-Default"
],
"intDefault": 42
},
{
"id": 2001,
"range_facet_l": [
2001
],
"hotel_s1": "a",
"airport_s1": "dus",
"duration_i1": 10,
"_version_": 1474661326389248000,
"timestamp": "2014-07-26T03:50:32.375Z",
"multiDefault": [
"muLti-Default"
],
"intDefault": 42
},
{
"id": 2002,
"range_facet_l": [
2002
],
"hotel_s1": "b",
"airport_s1": "ams",
"duration_i1": 10,
"_version_": 1474661326464745500,
"timestamp": "2014-07-26T03:50:32.446Z",
"multiDefault": [
"muLti-Default"
],
"intDefault": 42
}
]
}
}
{code}
Here is the query being run:
{code}
Test code:
assertQ(
req(
"q", "*:*",
"fq", "id:[2000 TO 2004]",
"group", "true",
"group.facet", "true",
"group.field", "hotel_s1",
"facet", "true",
"facet.limit", facetLimit,
"facet.query", "airport_s1:ams"
),
"//lst[@name='facet_queries']/int[@name='airport_s1:ams'][.='2']"
);
$ curl
"http://localhost:8983/solr/collection1/select?facet=true&facet.query=airport_s1%3Aams&q=*%3A*&facet.limit=-100&group.field=hotel_s1&group=true&group.facet=true&fq=id%3A%5B2000+TO+2004%5D&indent=true&wt=xml";
{code}
Now, if i issue a query statement - On *1* shard system (Works as expected)
{code}
$ curl
"http://localhost:8983/solr/collection1/select?facet=true&facet.query=airport_s1%3Aams&q=*%3A*&facet.limit=-100&group.field=hotel_s1&group=true&group.facet=true&fq=id%3A%5B2000+TO+2004%5D&indent=true&wt=xml";
0
17
true
true
airport_s1:ams
*:*
-100
hotel_s1
true
xml
id:[2000 TO 2004]
true
5
a
2001
2001
a
dus
10
1474989437819551744
2014-07-29T18:45:43.819Z
muLti-Default
42
b
2003
2003
b
ams
5
1474989439611568128
2014-07-29T18:45:45.528Z
muLti-Default
42
2
{code}
Now, if i run the same query on 2 shard system, i see facet count as *3*
instead of *2*.
Solr result on 2 shard cluster:
{code}
[systest@search-testing-c5-1 search]$ curl
"http://localhost:8983/solr/collection1/select?facet=true&facet.query=airport_s1%3Aams&q=*%3A*&facet.limit=-100&group.field=hotel_s1&group=true&group.facet=true&fq=id%3A%5B2000+TO+2004%5D&indent=true&wt=xml";
0
69
true
true
airport_s1:ams
*:*
[jira] [Updated] (SOLR-3345) BaseDistributedSearchTestCase should always ignore QTime
[ https://issues.apache.org/jira/browse/SOLR-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsee Yarlagadda updated SOLR-3345: Attachment: SOLR-3345-SVN.patch > BaseDistributedSearchTestCase should always ignore QTime > > > Key: SOLR-3345 > URL: https://issues.apache.org/jira/browse/SOLR-3345 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.0-ALPHA >Reporter: Benson Margulies >Assignee: Mark Miller > Attachments: SOLR-3345-SVN.patch, SOLR-3345.patch > > > The existing subclasses of BaseDistributedSearchTestCase all skip QTime. I > can't see any way in which those numbers will ever match. Why not make this > the default, or only, behavior? > (This is really a question, in that I will provide a patch if no one tells me > that it is a bad idea.) -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3345) BaseDistributedSearchTestCase should always ignore QTime
[ https://issues.apache.org/jira/browse/SOLR-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14069503#comment-14069503 ] Vamsee Yarlagadda commented on SOLR-3345: - [~markrmil...@gmail.com] Attached the SVN patch. Thanks! > BaseDistributedSearchTestCase should always ignore QTime > > > Key: SOLR-3345 > URL: https://issues.apache.org/jira/browse/SOLR-3345 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.0-ALPHA >Reporter: Benson Margulies >Assignee: Mark Miller > Attachments: SOLR-3345-SVN.patch, SOLR-3345.patch > > > The existing subclasses of BaseDistributedSearchTestCase all skip QTime. I > can't see any way in which those numbers will ever match. Why not make this > the default, or only, behavior? > (This is really a question, in that I will provide a patch if no one tells me > that it is a bad idea.) -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6252) Simplify UnInvertedField#getUnInvertedField synchronization module
[ https://issues.apache.org/jira/browse/SOLR-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14069392#comment-14069392 ] Vamsee Yarlagadda commented on SOLR-6252: - [~markrmil...@gmail.com] Good point! Updated the patch to reflect the suggestions. Thanks [~gchanan]. > Simplify UnInvertedField#getUnInvertedField synchronization module > -- > > Key: SOLR-6252 > URL: https://issues.apache.org/jira/browse/SOLR-6252 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 5.0 >Reporter: Vamsee Yarlagadda >Assignee: Mark Miller >Priority: Minor > Attachments: SOLR-6252-v3.patch, SOLR-6252.patch, SOLR-6252v2.patch > > > Looks like UnInvertedField#getUnInvertedField has implemented a bit > additional synchronization module rather than what is required, and thereby > increasing the complexity. > https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/request/UnInvertedField.java#L667 > As pointed out in the above link, as the synchronization is performed on the > cache variable(which itself will protect the threads from obtaining access to > the cache), we can safely remove all the placeholder flags. As long as > cache.get() is in synchronized block, we can simply populate the cache with > new entries and other threads will be able to see the changes. > This change has been introduced in > https://issues.apache.org/jira/browse/SOLR-2548 (Multithreaded faceting) -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6252) Simplify UnInvertedField#getUnInvertedField synchronization module
[ https://issues.apache.org/jira/browse/SOLR-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsee Yarlagadda updated SOLR-6252: Attachment: SOLR-6252-v3.patch > Simplify UnInvertedField#getUnInvertedField synchronization module > -- > > Key: SOLR-6252 > URL: https://issues.apache.org/jira/browse/SOLR-6252 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 5.0 >Reporter: Vamsee Yarlagadda >Assignee: Mark Miller >Priority: Minor > Attachments: SOLR-6252-v3.patch, SOLR-6252.patch, SOLR-6252v2.patch > > > Looks like UnInvertedField#getUnInvertedField has implemented a bit > additional synchronization module rather than what is required, and thereby > increasing the complexity. > https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/request/UnInvertedField.java#L667 > As pointed out in the above link, as the synchronization is performed on the > cache variable(which itself will protect the threads from obtaining access to > the cache), we can safely remove all the placeholder flags. As long as > cache.get() is in synchronized block, we can simply populate the cache with > new entries and other threads will be able to see the changes. > This change has been introduced in > https://issues.apache.org/jira/browse/SOLR-2548 (Multithreaded faceting) -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4999) Make the collections API consistent by using 'collection' instead of 'name'
[ https://issues.apache.org/jira/browse/SOLR-4999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14066543#comment-14066543 ] Vamsee Yarlagadda commented on SOLR-4999: - Good suggestion. But, this change might impact all the users who are using CollectionsAPI, which i assume is most of them. And moreover this might break their existing automation if any. To enable ease of move, we can certainly provide support to both "name", "collection" starting from 5.0 and we can document that the users can use either of the property names to pass on the value(collectionName). Looking at the CREATEALIAS, DELETEALIAS params, we are currently using "name" and with this proposal, i feel it would be good to use either "name" or "alias" for just the above operations. Thoughts? > Make the collections API consistent by using 'collection' instead of 'name' > --- > > Key: SOLR-4999 > URL: https://issues.apache.org/jira/browse/SOLR-4999 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 4.3.1 >Reporter: Anshum Gupta > > The collections API as of now are split between using 'name' and 'collection' > parameter. > We should add support to all APIs to work with 'collection', while > maintaining 'name' (where it already exists) until 5.0. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4895) Throw an error when a rollback is attempted in SolrCloud mode.
[ https://issues.apache.org/jira/browse/SOLR-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14065947#comment-14065947 ] Vamsee Yarlagadda commented on SOLR-4895: - Just wondering, what would be a good way to know (code wise) which mode is the Solr running on? Cloud or Standalone? Logically, if we are using ZooKeeper then we can assume it is running in SolrCloud mode. But, if we are dealing with classes like RequestHandlerUtils (org.apache.solr.handler) which is more generic in nature, how do we figure out the mode of Solr? > Throw an error when a rollback is attempted in SolrCloud mode. > -- > > Key: SOLR-4895 > URL: https://issues.apache.org/jira/browse/SOLR-4895 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.9, 5.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3345) BaseDistributedSearchTestCase should always ignore QTime
[ https://issues.apache.org/jira/browse/SOLR-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsee Yarlagadda updated SOLR-3345: Attachment: SOLR-3345.patch This patch will ensure that QTime value check gets skipped(as there is no guarantee that the value will match) at the BaseDistributedSearchTestCase rather than at test level. Note this patch will only ignore checking the value but the presence of tag "QTime" will be checked in the response. Ran all unit tests in trunk and everything passed. > BaseDistributedSearchTestCase should always ignore QTime > > > Key: SOLR-3345 > URL: https://issues.apache.org/jira/browse/SOLR-3345 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.0-ALPHA >Reporter: Benson Margulies > Attachments: SOLR-3345.patch > > > The existing subclasses of BaseDistributedSearchTestCase all skip QTime. I > can't see any way in which those numbers will ever match. Why not make this > the default, or only, behavior? > (This is really a question, in that I will provide a patch if no one tells me > that it is a bad idea.) -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6252) Simplify UnInvertedField#getUnInvertedField synchronization module
[ https://issues.apache.org/jira/browse/SOLR-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsee Yarlagadda updated SOLR-6252: Attachment: SOLR-6252v2.patch Removed the extra comment as pointed by Greg. > Simplify UnInvertedField#getUnInvertedField synchronization module > -- > > Key: SOLR-6252 > URL: https://issues.apache.org/jira/browse/SOLR-6252 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 5.0 >Reporter: Vamsee Yarlagadda >Priority: Minor > Attachments: SOLR-6252.patch, SOLR-6252v2.patch > > > Looks like UnInvertedField#getUnInvertedField has implemented a bit > additional synchronization module rather than what is required, and thereby > increasing the complexity. > https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/request/UnInvertedField.java#L667 > As pointed out in the above link, as the synchronization is performed on the > cache variable(which itself will protect the threads from obtaining access to > the cache), we can safely remove all the placeholder flags. As long as > cache.get() is in synchronized block, we can simply populate the cache with > new entries and other threads will be able to see the changes. > This change has been introduced in > https://issues.apache.org/jira/browse/SOLR-2548 (Multithreaded faceting) -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6252) Simplify UnInvertedField#getUnInvertedField synchronization module
[ https://issues.apache.org/jira/browse/SOLR-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsee Yarlagadda updated SOLR-6252: Attachment: SOLR-6252.patch > Simplify UnInvertedField#getUnInvertedField synchronization module > -- > > Key: SOLR-6252 > URL: https://issues.apache.org/jira/browse/SOLR-6252 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 5.0 >Reporter: Vamsee Yarlagadda >Priority: Minor > Attachments: SOLR-6252.patch > > > Looks like UnInvertedField#getUnInvertedField has implemented a bit > additional synchronization module rather than what is required, and thereby > increasing the complexity. > https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/request/UnInvertedField.java#L667 > As pointed out in the above link, as the synchronization is performed on the > cache variable(which itself will protect the threads from obtaining access to > the cache), we can safely remove all the placeholder flags. As long as > cache.get() is in synchronized block, we can simply populate the cache with > new entries and other threads will be able to see the changes. > This change has been introduced in > https://issues.apache.org/jira/browse/SOLR-2548 (Multithreaded faceting) -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6252) Simplify UnInvertedField#getUnInvertedField synchronization module
Vamsee Yarlagadda created SOLR-6252: --- Summary: Simplify UnInvertedField#getUnInvertedField synchronization module Key: SOLR-6252 URL: https://issues.apache.org/jira/browse/SOLR-6252 Project: Solr Issue Type: Improvement Components: search Affects Versions: 5.0 Reporter: Vamsee Yarlagadda Priority: Minor Looks like UnInvertedField#getUnInvertedField has implemented a bit additional synchronization module rather than what is required, and thereby increasing the complexity. https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/request/UnInvertedField.java#L667 As pointed out in the above link, as the synchronization is performed on the cache variable(which itself will protect the threads from obtaining access to the cache), we can safely remove all the placeholder flags. As long as cache.get() is in synchronized block, we can simply populate the cache with new entries and other threads will be able to see the changes. This change has been introduced in https://issues.apache.org/jira/browse/SOLR-2548 (Multithreaded faceting) -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4072) Error message is incorrect for linkconfig in ZkCLI
[
https://issues.apache.org/jira/browse/SOLR-4072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsee Yarlagadda updated SOLR-4072:
Attachment: SOLR-4072.patch
Patch available.
> Error message is incorrect for linkconfig in ZkCLI
> --
>
> Key: SOLR-4072
> URL: https://issues.apache.org/jira/browse/SOLR-4072
> Project: Solr
> Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Adam Hahn
>Priority: Trivial
> Attachments: SOLR-4072.patch
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> If you don't include both the collection and confname when doing a
> linkconfig, it shows you an incorrect error message stating that the CONFDIR
> is required for linkconfig. That should be changed to COLLECTION. The
> incorrect code is below.
> else if (line.getOptionValue(CMD).equals(LINKCONFIG)) {
> if (!line.hasOption(COLLECTION) || !line.hasOption(CONFNAME)) {
> System.out.println("-" + {color:red} CONFDIR {color} + " and -" +
> CONFNAME
> + " are required for " + LINKCONFIG);
> System.exit(1);
> }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
