[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=falsewt=javabinversion=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=falsewt=javabinversion=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/election/93427899815755803-core_node8-n_01
2015-03-05 22:05:27,393 INFO org.apache.solr.core.SolrCore:
[SolrUpgrade_collection_shard2_1_replica3] CLOSING SolrCore
[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-tabpanelfocusedCommentId=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 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]
[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=falsewt=javabinversion=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=falsewt=javabinversion=2} hits=118 status=0 QTime=0
2015-03-05 22:05:27,392 INFO org.apache.solr.cloud.ElectionContext: canceling
election
[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-tabpanelfocusedCommentId=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:520)
at
[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=FROMLEADERwt=javabinversion=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
[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.java:1145)
at
[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-tabpanelfocusedCommentId=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.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
at
[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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-7124) Add delconfig command to zkcli
[ https://issues.apache.org/jira/browse/SOLR-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [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] [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 we can notice, we can see the exception but we don't have any information
around which server is
[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(ThreadPoolExecutor.java:1145)
at
[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-tabpanelfocusedCommentId=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(ConcurrentUpdateSolrServer.java:235)
at
[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(StatementAdapter.java:36)
at
[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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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(NoShadowingOrOverridesOnMethodsRule.java:39)
at
[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-tabpanelfocusedCommentId=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.StatementAdapter.evaluate(StatementAdapter.java:36)
at
[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-tabpanelfocusedCommentId=14339702#comment-14339702 ] Vamsee Yarlagadda commented on SOLR-7124: - Looks like zkcli .. -cmd clear znode can delete the znodes recursively. So a user can call this for /solr/configs/ConfigName 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] [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(StatementAdapter.java:36)
at
[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: 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: 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: (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-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] [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] [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-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 /stream 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(/stream.getBytes(StandardCharsets.UTF_8));
}
should be moved to the finally statement.
If InteruptedException is raised, it will send the wrong xml document without
/stream 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-tabpanelfocusedCommentId=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] [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=STATUScore=abc
{code}
response
lst name=responseHeader
int name=status0/int
int name=QTime1/int
/lstlst name=initFailures/
lst name=status
lst name=abc/
/lst
/response
{code}
Instead, it would be good to return an error message stating that the core
doesn't exist.
e.g
{code}
response
lst name=responseHeader
int name=status400/int
int name=QTime27/int
/lst
lst name=initFailures/
lst name=error
str name=msgCore [abc] does not exist/str
int name=code400/int
/lst
/response
{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-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=STATUScore=abc
{code}
response
lst name=responseHeader
int name=status0/int
int name=QTime1/int
/lstlst name=initFailures/
lst name=status
lst name=abc/
/lst
/response
{code}
Instead, it would be good to return an error message stating that the core
doesn't exist.
e.g
{code}
response
lst name=responseHeader
int name=status400/int
int name=QTime27/int
/lst
lst name=initFailures/
lst name=error
str name=msgCore [abc] does not exist/str
int name=code400/int
/lst
/response
{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-tabpanelfocusedCommentId=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=truefl=idindent=trueq=id%3A*facet.limit=-1facet.threads=1000facet.field=f0_wsfacet.field=f0_wsfacet.field=f0_wsfacet.field=f0_wsfacet.field=f0_wsfacet.field=f1_wsfacet.field=f1_wsfacet.field=f1_wsfacet.field=f1_wsfacet.field=f1_wsfacet.field=f2_wsfacet.field=f2_wsfacet.field=f2_wsfacet.field=f2_wsfacet.field=f2_wsfacet.field=f3_wsfacet.field=f3_wsfacet.field=f3_wsfacet.field=f3_wsfacet.field=f3_wsfacet.field=f4_wsfacet.field=f4_wsfacet.field=f4_wsfacet.field=f4_wsfacet.field=f4_wsfacet.field=f5_wsfacet.field=f5_wsfacet.field=f5_wsfacet.field=f5_wsfacet.field=f5_wsfacet.field=f6_wsfacet.field=f6_wsfacet.field=f6_wsfacet.field=f6_wsfacet.field=f6_wsfacet.field=f7_wsfacet.field=f7_wsfacet.field=f7_wsfacet.field=f7_wsfacet.field=f7_wsfacet.field=f8_wsfacet.field=f8_wsfacet.field=f8_wsfacet.field=f8_wsfacet.field=f8_wsfacet.field=f9_wsfacet.field=f9_wsfacet.field=f9_wsfacet.field=f9_wsfacet.field=f9_wsrows=1wt=xml;
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeader
int name=status0/int
int name=QTime21/int
lst name=params
str name=facettrue/str
str name=flid/str
str name=indenttrue/str
str name=qid:*/str
str name=facet.limit-1/str
str name=facet.threads1000/str
arr name=facet.field
strf0_ws/str
strf0_ws/str
strf0_ws/str
strf0_ws/str
strf0_ws/str
strf1_ws/str
strf1_ws/str
strf1_ws/str
strf1_ws/str
strf1_ws/str
strf2_ws/str
strf2_ws/str
strf2_ws/str
strf2_ws/str
strf2_ws/str
strf3_ws/str
strf3_ws/str
strf3_ws/str
strf3_ws/str
strf3_ws/str
strf4_ws/str
strf4_ws/str
strf4_ws/str
strf4_ws/str
strf4_ws/str
strf5_ws/str
strf5_ws/str
strf5_ws/str
strf5_ws/str
strf5_ws/str
strf6_ws/str
strf6_ws/str
strf6_ws/str
strf6_ws/str
strf6_ws/str
strf7_ws/str
strf7_ws/str
strf7_ws/str
strf7_ws/str
strf7_ws/str
strf8_ws/str
strf8_ws/str
strf8_ws/str
strf8_ws/str
strf8_ws/str
strf9_ws/str
strf9_ws/str
strf9_ws/str
strf9_ws/str
strf9_ws/str
/arr
str name=wtxml/str
str name=rows1/str
/lst
/lst
result name=response numFound=50 start=0
doc
float name=id0.0/float/doc
/result
lst name=facet_counts
lst name=facet_queries/
lst name=facet_fields
lst name=f0_ws
int name=zero_125/int
int name=zero_225/int
/lst
lst name=f0_ws
int name=zero_125/int
int name=zero_225/int
/lst
lst name=f0_ws
int name=zero_125/int
int name=zero_225/int
/lst
lst name=f0_ws
int name=zero_125/int
int name=zero_225/int
/lst
lst name=f0_ws
int name=zero_125/int
int name=zero_225/int
/lst
lst name=f1_ws
int name=one_133/int
int name=one_317/int
/lst
lst name=f1_ws
int name=one_133/int
int name=one_317/int
/lst
lst name=f1_ws
int name=one_133/int
int name=one_317/int
/lst
lst name=f1_ws
int name=one_133/int
int name=one_317/int
/lst
lst name=f1_ws
int name=one_133/int
int name=one_317/int
/lst
lst name=f2_ws
int name=two_137/int
int name=two_413/int
/lst
lst name=f2_ws
[jira] [Created] (SOLR-6375) facet_ranges count for before,after,between differ if #shards1
Vamsee Yarlagadda created SOLR-6375:
---
Summary: facet_ranges count for before,after,between differ if
#shards1
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}
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeader
int name=status0/int
int name=QTime12/int
lst name=params
str name=facet.range.includelower/str
str name=facet.range.otherall/str
str name=facettrue/str
str name=indenttrue/str
str name=q*:*/str
str name=facet.range.start1976-07-01T00:00:00.000Z/str
str name=facet.rangea_tdt/str
str name=facet.range.end1976-07-16T00:00:00.000Z/str
str name=facet.range.gap+1DAY/str
str name=wtxml/str
str name=rows0/str
/lst
/lst
result name=response numFound=63 start=0
/result
lst name=facet_counts
lst name=facet_queries/
lst name=facet_fields/
lst name=facet_dates/
lst name=facet_ranges
lst name=a_tdt
lst name=counts
int name=1976-07-01T00:00:00Z1/int
int name=1976-07-02T00:00:00Z0/int
int name=1976-07-03T00:00:00Z0/int
int name=1976-07-04T00:00:00Z1/int
int name=1976-07-05T00:00:00Z2/int
int name=1976-07-06T00:00:00Z0/int
int name=1976-07-07T00:00:00Z1/int
int name=1976-07-08T00:00:00Z0/int
int name=1976-07-09T00:00:00Z0/int
int name=1976-07-10T00:00:00Z0/int
int name=1976-07-11T00:00:00Z0/int
int name=1976-07-12T00:00:00Z0/int
int name=1976-07-13T00:00:00Z2/int
int name=1976-07-14T00:00:00Z0/int
int name=1976-07-15T00:00:00Z1/int
/lst
str name=gap+1DAY/str
date name=start1976-07-01T00:00:00Z/date
date name=end1976-07-16T00:00:00Z/date
int name=before1/int
int name=after1/int
int name=between8/int
/lst
/lst
/lst
/response
{code}
Running the same above on #shards 1 (facet_range count for
after,before,between differs)
{code}
response
lst name=responseHeader
int name=status0/int
int name=QTime7/int
lst name=params
str name=facet.range.includelower/str
str name=facet.range.otherall/str
str name=facettrue/str
str name=indenttrue/str
str name=q*:*/str
str name=facet.range.start1976-07-01T00:00:00.000Z/str
str name=facet.rangea_tdt/str
str name=facet.range.end1976-07-16T00:00:00.000Z/str
str name=facet.range.gap+1DAY/str
str name=wtxml/str
str name=rows0/str
/lst
/lst
result name=response numFound=63 start=0 maxScore=1.0
/result
lst name=facet_counts
lst name=facet_queries/
lst name=facet_fields/
lst name=facet_dates/
lst name=facet_ranges
lst name=a_tdt
lst name=counts
int name=1976-07-01T00:00:00Z1/int
int name=1976-07-02T00:00:00Z0/int
int name=1976-07-03T00:00:00Z0/int
int name=1976-07-04T00:00:00Z1/int
int name=1976-07-05T00:00:00Z2/int
int name=1976-07-06T00:00:00Z0/int
int name=1976-07-07T00:00:00Z1/int
int name=1976-07-08T00:00:00Z0/int
int name=1976-07-09T00:00:00Z0/int
int name=1976-07-10T00:00:00Z0/int
int name=1976-07-11T00:00:00Z0/int
int name=1976-07-12T00:00:00Z0/int
int name=1976-07-13T00:00:00Z2/int
int name=1976-07-14T00:00:00Z0/int
int name=1976-07-15T00:00:00Z1/int
/lst
str name=gap+1DAY/str
date name=start1976-07-01T00:00:00Z/date
date name=end1976-07-16T00:00:00Z/date
int name=before1/int
int name=after0/int
int name=between3/int
/lst
/lst
/lst
/response
{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-tabpanelfocusedCommentId=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=truefl=idindent=trueq=id%3A*facet.limit=-1facet.threads=1000facet.field=f0_wsfacet.field=f0_wsfacet.field=f0_wsfacet.field=f0_wsfacet.field=f0_wsfacet.field=f1_wsfacet.field=f1_wsfacet.field=f1_wsfacet.field=f1_wsfacet.field=f1_wsfacet.field=f2_wsfacet.field=f2_wsfacet.field=f2_wsfacet.field=f2_wsfacet.field=f2_wsfacet.field=f3_wsfacet.field=f3_wsfacet.field=f3_wsfacet.field=f3_wsfacet.field=f3_wsfacet.field=f4_wsfacet.field=f4_wsfacet.field=f4_wsfacet.field=f4_wsfacet.field=f4_wsfacet.field=f5_wsfacet.field=f5_wsfacet.field=f5_wsfacet.field=f5_wsfacet.field=f5_wsfacet.field=f6_wsfacet.field=f6_wsfacet.field=f6_wsfacet.field=f6_wsfacet.field=f6_wsfacet.field=f7_wsfacet.field=f7_wsfacet.field=f7_wsfacet.field=f7_wsfacet.field=f7_wsfacet.field=f8_wsfacet.field=f8_wsfacet.field=f8_wsfacet.field=f8_wsfacet.field=f8_wsfacet.field=f9_wsfacet.field=f9_wsfacet.field=f9_wsfacet.field=f9_wsfacet.field=f9_wsrows=1wt=xml;
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeader
int name=status0/int
int name=QTime21/int
lst name=params
str name=facettrue/str
str name=flid/str
str name=indenttrue/str
str name=qid:*/str
str name=facet.limit-1/str
str name=facet.threads1000/str
arr name=facet.field
strf0_ws/str
strf0_ws/str
strf0_ws/str
strf0_ws/str
strf0_ws/str
strf1_ws/str
strf1_ws/str
strf1_ws/str
strf1_ws/str
strf1_ws/str
strf2_ws/str
strf2_ws/str
strf2_ws/str
strf2_ws/str
strf2_ws/str
strf3_ws/str
strf3_ws/str
strf3_ws/str
strf3_ws/str
strf3_ws/str
strf4_ws/str
strf4_ws/str
strf4_ws/str
strf4_ws/str
strf4_ws/str
strf5_ws/str
strf5_ws/str
strf5_ws/str
strf5_ws/str
strf5_ws/str
strf6_ws/str
strf6_ws/str
strf6_ws/str
strf6_ws/str
strf6_ws/str
strf7_ws/str
strf7_ws/str
strf7_ws/str
strf7_ws/str
strf7_ws/str
strf8_ws/str
strf8_ws/str
strf8_ws/str
strf8_ws/str
strf8_ws/str
strf9_ws/str
strf9_ws/str
strf9_ws/str
strf9_ws/str
strf9_ws/str
/arr
str name=wtxml/str
str name=rows1/str
/lst
/lst
result name=response numFound=50 start=0
doc
float name=id0.0/float/doc
/result
lst name=facet_counts
lst name=facet_queries/
lst name=facet_fields
lst name=f0_ws
int name=zero_125/int
int name=zero_225/int
/lst
lst name=f0_ws
int name=zero_125/int
int name=zero_225/int
/lst
lst name=f0_ws
int name=zero_125/int
int name=zero_225/int
/lst
lst name=f0_ws
int name=zero_125/int
int name=zero_225/int
/lst
lst
[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-tabpanelfocusedCommentId=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=truefl=idindent=trueq=id%3A*facet.limit=-1facet.threads=1000facet.field=f0_wsfacet.field=f0_wsfacet.field=f0_wsfacet.field=f0_wsfacet.field=f0_wsfacet.field=f1_wsfacet.field=f1_wsfacet.field=f1_wsfacet.field=f1_wsfacet.field=f1_wsfacet.field=f2_wsfacet.field=f2_wsfacet.field=f2_wsfacet.field=f2_wsfacet.field=f2_wsfacet.field=f3_wsfacet.field=f3_wsfacet.field=f3_wsfacet.field=f3_wsfacet.field=f3_wsfacet.field=f4_wsfacet.field=f4_wsfacet.field=f4_wsfacet.field=f4_wsfacet.field=f4_wsfacet.field=f5_wsfacet.field=f5_wsfacet.field=f5_wsfacet.field=f5_wsfacet.field=f5_wsfacet.field=f6_wsfacet.field=f6_wsfacet.field=f6_wsfacet.field=f6_wsfacet.field=f6_wsfacet.field=f7_wsfacet.field=f7_wsfacet.field=f7_wsfacet.field=f7_wsfacet.field=f7_wsfacet.field=f8_wsfacet.field=f8_wsfacet.field=f8_wsfacet.field=f8_wsfacet.field=f8_wsfacet.field=f9_wsfacet.field=f9_wsfacet.field=f9_wsfacet.field=f9_wsfacet.field=f9_wsrows=1wt=xml;
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeader
int name=status0/int
int name=QTime21/int
lst name=params
str name=facettrue/str
str name=flid/str
str name=indenttrue/str
str name=qid:*/str
str name=facet.limit-1/str
str name=facet.threads1000/str
arr name=facet.field
strf0_ws/str
strf0_ws/str
strf0_ws/str
strf0_ws/str
strf0_ws/str
strf1_ws/str
strf1_ws/str
strf1_ws/str
strf1_ws/str
strf1_ws/str
strf2_ws/str
strf2_ws/str
strf2_ws/str
strf2_ws/str
strf2_ws/str
strf3_ws/str
strf3_ws/str
strf3_ws/str
strf3_ws/str
strf3_ws/str
strf4_ws/str
strf4_ws/str
strf4_ws/str
strf4_ws/str
strf4_ws/str
strf5_ws/str
strf5_ws/str
strf5_ws/str
strf5_ws/str
strf5_ws/str
strf6_ws/str
strf6_ws/str
strf6_ws/str
strf6_ws/str
strf6_ws/str
strf7_ws/str
strf7_ws/str
strf7_ws/str
strf7_ws/str
strf7_ws/str
strf8_ws/str
strf8_ws/str
strf8_ws/str
strf8_ws/str
strf8_ws/str
strf9_ws/str
strf9_ws/str
strf9_ws/str
strf9_ws/str
strf9_ws/str
/arr
str name=wtxml/str
str name=rows1/str
/lst
/lst
result name=response numFound=50 start=0
doc
float name=id0.0/float/doc
/result
lst name=facet_counts
lst name=facet_queries/
lst name=facet_fields
lst name=f0_ws
int name=zero_125/int
int name=zero_225/int
/lst
lst name=f0_ws
int name=zero_125/int
int name=zero_225/int
/lst
lst name=f0_ws
int name=zero_125/int
int name=zero_225/int
/lst
lst name=f0_ws
int name=zero_125/int
int name=zero_225/int
/lst
lst name=f0_ws
int name=zero_125/int
int name=zero_225/int
/lst
lst name=f1_ws
int name=one_133/int
int name=one_317/int
/lst
lst name=f1_ws
int name=one_133/int
int name=one_317/int
/lst
lst name=f1_ws
int name=one_133/int
int name=one_317/int
/lst
lst name=f1_ws
int name=one_133/int
int name=one_317/int
/lst
lst name=f1_ws
int name=one_133/int
int name=one_317/int
/lst
lst name=f2_ws
int name=two_137/int
int name=two_413/int
/lst
lst name=f2_ws
int name=two_137/int
[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-tabpanelfocusedCommentId=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-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=truefl=idindent=trueq=id%3A*facet.limit=-1facet.threads=1000facet.field=f0_wsfacet.field=f0_wsfacet.field=f0_wsfacet.field=f0_wsfacet.field=f0_wsfacet.field=f1_wsfacet.field=f1_wsfacet.field=f1_wsfacet.field=f1_wsfacet.field=f1_wsfacet.field=f2_wsfacet.field=f2_wsfacet.field=f2_wsfacet.field=f2_wsfacet.field=f2_wsfacet.field=f3_wsfacet.field=f3_wsfacet.field=f3_wsfacet.field=f3_wsfacet.field=f3_wsfacet.field=f4_wsfacet.field=f4_wsfacet.field=f4_wsfacet.field=f4_wsfacet.field=f4_wsfacet.field=f5_wsfacet.field=f5_wsfacet.field=f5_wsfacet.field=f5_wsfacet.field=f5_wsfacet.field=f6_wsfacet.field=f6_wsfacet.field=f6_wsfacet.field=f6_wsfacet.field=f6_wsfacet.field=f7_wsfacet.field=f7_wsfacet.field=f7_wsfacet.field=f7_wsfacet.field=f7_wsfacet.field=f8_wsfacet.field=f8_wsfacet.field=f8_wsfacet.field=f8_wsfacet.field=f8_wsfacet.field=f9_wsfacet.field=f9_wsfacet.field=f9_wsfacet.field=f9_wsfacet.field=f9_wsrows=1wt=xml;
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeader
int name=status0/int
int name=QTime21/int
lst name=params
str name=facettrue/str
str name=flid/str
str name=indenttrue/str
str name=qid:*/str
str name=facet.limit-1/str
str name=facet.threads1000/str
arr name=facet.field
strf0_ws/str
strf0_ws/str
strf0_ws/str
strf0_ws/str
strf0_ws/str
strf1_ws/str
strf1_ws/str
strf1_ws/str
strf1_ws/str
strf1_ws/str
strf2_ws/str
strf2_ws/str
strf2_ws/str
strf2_ws/str
strf2_ws/str
strf3_ws/str
strf3_ws/str
strf3_ws/str
strf3_ws/str
strf3_ws/str
strf4_ws/str
strf4_ws/str
strf4_ws/str
strf4_ws/str
strf4_ws/str
strf5_ws/str
strf5_ws/str
strf5_ws/str
strf5_ws/str
strf5_ws/str
strf6_ws/str
strf6_ws/str
strf6_ws/str
strf6_ws/str
strf6_ws/str
strf7_ws/str
strf7_ws/str
strf7_ws/str
strf7_ws/str
strf7_ws/str
strf8_ws/str
strf8_ws/str
strf8_ws/str
strf8_ws/str
strf8_ws/str
strf9_ws/str
strf9_ws/str
strf9_ws/str
strf9_ws/str
strf9_ws/str
/arr
str name=wtxml/str
str name=rows1/str
/lst
/lst
result name=response numFound=50 start=0
doc
float name=id0.0/float/doc
/result
lst name=facet_counts
lst name=facet_queries/
lst name=facet_fields
lst name=f0_ws
int name=zero_125/int
int name=zero_225/int
/lst
lst name=f0_ws
int name=zero_125/int
int name=zero_225/int
/lst
lst name=f0_ws
int name=zero_125/int
int name=zero_225/int
/lst
lst name=f0_ws
int name=zero_125/int
int name=zero_225/int
/lst
lst name=f0_ws
int name=zero_125/int
int name=zero_225/int
/lst
lst name=f1_ws
int name=one_133/int
int name=one_317/int
/lst
lst name=f1_ws
int name=one_133/int
int name=one_317/int
/lst
lst name=f1_ws
int name=one_133/int
int name=one_317/int
/lst
lst name=f1_ws
int name=one_133/int
int name=one_317/int
/lst
lst name=f1_ws
int name=one_133/int
int name=one_317/int
/lst
lst name=f2_ws
int name=two_137/int
int name=two_413/int
/lst
lst name=f2_ws
int name=two_137/int
int name=two_413/int
/lst
lst name=f2_ws
int name=two_137/int
int name=two_413/int
/lst
lst name=f2_ws
int name=two_137/int
int name=two_413/int
/lst
lst name=f2_ws
int name=two_137/int
int name=two_413/int
/lst
lst name=f3_ws
int name=three_140/int
int name=three_510/int
/lst
lst name=f3_ws
int name=three_140/int
int name=three_510/int
/lst
lst name=f3_ws
int name=three_140/int
int
[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=truefacet.query=airport_s1%3Aamsq=*%3A*facet.limit=-100group.field=hotel_s1group=truegroup.facet=truefq=id%3A%5B2000+TO+2004%5Dindent=truewt=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=truefacet.query=airport_s1%3Aamsq=*%3A*facet.limit=-100group.field=hotel_s1group=truegroup.facet=truefq=id%3A%5B2000+TO+2004%5Dindent=truewt=xml;
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeader
int name=status0/int
int name=QTime17/int
lst name=params
str name=facettrue/str
str name=indenttrue/str
str name=facet.queryairport_s1:ams/str
str name=q*:*/str
str name=facet.limit-100/str
str name=group.fieldhotel_s1/str
str name=grouptrue/str
str name=wtxml/str
str name=fqid:[2000 TO 2004]/str
str name=group.facettrue/str
/lst
/lst
lst name=grouped
lst name=hotel_s1
int name=matches5/int
arr name=groups
lst
str name=groupValuea/str
result name=doclist numFound=2 start=0
doc
int name=id2001/int
arr name=range_facet_l
long2001/long
/arr
str name=hotel_s1a/str
[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.000Zfacet=truefacet.mincount=1q=*%3A*facet.date=bdayfacet.date.other=allfacet.date.gap=%2B1DAYfacet.date.end=1976-07-01T00%3A00%3A00.000Z%2B1MONTHrows=0indent=truewt=xmldistrib=false;
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeader
int name=status0/int
int name=QTime3/int
lst name=params
str name=facet.date.start1976-07-01T00:00:00.000Z/str
str name=facettrue/str
str name=indenttrue/str
str name=facet.mincount1/str
str name=q*:*/str
str name=facet.datebday/str
str name=distribfalse/str
str name=facet.date.gap+1DAY/str
str name=facet.date.otherall/str
str name=wtxml/str
str name=facet.date.end1976-07-01T00:00:00.000Z+1MONTH/str
str name=rows0/str
/lst
/lst
result name=response numFound=33 start=0
/result
lst name=facet_counts
lst name=facet_queries/
lst name=facet_fields/
lst name=facet_dates
lst name=bday
int name=1976-07-03T00:00:00Z1/int
int name=1976-07-04T00:00:00Z1/int
int name=1976-07-05T00:00:00Z1/int
int name=1976-07-13T00:00:00Z1/int
int name=1976-07-15T00:00:00Z1/int
int name=1976-07-21T00:00:00Z1/int
int name=1976-07-30T00:00:00Z1/int
str name=gap+1DAY/str
date name=start1976-07-01T00:00:00Z/date
date name=end1976-08-01T00:00:00Z/date
int name=before2/int
int name=after0/int
int name=between6/int
/lst
/lst
lst name=facet_ranges/
/lst
/response
{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.000Zfacet=truefacet.mincount=1q=*%3A*facet.date=bdayfacet.date.other=allfacet.date.gap=%2B1DAYfacet.date.end=1976-07-01T00%3A00%3A00.000Z%2B1MONTHrows=0indent=truewt=xmldistrib=true;
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeader
int name=status0/int
int name=QTime12/int
lst name=params
str name=facet.date.start1976-07-01T00:00:00.000Z/str
str name=facettrue/str
str name=indenttrue/str
str name=facet.mincount1/str
str name=q*:*/str
str name=facet.datebday/str
str name=distribtrue/str
str name=facet.date.gap+1DAY/str
str name=facet.date.otherall/str
str name=wtxml/str
str name=facet.date.end1976-07-01T00:00:00.000Z+1MONTH/str
str name=rows0/str
/lst
/lst
result name=response numFound=63 start=0 maxScore=1.0
/result
lst name=facet_counts
lst name=facet_queries/
lst name=facet_fields/
lst name=facet_dates
lst name=bday
int name=1976-07-01T00:00:00Z0/int
int name=1976-07-02T00:00:00Z0/int
int name=1976-07-03T00:00:00Z2/int
int name=1976-07-04T00:00:00Z2/int
int name=1976-07-05T00:00:00Z2/int
int name=1976-07-06T00:00:00Z0/int
int name=1976-07-07T00:00:00Z0/int
int name=1976-07-08T00:00:00Z0/int
int name=1976-07-09T00:00:00Z0/int
int name=1976-07-10T00:00:00Z0/int
int name=1976-07-11T00:00:00Z0/int
int name=1976-07-12T00:00:00Z1/int
int name=1976-07-13T00:00:00Z1/int
int name=1976-07-14T00:00:00Z0/int
int name=1976-07-15T00:00:00Z2/int
int name=1976-07-16T00:00:00Z0/int
int name=1976-07-17T00:00:00Z0/int
int name=1976-07-18T00:00:00Z0/int
int name=1976-07-19T00:00:00Z0/int
int name=1976-07-20T00:00:00Z0/int
int name=1976-07-21T00:00:00Z1/int
int name=1976-07-22T00:00:00Z0/int
int name=1976-07-23T00:00:00Z0/int
[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=truefacet.query=airport_s1%3Aamsq=*%3A*facet.limit=-100group.field=hotel_s1group=truegroup.facet=truefq=id%3A%5B2000+TO+2004%5Dindent=truewt=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=truefacet.query=airport_s1%3Aamsq=*%3A*facet.limit=-100group.field=hotel_s1group=truegroup.facet=truefq=id%3A%5B2000+TO+2004%5Dindent=truewt=xml;
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeader
int name=status0/int
int name=QTime17/int
lst name=params
str name=facettrue/str
str name=indenttrue/str
str name=facet.queryairport_s1:ams/str
str name=q*:*/str
str name=facet.limit-100/str
str name=group.fieldhotel_s1/str
str name=grouptrue/str
str name=wtxml/str
str name=fqid:[2000 TO 2004]/str
str name=group.facettrue/str
/lst
/lst
lst name=grouped
lst name=hotel_s1
int name=matches5/int
arr name=groups
lst
str name=groupValuea/str
result name=doclist numFound=2 start=0
doc
int name=id2001/int
arr name=range_facet_l
long2001/long
/arr
str name=hotel_s1a/str
str name=airport_s1dus/str
int name=duration_i110/int
long name=_version_1474989437819551744/long
date name=timestamp2014-07-29T18:45:43.819Z/date
arr name=multiDefault
strmuLti-Default/str
/arr
int name=intDefault42/int/doc
/result
/lst
lst
str name=groupValueb/str
result name=doclist numFound=3 start=0
doc
int name=id2003/int
arr name=range_facet_l
long2003/long
/arr
str name=hotel_s1b/str
str name=airport_s1ams/str
int
[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.000Zfacet=truefacet.mincount=1q=*%3A*facet.date=bdayfacet.date.other=allfacet.date.gap=%2B1DAYfacet.date.end=1976-07-01T00%3A00%3A00.000Z%2B1MONTHrows=0indent=truewt=xmldistrib=false;
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeader
int name=status0/int
int name=QTime3/int
lst name=params
str name=facet.date.start1976-07-01T00:00:00.000Z/str
str name=facettrue/str
str name=indenttrue/str
str name=facet.mincount1/str
str name=q*:*/str
str name=facet.datebday/str
str name=distribfalse/str
str name=facet.date.gap+1DAY/str
str name=facet.date.otherall/str
str name=wtxml/str
str name=facet.date.end1976-07-01T00:00:00.000Z+1MONTH/str
str name=rows0/str
/lst
/lst
result name=response numFound=33 start=0
/result
lst name=facet_counts
lst name=facet_queries/
lst name=facet_fields/
lst name=facet_dates
lst name=bday
int name=1976-07-03T00:00:00Z1/int
int name=1976-07-04T00:00:00Z1/int
int name=1976-07-05T00:00:00Z1/int
int name=1976-07-13T00:00:00Z1/int
int name=1976-07-15T00:00:00Z1/int
int name=1976-07-21T00:00:00Z1/int
int name=1976-07-30T00:00:00Z1/int
str name=gap+1DAY/str
date name=start1976-07-01T00:00:00Z/date
date name=end1976-08-01T00:00:00Z/date
int name=before2/int
int name=after0/int
int name=between6/int
/lst
/lst
lst name=facet_ranges/
/lst
/response
{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.000Zfacet=truefacet.mincount=1q=*%3A*facet.date=bdayfacet.date.other=allfacet.date.gap=%2B1DAYfacet.date.end=1976-07-01T00%3A00%3A00.000Z%2B1MONTHrows=0indent=truewt=xmldistrib=true;
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeader
int name=status0/int
int name=QTime12/int
lst name=params
str name=facet.date.start1976-07-01T00:00:00.000Z/str
str name=facettrue/str
str name=indenttrue/str
str name=facet.mincount1/str
str name=q*:*/str
str name=facet.datebday/str
str name=distribtrue/str
str name=facet.date.gap+1DAY/str
str name=facet.date.otherall/str
str name=wtxml/str
str name=facet.date.end1976-07-01T00:00:00.000Z+1MONTH/str
str name=rows0/str
/lst
/lst
result name=response numFound=63 start=0 maxScore=1.0
/result
lst name=facet_counts
lst name=facet_queries/
lst name=facet_fields/
lst name=facet_dates
lst name=bday
int name=1976-07-01T00:00:00Z0/int
int name=1976-07-02T00:00:00Z0/int
int name=1976-07-03T00:00:00Z2/int
int name=1976-07-04T00:00:00Z2/int
int name=1976-07-05T00:00:00Z2/int
int name=1976-07-06T00:00:00Z0/int
int name=1976-07-07T00:00:00Z0/int
int name=1976-07-08T00:00:00Z0/int
int name=1976-07-09T00:00:00Z0/int
int name=1976-07-10T00:00:00Z0/int
int name=1976-07-11T00:00:00Z0/int
int name=1976-07-12T00:00:00Z1/int
int name=1976-07-13T00:00:00Z1/int
int name=1976-07-14T00:00:00Z0/int
int name=1976-07-15T00:00:00Z2/int
int name=1976-07-16T00:00:00Z0/int
int name=1976-07-17T00:00:00Z0/int
int name=1976-07-18T00:00:00Z0/int
int name=1976-07-19T00:00:00Z0/int
int name=1976-07-20T00:00:00Z0/int
int name=1976-07-21T00:00:00Z1/int
int name=1976-07-22T00:00:00Z0/int
int name=1976-07-23T00:00:00Z0/int
int name=1976-07-24T00:00:00Z0/int
int name=1976-07-25T00:00:00Z0/int
int name=1976-07-26T00:00:00Z0/int
int name=1976-07-27T00:00:00Z0/int
int name=1976-07-28T00:00:00Z0/int
int name=1976-07-29T00:00:00Z0/int
int name=1976-07-30T00:00:00Z1/int
int name=1976-07-31T00:00:00Z0/int
str
[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-6252) Simplify UnInvertedField#getUnInvertedField synchronization module
[ https://issues.apache.org/jira/browse/SOLR-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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] [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] [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-tabpanelfocusedCommentId=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] [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-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] [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-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
