[jira] [Created] (SOLR-13732) Always traces requests contain configured header key
Cao Manh Dat created SOLR-13732:
---
Summary: Always traces requests contain configured header key
Key: SOLR-13732
URL: https://issues.apache.org/jira/browse/SOLR-13732
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Cao Manh Dat
Assignee: Cao Manh Dat
Sometimes, users want to always trace requests contains {{special}} header
(ignoring sampling rate). For example traced request comes from other backend
services.
Users should be able to do that by setting a {{ClusterProperty}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13510) Intermittent 401's for internode requests with basicauth enabled
[
https://issues.apache.org/jira/browse/SOLR-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915553#comment-16915553
]
Cao Manh Dat commented on SOLR-13510:
-
Hi [~sjwoodard] I kinda think this problem relate to TLOG/PULL replicas with
basicauth enabled. Can you open a new issue and provide steps to reproduce your
problem?
> Intermittent 401's for internode requests with basicauth enabled
>
>
> Key: SOLR-13510
> URL: https://issues.apache.org/jira/browse/SOLR-13510
> Project: Solr
> Issue Type: Bug
> Components: Authentication
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2, 8.1.2
>
> Attachments: SOLR-13510.patch
>
>
> We recently got a bug report on the mailing list:
> {quote}
> On Solr 8.1.1, using our previously working security.json, running queries
> (through the admin UI currently) I non-deterministically get 401 responses
> on queries when a collection has more than 1 shard. Increasing the number
> of shards in the collection makes the errors more likely.
> {
> "responseHeader":{
> "zkConnected":true,
> "status":401,
> "QTime":30,
> "params":{
> "q":"*:*",
> "_":"1559474550365"}},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
> "root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
> require authentication\n\n\n",
> "code":401}}
> {quote}
> The reporter (credit to Colvin Cowie) also gives reproduction steps:
> {quote}
># Extract solr 8.1.1.
># bin\solr start -e cloud
> 1 node / [default port] / [default collection name] / 4 shards / 1
> replica / [_default configuration]
># server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
> /security.json
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{ "name": "all", "role": "admin"} ],
> "user-role": {"solradmin": "admin"}
> }
> }
> {quote}
> (Minor edits for conciseness)
> I'm able to reproduce this bug as well. Other auth issues (SOLR-13472) look
> like they're impacted by the topography of the collection and cluster. But
> this doesn't seem affected by that at all (401's occur on inter-node requests
> regardless of the recipient of the initial request, and even when all nodes
> have a shard replica).
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13683) SolrJ 8.1.1 Http2SolrClient should allow customizing HTTP headers
[
https://issues.apache.org/jira/browse/SOLR-13683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907782#comment-16907782
]
Cao Manh Dat commented on SOLR-13683:
-
This one
{code}
Http2SolrClient.Builder().withHttpClient(Http2SolrClient httpClient)
{code}
is used for sharing connections pool between multiple {{Http2SolrClient}}s.
The idea here to hiding the underlying {{HttpClient}} (what if we want to
switch to different client in the future?). More over it help us preventing
access to {{HttpClient}}. Even in Solr code base right now. Manually modifying
HttpClient to change {{connectionTimeout}} and {{socketTimeout}} without going
through provided methods by Http[2]SolrClient is common. This is not good and
sometime quite confusing for knowing exact params are used by underlying
HttpClient.
{quote}
Http2SolrClient does not allow configuring custom headers
{quote}
It does, if you want to set basic auth for a specific request uses
{{SolrRequest#setBasicAuthCredentials}}.
If you want to set basic auth for all requests sent by {{Http2SolrClient}} uses
{{PreemptiveBasicAuthClientBuilderFactory#setup()}}.
If {{PreemptiveBasicAuthClientBuilderFactory}} behaviour is not suitable for
you, you can always add your own custom headers by using
{{Http2SolrClient#addListenerFactory()}}.
> SolrJ 8.1.1 Http2SolrClient should allow customizing HTTP headers
> -
>
> Key: SOLR-13683
> URL: https://issues.apache.org/jira/browse/SOLR-13683
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: clients - java
>Affects Versions: 8.1.1
>Reporter: Niranjan Nanda
>Priority: Minor
>
> Currently {{Http2SolrClient}} does not allow configuring custom headers. For
> example, how to pass Basic Auth headers? It should expose some builder APIs
> to pass such headers.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13486) race condition between leader's "replay on startup" and non-leader's "recover from leader" can leave replicas out of sync (TestCloudConsistency)
[
https://issues.apache.org/jira/browse/SOLR-13486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887575#comment-16887575
]
Cao Manh Dat commented on SOLR-13486:
-
Thanks [~hossman] it is indeed a serious problem. Should we introduce a
lock/flag to prevent /replication if tlog replay is not finished?
([~shalinmangar] wdyt?)
> race condition between leader's "replay on startup" and non-leader's "recover
> from leader" can leave replicas out of sync (TestCloudConsistency)
>
>
> Key: SOLR-13486
> URL: https://issues.apache.org/jira/browse/SOLR-13486
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
>Priority: Major
> Attachments:
> apache_Lucene-Solr-BadApples-NightlyTests-master_61.log.txt.gz,
> apache_Lucene-Solr-BadApples-Tests-8.x_102.log.txt.gz
>
>
> I've been investigating some jenkins failures from TestCloudConsistency,
> which at first glance suggest a problem w/replica(s) recovering after a
> network partition from the leader - but in digging into the logs the root
> cause acturally seems to be a thread race conditions when a replica (the
> leader) is first registered...
> * The {{ZkContainer.registerInZk(...)}} method (which is called by
> {{CoreContainer.registerCore(...)}} & {{CoreContainer.load()}}) is typically
> run in a background thread (via the {{ZkContainer.coreZkRegister}}
> ExecutorService)
> * {{ZkContainer.registerInZk(...)}} delegates to
> {{ZKController.register(...)}} which is ultimately responsible for checking
> if there are any "old" tlogs on disk, and if so handling the "Replaying tlog
> for during startup" logic
> * Because this happens in a background thread, other logic/requests can be
> handled by this core/replica in the meantime - before it starts (or while in
> the middle of) replaying the tlogs
> ** Notably: *leader's that have not yet replayed tlogs on startup will
> erroneously respond to RTG / Fingerprint / PeerSync requests from other
> replicas w/incomplete data*
> ...In general, it seems scary / fishy to me that a replica can (aparently)
> become *ACTIVE* before it's finished it's {{registerInZk}} + "Replaying tlog
> ... during startup" logic ... particularly since this can happen even for
> replicas that are/become leaders. It seems like this could potentially cause
> a whole host of problems, only one of which manifests in this particular test
> failure:
> * *BEFORE* replicaX's "coreZkRegister" thread reaches the "Replaying tlog
> ... during startup" check:
> ** replicaX can recognize (via zk terms) that it should be the leader(X)
> ** this leaderX can then instruct some other replicaY to recover from it
> ** replicaY can send RTG / PeerSync / FetchIndex requests to the leaderX
> (either on it's own volition, or because it was instructed to by leaderX) in
> an attempt to recover
> *** the responses to these recovery requests will not include updates in the
> tlog files that existed on leaderX prior to startup that hvae not yet been
> replayed
> * *AFTER* replicaY has finished it's recovery, leaderX's "Replaying tlog ...
> during startup" can finish
> ** replicaY now thinks it is in sync with leaderX, but leaderX has
> (replayed) updates the other replicas know nothing about
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13616) Possible racecondition/deadlock between collection DELETE and PrepRecovery ? (TestPolicyCloud failures)
[
https://issues.apache.org/jira/browse/SOLR-13616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881792#comment-16881792
]
Cao Manh Dat commented on SOLR-13616:
-
I'm not sure we should change the {{waitForState}} logic to rethrow Exceptions
or revert back PrepRecoveryOp to its previous version (before SOLR-12801).
Need more thought about it.
> Possible racecondition/deadlock between collection DELETE and PrepRecovery ?
> (TestPolicyCloud failures)
> ---
>
> Key: SOLR-13616
> URL: https://issues.apache.org/jira/browse/SOLR-13616
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Priority: Major
> Attachments: SOLR-13616.test-incomplete.patch,
> thetaphi_Lucene-Solr-master-Linux_24358.log.txt
>
>
> Based on some recent jenkins failures in TestPolicyCloud, I suspect there is
> a possible deadlock condition when attempting to delete a collection while
> recovery is in progress.
> I haven't been able to identify exactly where/why/how the problem occurs, but
> it does not appear to be a test specific problem, and seems like it could
> potentially affect anyone unlucky enough to issue poorly timed DELETE.
> Details to follow in comments...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13616) Possible racecondition/deadlock between collection DELETE and PrepRecovery ? (TestPolicyCloud failures)
[
https://issues.apache.org/jira/browse/SOLR-13616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881790#comment-16881790
]
Cao Manh Dat commented on SOLR-13616:
-
Hi [~hossman], thanks a lot for taking a look at this failure. Your analysis
make tracking down things much faster.
I think the problem here belongs to {{ZkStateReader}} (or the way we use it in
{{PreRecoveryOp}}).
In {{PreRecoveryOp}} (this call was added/refactored in SOLR-12801)
{code}
coreContainer.getZkController().getZkStateReader().waitForState(collectionName,
conflictWaitMs, TimeUnit.MILLISECONDS, (n, c) -> {
try (SolrCore core = coreContainer.getCore(cname)) {
if (core == null) throw new
SolrException(SolrException.ErrorCode.BAD_REQUEST, "core not found:" + cname);
...
{code}
So the idea here is we throw an SolrException whenever the core (leader) is not
found, so the method will terminate and return response to the replica which is
doing recovery.
But ZkStateReader will never throw any exception happened in Watcher
(CollectionStatePredicate) to the upper level, it just log out the exception
and continue.
https://github.com/apache/lucene-solr/blob/fb30ded6436a577af86e5db201eed01170102a97/solr/solrj/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L2045
Furthermore that exception watcher never get removed from the list of watchers,
so whenever clusterstate get changed, this method will get invoked -> that is
the reason why that {{"Error on calling watcher"}} appeared multiple times.
> Possible racecondition/deadlock between collection DELETE and PrepRecovery ?
> (TestPolicyCloud failures)
> ---
>
> Key: SOLR-13616
> URL: https://issues.apache.org/jira/browse/SOLR-13616
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Priority: Major
> Attachments: SOLR-13616.test-incomplete.patch,
> thetaphi_Lucene-Solr-master-Linux_24358.log.txt
>
>
> Based on some recent jenkins failures in TestPolicyCloud, I suspect there is
> a possible deadlock condition when attempting to delete a collection while
> recovery is in progress.
> I haven't been able to identify exactly where/why/how the problem occurs, but
> it does not appear to be a test specific problem, and seems like it could
> potentially affect anyone unlucky enough to issue poorly timed DELETE.
> Details to follow in comments...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13532) Unable to start core recovery due to timeout in ping request
[
https://issues.apache.org/jira/browse/SOLR-13532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881673#comment-16881673
]
Cao Manh Dat commented on SOLR-13532:
-
Thanks [~hossman] for very carefully take a look at this problem. I think the
general idea to remove all hard configured timeout is a good thing to do.
+1 for commit.
> Unable to start core recovery due to timeout in ping request
>
>
> Key: SOLR-13532
> URL: https://issues.apache.org/jira/browse/SOLR-13532
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 7.6
>Reporter: Suril Shah
>Priority: Major
> Attachments: SOLR-13532.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Discovered following issue with the core recovery:
> * Core recovery is not being initialized and throwing following exception
> message :
> {code:java}
> 2019-06-07 00:53:12.436 INFO
> (recoveryExecutor-4-thread-1-processing-n::8983_solr
> x:_shard41_replica_n2777 c: s:shard41
> r:core_node2778) x:_shard41_replica_n2777
> o.a.s.c.RecoveryStrategy Failed to connect leader http://:8983/solr
> on recovery, try again{code}
> * Above error occurs when ping request takes time more than a timeout period
> which is hard-coded to one second in solr source code. However In a general
> production setting it is common to have ping time more than one second,
> hence, the core recovery never starts and exception is thrown.
> * Also the other major concern is that this exception is logged as an info
> message, hence it is very difficult to identify the error if info logging is
> not enabled.
> * Please refer to following code snippet from the [source
> code|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L789-L803]
> to understand the above issue.
> {code:java}
> try (HttpSolrClient httpSolrClient = new
> HttpSolrClient.Builder(leaderReplica.getCoreUrl())
> .withSocketTimeout(1000)
> .withConnectionTimeout(1000)
>
> .withHttpClient(cc.getUpdateShardHandler().getRecoveryOnlyHttpClient())
> .build()) {
> SolrPingResponse resp = httpSolrClient.ping();
> return leaderReplica;
> } catch (IOException e) {
> log.info("Failed to connect leader {} on recovery, try again",
> leaderReplica.getBaseUrl());
> Thread.sleep(500);
> } catch (Exception e) {
> if (e.getCause() instanceof IOException) {
> log.info("Failed to connect leader {} on recovery, try again",
> leaderReplica.getBaseUrl());
> Thread.sleep(500);
> } else {
> return leaderReplica;
> }
> }
> {code}
> The above issue will have high impact in production level clusters, since
> cores not being able to recover may lead to data loss.
> Following improvements would be really helpful:
> 1. The [timeout for ping
> request|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L790-L791]
> in *RecoveryStrategy.java* should be configurable and the defaults set to
> high values like 15seconds.
> 2. The exception message in [line
> 797|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L797]
> and [line
> 801|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L801]
> in *RecoveryStrategy.java* should be logged as *error* messages instead of
> *info* messages
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13608) Incremental backup for Solr
[
https://issues.apache.org/jira/browse/SOLR-13608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-13608:
Description:
Currently every call to backup API requires backup the whole index with
different backupName. This is very costly and nearly useless in case of large
frequent change indexes.
Since index files of Lucene are written one only, they also contains the
informantion about checksum of files. Then we can rely on these to support
incremental backup -- only upload files that do not present in the repository.
The design for this issue will be like this
* Adding another parameter named {{incremental}} to backup API.
* Adding new methods to {{BackupRepository}}, like compute checksum,
deletefiles..
* {{SnapShooter}} will skip uploading files from local if file in repository
matches in checksum and length.
* Segments_N will be copied last to guarantee that even the backup process get
interrupted in the middle, the old backup will still can be used.
* We only keep the last {{IndexCommit}} therefore after uploading Segments_N
successfully, any file does not needed for the last {{IndexCommit}} will be
deleted. We will try to improve this situation in another issue.
* Any files in ZK will be re-uploaded
** The ZK files coressponds first backup will be stored in same location as
today (to maintain backward compatibility)
** On subsequent backups ZK files will be stored in folder {{gen-ith}}
was:
Currently every call to backup API requires backup the whole index with
different backupName. This is very costly and nearly useless in case of large
frequent change indexes.
Since index files of Lucene are written one only, they also contains the
informantion about checksum of files. Then we can rely on these to support
incremental backup -- only upload files that do not present in the repository.
The design for this issue will be like this
* Adding another parameter named {{incremental}} to backup API.
* Adding new methods to {{BackupRepository}}, like compute checksum,
deletefiles..
* {{UnsupportedOperationException}} on methods).
* {{SnapShooter}} will skip uploading files from local if file in repository
matches in checksum and length.
* Segments_N will be copied last to guarantee that even the backup process get
interrupted in the middle, the old backup will still can be used.
* We only keep the last {{IndexCommit}} therefore after uploading Segments_N
successfully, any file does not needed for the last {{IndexCommit}} will be
deleted. We will try to improve this situation in another issue.
* Any files in ZK will be re-uploaded
** The ZK files coressponds first backup will be stored in same location as
today (to maintain backward compatibility)
** On subsequent backups ZK files will be stored in folder {{gen-ith}}
> Incremental backup for Solr
> ---
>
> Key: SOLR-13608
> URL: https://issues.apache.org/jira/browse/SOLR-13608
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently every call to backup API requires backup the whole index with
> different backupName. This is very costly and nearly useless in case of large
> frequent change indexes.
> Since index files of Lucene are written one only, they also contains the
> informantion about checksum of files. Then we can rely on these to support
> incremental backup -- only upload files that do not present in the repository.
> The design for this issue will be like this
> * Adding another parameter named {{incremental}} to backup API.
> * Adding new methods to {{BackupRepository}}, like compute checksum,
> deletefiles..
> * {{SnapShooter}} will skip uploading files from local if file in repository
> matches in checksum and length.
> * Segments_N will be copied last to guarantee that even the backup process
> get interrupted in the middle, the old backup will still can be used.
> * We only keep the last {{IndexCommit}} therefore after uploading Segments_N
> successfully, any file does not needed for the last {{IndexCommit}} will be
> deleted. We will try to improve this situation in another issue.
> * Any files in ZK will be re-uploaded
> ** The ZK files coressponds first backup will be stored in same location as
> today (to maintain backward compatibility)
> ** On subsequent backups ZK files will be stored in folder {{gen-ith}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13608) Incremental backup for Solr
[
https://issues.apache.org/jira/browse/SOLR-13608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-13608:
Description:
Currently every call to backup API requires backup the whole index with
different backupName. This is very costly and nearly useless in case of large
frequent change indexes.
Since index files of Lucene are written one only, they also contains the
informantion about checksum of files. Then we can rely on these to support
incremental backup -- only upload files that do not present in the repository.
The design for this issue will be like this
* Adding another parameter named {{incremental}} to backup API.
* Adding new methods to {{BackupRepository}}, like compute checksum,
deletefiles..
* {{UnsupportedOperationException}} on methods).
* {{SnapShooter}} will skip uploading files from local if file in repository
matches in checksum and length.
* Segments_N will be copied last to guarantee that even the backup process get
interrupted in the middle, the old backup will still can be used.
* We only keep the last {{IndexCommit}} therefore after uploading Segments_N
successfully, any file does not needed for the last {{IndexCommit}} will be
deleted. We will try to improve this situation in another issue.
* Any files in ZK will be re-uploaded
** The ZK files coressponds first backup will be stored in same location as
today (to maintain backward compatibility)
** On subsequent backups ZK files will be stored in folder {{gen-ith}}
was:
Currently every call to backup API requires backup the whole index with
different backupName. This is very costly and nearly useless in case of large
frequent change indexes.
Since index files of Lucene are written one only, they also contains the
informantion about checksum of files. Then we can rely on these to support
incremental backup -- only upload files that do not present in the repository.
The design for this issue will be like this
* Adding another parameter named {{incremental}} to backup API.
* Adding new methods to {{BackupRepository}}, unfortunately we still uses Java
8 for branch_8_x therefore we can't use {{default method}}. Therefore if
someone already have a customised version of BackupRepository, they need to
recompile their code. (Simply by throw {{UnsupportedOperationException}} on
methods).
* {{SnapShooter}} will skip uploading files from local if file in repository
matches in checksum and length.
* Segments_N will be copied last to guarantee that even the backup process get
interrupted in the middle, the old backup will still can be used.
* We only keep the last {{IndexCommit}} therefore after uploading Segments_N
successfully, any file does not needed for the last {{IndexCommit}} will be
deleted. We will try to improve this situation in another issue.
* Any files in ZK will be re-uploaded
** The ZK files coressponds first backup will be stored in same location as
today (to maintain backward compatibility)
** On subsequent backups ZK files will be stored in folder {{gen-ith}}
> Incremental backup for Solr
> ---
>
> Key: SOLR-13608
> URL: https://issues.apache.org/jira/browse/SOLR-13608
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
>
> Currently every call to backup API requires backup the whole index with
> different backupName. This is very costly and nearly useless in case of large
> frequent change indexes.
> Since index files of Lucene are written one only, they also contains the
> informantion about checksum of files. Then we can rely on these to support
> incremental backup -- only upload files that do not present in the repository.
> The design for this issue will be like this
> * Adding another parameter named {{incremental}} to backup API.
> * Adding new methods to {{BackupRepository}}, like compute checksum,
> deletefiles..
> * {{UnsupportedOperationException}} on methods).
> * {{SnapShooter}} will skip uploading files from local if file in repository
> matches in checksum and length.
> * Segments_N will be copied last to guarantee that even the backup process
> get interrupted in the middle, the old backup will still can be used.
> * We only keep the last {{IndexCommit}} therefore after uploading Segments_N
> successfully, any file does not needed for the last {{IndexCommit}} will be
> deleted. We will try to improve this situation in another issue.
> * Any files in ZK will be re-uploaded
> ** The ZK files coressponds first backup will be stored in same location as
> today (to maintain backward compatibility)
> ** On subsequent backups ZK files will be stored in folder {{gen-ith}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SOLR-13608) Incremental backup for Solr
Cao Manh Dat created SOLR-13608:
---
Summary: Incremental backup for Solr
Key: SOLR-13608
URL: https://issues.apache.org/jira/browse/SOLR-13608
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Cao Manh Dat
Assignee: Cao Manh Dat
Currently every call to backup API requires backup the whole index with
different backupName. This is very costly and nearly useless in case of large
frequent change indexes.
Since index files of Lucene are written one only, they also contains the
informantion about checksum of files. Then we can rely on these to support
incremental backup -- only upload files that do not present in the repository.
The design for this issue will be like this
* Adding another parameter named {{incremental}} to backup API.
* Adding new methods to {{BackupRepository}}, unfortunately we still uses Java
8 for branch_8_x therefore we can't use {{default method}}. Therefore if
someone already have a customised version of BackupRepository, they need to
recompile their code. (Simply by throw {{UnsupportedOperationException}} on
methods).
* {{SnapShooter}} will skip uploading files from local if file in repository
matches in checksum and length.
* Segments_N will be copied last to guarantee that even the backup process get
interrupted in the middle, the old backup will still can be used.
* We only keep the last {{IndexCommit}} therefore after uploading Segments_N
successfully, any file does not needed for the last {{IndexCommit}} will be
deleted. We will try to improve this situation in another issue.
* Any files in ZK will be re-uploaded
** The ZK files coressponds first backup will be stored in same location as
today (to maintain backward compatibility)
** On subsequent backups ZK files will be stored in folder {{gen-ith}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13583) Impossible to delete a collection with the same name as an existing alias
[
https://issues.apache.org/jira/browse/SOLR-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16878278#comment-16878278
]
Cao Manh Dat commented on SOLR-13583:
-
[~ab] Should it be closed now?
> Impossible to delete a collection with the same name as an existing alias
> -
>
> Key: SOLR-13583
> URL: https://issues.apache.org/jira/browse/SOLR-13583
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.1, 8.1.1
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Blocker
> Fix For: 8.1.2
>
> Attachments: SOLR-13583.patch, SOLR-13583.patch
>
>
> SOLR-13262 changed the behavior of most collection admin commands so that
> they always resolve aliases by default. In most cases this is desireable
> behavior but it also prevents executing commands on the collections that have
> the same name as an existing alias (which usually points to a different
> collection).
> This behavior also breaks the REINDEXCOLLECTION command with
> {{removeSource=true,}} which can also lead to data loss.
> This issue can be resolved by adding either an opt-in or opt-out flag to the
> collection admin commands that specifies whether the command should attempt
> resolving the provided name as an alias first. From the point of view of ease
> of use this could be an opt-out option, from the point of view of data safety
> this could be an opt-in option.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13413) jetty IdleTimeout bugs with Http2SolrClient, cause sprious timeouts on intranode requests
[ https://issues.apache.org/jira/browse/SOLR-13413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16873213#comment-16873213 ] Cao Manh Dat commented on SOLR-13413: - Thanks [~dsmiley][~ivera] > jetty IdleTimeout bugs with Http2SolrClient, cause sprious timeouts on > intranode requests > - > > Key: SOLR-13413 > URL: https://issues.apache.org/jira/browse/SOLR-13413 > Project: Solr > Issue Type: Bug >Affects Versions: 8.0 >Reporter: Hoss Man >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2, 8.1.2 > > Attachments: SOLR-13413.patch, > nocommit_TestDistributedStatsComponentCardinality_trivial-no-http2.patch > > > There is evidence in some recent jenkins failures that we may have some manor > of bug in our http2 client/server code that can cause intra-node query > requests to stall / timeout non-reproducibly. > In at least one known case, forcing the jetty & SolrClients used in the test > to use http1.1, seems to prevent these test failures. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13570) Unable to control timeout for requests from Overseer to other nodes
[
https://issues.apache.org/jira/browse/SOLR-13570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-13570:
Attachment: SOLR-13570.patch
> Unable to control timeout for requests from Overseer to other nodes
> ---
>
> Key: SOLR-13570
> URL: https://issues.apache.org/jira/browse/SOLR-13570
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-13570.patch
>
>
> All Overseer requests uses {{UpdateShardHandler.httpClient}}, so in theory we
> should be able to control timeout by setting {{distribUpdateConnTimeout}} in
> {{solr.xml}}. Since HttpClient was configured with timeout from
> {{distribUpdateConnTimeout}}
> It used to work but since SOLR-11004, we hardcoded the timeout in
> SolrClientBuilder.socketTimeoutMillis = 12, therefore any HttpSolrClient
> without specify {{withSocketTimeout()}} will have timeout = 12. We
> basically ignore the timeout set to HttpClient.
> For long async tasks like BACKUP/RESTORE, 2 minutes is not enough and users
> will frequently encountering timeout on these calls.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13570) Unable to control timeout for requests from Overseer to other nodes
[
https://issues.apache.org/jira/browse/SOLR-13570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870551#comment-16870551
]
Cao Manh Dat commented on SOLR-13570:
-
This problem can be solved by removing all call in *Cmd
{code}
ocmh.shardHandlerFactory.getShardHandler(ocmh.overseer.getCoreContainer().getUpdateShardHandler().getDefaultHttpClient())
{code}
which is using Apache HttpClient by
{{ocmh.shardHandlerFactory.getShardHandler()}} to use {{Http2SolrClient}}.
It makes sense now since we are moved to Http/2 so we don't have to use a
dedicated client for this kind of tasks. What do you think
[~markrmil...@gmail.com]?
> Unable to control timeout for requests from Overseer to other nodes
> ---
>
> Key: SOLR-13570
> URL: https://issues.apache.org/jira/browse/SOLR-13570
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
>
> All Overseer requests uses {{UpdateShardHandler.httpClient}}, so in theory we
> should be able to control timeout by setting {{distribUpdateConnTimeout}} in
> {{solr.xml}}. Since HttpClient was configured with timeout from
> {{distribUpdateConnTimeout}}
> It used to work but since SOLR-11004, we hardcoded the timeout in
> SolrClientBuilder.socketTimeoutMillis = 12, therefore any HttpSolrClient
> without specify {{withSocketTimeout()}} will have timeout = 12. We
> basically ignore the timeout set to HttpClient.
> For long async tasks like BACKUP/RESTORE, 2 minutes is not enough and users
> will frequently encountering timeout on these calls.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13570) Unable to control timeout for requests from Overseer to other nodes
Cao Manh Dat created SOLR-13570:
---
Summary: Unable to control timeout for requests from Overseer to
other nodes
Key: SOLR-13570
URL: https://issues.apache.org/jira/browse/SOLR-13570
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Cao Manh Dat
Assignee: Cao Manh Dat
All Overseer requests uses {{UpdateShardHandler.httpClient}}, so in theory we
should be able to control timeout by setting {{distribUpdateConnTimeout}} in
{{solr.xml}}. Since HttpClient was configured with timeout from
{{distribUpdateConnTimeout}}
It used to work but since SOLR-11004, we hardcoded the timeout in
SolrClientBuilder.socketTimeoutMillis = 12, therefore any HttpSolrClient
without specify {{withSocketTimeout()}} will have timeout = 12. We
basically ignore the timeout set to HttpClient.
For long async tasks like BACKUP/RESTORE, 2 minutes is not enough and users
will frequently encountering timeout on these calls.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12988) Skip running tests with SSL on Java 11 to 11.0.2
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869251#comment-16869251
]
Cao Manh Dat commented on SOLR-12988:
-
Kinda shame, thanks Hoss!
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-12988.patch, SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should skip running
> tests with SSL on Java 11 to 11.0.2.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13532) Unable to start core recovery due to timeout in ping request
[
https://issues.apache.org/jira/browse/SOLR-13532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868432#comment-16868432
]
Cao Manh Dat commented on SOLR-13532:
-
+1 for your changes [~surilshah]. That totally makes sense to me.
> Unable to start core recovery due to timeout in ping request
>
>
> Key: SOLR-13532
> URL: https://issues.apache.org/jira/browse/SOLR-13532
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 7.6
>Reporter: Suril Shah
>Priority: Major
>
> Discovered following issue with the core recovery:
> * Core recovery is not being initialized and throwing following exception
> message :
> {code:java}
> 2019-06-07 00:53:12.436 INFO
> (recoveryExecutor-4-thread-1-processing-n::8983_solr
> x:_shard41_replica_n2777 c: s:shard41
> r:core_node2778) x:_shard41_replica_n2777
> o.a.s.c.RecoveryStrategy Failed to connect leader http://:8983/solr
> on recovery, try again{code}
> * Above error occurs when ping request takes time more than a timeout period
> which is hard-coded to one second in solr source code. However In a general
> production setting it is common to have ping time more than one second,
> hence, the core recovery never starts and exception is thrown.
> * Also the other major concern is that this exception is logged as an info
> message, hence it is very difficult to identify the error if info logging is
> not enabled.
> * Please refer to following code snippet from the [source
> code|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L789-L803]
> to understand the above issue.
> {code:java}
> try (HttpSolrClient httpSolrClient = new
> HttpSolrClient.Builder(leaderReplica.getCoreUrl())
> .withSocketTimeout(1000)
> .withConnectionTimeout(1000)
>
> .withHttpClient(cc.getUpdateShardHandler().getRecoveryOnlyHttpClient())
> .build()) {
> SolrPingResponse resp = httpSolrClient.ping();
> return leaderReplica;
> } catch (IOException e) {
> log.info("Failed to connect leader {} on recovery, try again",
> leaderReplica.getBaseUrl());
> Thread.sleep(500);
> } catch (Exception e) {
> if (e.getCause() instanceof IOException) {
> log.info("Failed to connect leader {} on recovery, try again",
> leaderReplica.getBaseUrl());
> Thread.sleep(500);
> } else {
> return leaderReplica;
> }
> }
> {code}
> The above issue will have high impact in production level clusters, since
> cores not being able to recover may lead to data loss.
> Following improvements would be really helpful:
> 1. The [timeout for ping
> request|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L790-L791]
> in *RecoveryStrategy.java* should be configurable and the defaults set to
> high values like 15seconds.
> 2. The exception message in [line
> 797|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L797]
> and [line
> 801|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L801]
> in *RecoveryStrategy.java* should be logged as *error* messages instead of
> *info* messages
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13532) Unable to start core recovery due to timeout in ping request
[
https://issues.apache.org/jira/browse/SOLR-13532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868432#comment-16868432
]
Cao Manh Dat edited comment on SOLR-13532 at 6/20/19 10:32 AM:
---
+1 for your changes [~surilshah]. That totally makes sense to me. Would you
like to upload a patch?
was (Author: caomanhdat):
+1 for your changes [~surilshah]. That totally makes sense to me.
> Unable to start core recovery due to timeout in ping request
>
>
> Key: SOLR-13532
> URL: https://issues.apache.org/jira/browse/SOLR-13532
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 7.6
>Reporter: Suril Shah
>Priority: Major
>
> Discovered following issue with the core recovery:
> * Core recovery is not being initialized and throwing following exception
> message :
> {code:java}
> 2019-06-07 00:53:12.436 INFO
> (recoveryExecutor-4-thread-1-processing-n::8983_solr
> x:_shard41_replica_n2777 c: s:shard41
> r:core_node2778) x:_shard41_replica_n2777
> o.a.s.c.RecoveryStrategy Failed to connect leader http://:8983/solr
> on recovery, try again{code}
> * Above error occurs when ping request takes time more than a timeout period
> which is hard-coded to one second in solr source code. However In a general
> production setting it is common to have ping time more than one second,
> hence, the core recovery never starts and exception is thrown.
> * Also the other major concern is that this exception is logged as an info
> message, hence it is very difficult to identify the error if info logging is
> not enabled.
> * Please refer to following code snippet from the [source
> code|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L789-L803]
> to understand the above issue.
> {code:java}
> try (HttpSolrClient httpSolrClient = new
> HttpSolrClient.Builder(leaderReplica.getCoreUrl())
> .withSocketTimeout(1000)
> .withConnectionTimeout(1000)
>
> .withHttpClient(cc.getUpdateShardHandler().getRecoveryOnlyHttpClient())
> .build()) {
> SolrPingResponse resp = httpSolrClient.ping();
> return leaderReplica;
> } catch (IOException e) {
> log.info("Failed to connect leader {} on recovery, try again",
> leaderReplica.getBaseUrl());
> Thread.sleep(500);
> } catch (Exception e) {
> if (e.getCause() instanceof IOException) {
> log.info("Failed to connect leader {} on recovery, try again",
> leaderReplica.getBaseUrl());
> Thread.sleep(500);
> } else {
> return leaderReplica;
> }
> }
> {code}
> The above issue will have high impact in production level clusters, since
> cores not being able to recover may lead to data loss.
> Following improvements would be really helpful:
> 1. The [timeout for ping
> request|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L790-L791]
> in *RecoveryStrategy.java* should be configurable and the defaults set to
> high values like 15seconds.
> 2. The exception message in [line
> 797|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L797]
> and [line
> 801|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L801]
> in *RecoveryStrategy.java* should be logged as *error* messages instead of
> *info* messages
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13523) Atomic Update results in NullPointerException
[
https://issues.apache.org/jira/browse/SOLR-13523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868429#comment-16868429
]
Cao Manh Dat commented on SOLR-13523:
-
Sure [~dsmiley], I will wait for this ticket being backported to branch_8_1
before doing release for 8_1_2
> Atomic Update results in NullPointerException
> -
>
> Key: SOLR-13523
> URL: https://issues.apache.org/jira/browse/SOLR-13523
> Project: Solr
> Issue Type: Bug
> Components: update
>Affects Versions: 8.1
> Environment: * Operating system: Win10 v1803 build 17143.766
> * Java version:
> java 11.0.1 2018-10-16 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)
> * solr-spec: 8.1.1
> * solr-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab -
> 2019-05-22 15:20:01
> * lucene-spec: 8.1.1
> * lucene-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab -
> 2019-05-22 15:15:24
>Reporter: Kieran Devlin
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-13523.patch, SOLR-13523.patch, SOLR-13523.patch,
> SOLR-13523_WIP_bug_hunt.patch, XUBrk.png, Xn1RW.png, reproduce.sh
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Partially update a document via an atomic update, when I do so, the web sever
> responds with a 500 status with the stack trace:
> {code:java}
> { "responseHeader":{ "status":500, "QTime":1}, "error":{
> "trace":"java.lang.NullPointerException\r\n\tat
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.getFieldFromHierarchy(AtomicUpdateDocumentMerger.java:301)\r\n\tat
>
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeChildDoc(AtomicUpdateDocumentMerger.java:398)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.getUpdatedDocument(DistributedUpdateProcessor.java:697)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.doVersionAdd(DistributedUpdateProcessor.java:372)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.lambda$versionAdd$0(DistributedUpdateProcessor.java:337)\r\n\tat
>
> org.apache.solr.update.VersionBucket.runWithLock(VersionBucket.java:50)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:337)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:223)\r\n\tat
>
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:475)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldNameMutatingUpdateProcessorFactory$1.processAdd(FieldNameMutatingUpdateProcessorFactory.java:75)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.AbstractDefaultValueUpdateProcessorFactory$DefaultValueUpdateProcessor.processAdd(AbstractDefaultValueUpdateProcessorFactory.java:92)\r\n\tat
>
> org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.handleAdds(JsonLoader.java:507)\r\n\tat
>
>
[jira] [Updated] (SOLR-12988) Skip running tests with SSL on Java 11 to 11.0.2
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-12988:
Attachment: (was: SOLR-12988.patch)
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-12988.patch, SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should skip running
> tests with SSL on Java 11 to 11.0.2.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12988) Skip running tests with SSL on Java 11 to 11.0.2
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-12988:
Attachment: SOLR-12988.patch
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-12988.patch, SOLR-12988.patch, SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should skip running
> tests with SSL on Java 11 to 11.0.2.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12988) Skip running tests with SSL on Java 11 to 11.0.2
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867957#comment-16867957
]
Cao Manh Dat commented on SOLR-12988:
-
{quote}
That's very suprising since java.lang.Runtime.Version didn't exist until
java9...
{quote}
Hmm, now you mention, it seems weird too me as well. But the {{ant compile}}
success at my machine with java 1.8.0_191.
{quote}
But to re-iterate: even if/once we have a "good" patch (that can be backported
to 8x) i STILL think we need to revert all of these changes, and not move
forward with any patch (or existing changes to allow SSL testing on java11)
until the jenkins boxes are running 11.0.3.
{quote}
Ok that makes sense to me, I will revert changes and let you handle this issue,
since both of us understand the problem, we just need a way to handle the test
now which it seems you will handle it properly and more stable than me.
Just a note here, since the awaitsFix of Mark 6 months ago + the enforcment of
using Java 11 on master. None tests on master were run with HTTPS. Hoping that
this issue can move fast.
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-12988.patch, SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should skip running
> tests with SSL on Java 11 to 11.0.2.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12988) Skip running tests with SSL on Java 11 to 11.0.2
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867897#comment-16867897
]
Cao Manh Dat commented on SOLR-12988:
-
[~hossman] does that most recent patch matched to your idea?
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-12988.patch, SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should skip running
> tests with SSL on Java 11 to 11.0.2.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12988) Skip running tests with SSL on Java 11 to 11.0.2
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-12988:
Attachment: SOLR-12988.patch
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-12988.patch, SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should skip running
> tests with SSL on Java 11 to 11.0.2.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12988) Skip running tests with SSL on Java 11 to 11.0.2
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867891#comment-16867891
]
Cao Manh Dat commented on SOLR-12988:
-
Hi [~hossman] I kinda think we are misunderstanding each others here.
{quote}
that doesn't even fucking compile with java8
{quote}
Firstly, I don't see any problem with compiling branch_8x on java8 locally.
Secondly, I rushed the commit to revert changes back to it used to be + minimal
checks so Jenkins will become happy. THEN we can continue doing what we should
do after discussion.
Thirdly, I quite understand your idea now, so we should call {{assumFalse()}}
in {{SSLTestConfig}} whenever SSL is enabled on Java 11 -> 11.0.2. Luckily that
it still matches with issue's name and we do not need to change issue name
(again).
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should skip running
> tests with SSL on Java 11 to 11.0.2.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12988) Skip running tests with SSL on Java 11 to 11.0.2
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-12988:
Description:
HTTPCLIENT-1967 indicates that HttpClient can't be used properly with TLSv1.3.
It caused some test failures below, therefore we should skip running tests with
SSL on Java 11 to 11.0.2.
TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of the
time when run with java11 (or java12), regardless of seed, on both master & 7x.
The nature of the problem and the way our htp stack works suggests it *may*
ultimately be a jetty bug (perhaps related to [jetty
issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
*HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
been fixed on the {{jira/http2}} branch (as of
52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
merged to master soon.
Filing this issue largely for tracking purpose, although we may also want to
use it for discussions/considerations of other backports/fixes to 7x
was:
HTTPCLIENT-1967 indicates that HttpClient can't be used properly with TLSv1.3.
It caused some test failures below, therefore we should enforce HttpClient to
uses TLSv1.2 or lower versions.
TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of the
time when run with java11 (or java12), regardless of seed, on both master & 7x.
The nature of the problem and the way our htp stack works suggests it *may*
ultimately be a jetty bug (perhaps related to [jetty
issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
*HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
been fixed on the {{jira/http2}} branch (as of
52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
merged to master soon.
Filing this issue largely for tracking purpose, although we may also want to
use it for discussions/considerations of other backports/fixes to 7x
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should skip running
> tests with SSL on Java 11 to 11.0.2.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12988) Skip running tests with SSL on Java 11 to 11.0.2
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-12988:
Summary: Skip running tests with SSL on Java 11 to 11.0.2 (was: Avoid
using TLSv1.3 for HttpClient)
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should enforce
> HttpClient to uses TLSv1.2 or lower versions.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12988) Avoid using TLSv1.3 for HttpClient
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867442#comment-16867442
]
Cao Manh Dat commented on SOLR-12988:
-
Thanks [~hossman], I kinda agree with you strategy about
{quote}
then le it fail if it's going to fail.
{quote}
But I kinda wondering what we should do with the tests? Should we enforce tests
to run in TLSv1.2 for 11 to 11.02? Since not all developers - jenkins do know
this and do the upgrade their sdk?
> Avoid using TLSv1.3 for HttpClient
> --
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should enforce
> HttpClient to uses TLSv1.2 or lower versions.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13549) Maven build fails to build Solr core tests due to missing dependency
[ https://issues.apache.org/jira/browse/SOLR-13549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867391#comment-16867391 ] Cao Manh Dat commented on SOLR-13549: - Thanks [~dancollins] > Maven build fails to build Solr core tests due to missing dependency > > > Key: SOLR-13549 > URL: https://issues.apache.org/jira/browse/SOLR-13549 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: master (9.0), 8.2 >Reporter: Daniel Collins >Priority: Minor > Fix For: master (9.0), 8.2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > If I run > ant get-maven-poms > mvn -f maven-build/pom.xml install -DskipTests > On master or branch_8x, it fails to build the Solr tests due to a dependency > on opentracing-mock. Eclipse builds fine (because it uses a single classpath > with everything in it), and not entirely sure how ant builds... > But the solr/core/ivy.xml doesn't have a dependency on opentracing-mock > (though it has all the other opentracing modules) > [https://github.com/apache/lucene-solr/pull/720] for the fix > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12988) Avoid using TLSv1.3 for HttpClient
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866833#comment-16866833
]
Cao Manh Dat edited comment on SOLR-12988 at 6/18/19 4:56 PM:
--
{code}
At some point after that, after http2 was merged to master, the nature of the
failure changed – with openjdk 11.0.2 a NEW similar looing failure caused a
similar looking stack trace from
TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName – but only on the
internode communication – NOT on the connection between the test client and the
first node.
{code}
I understand why this happened, since in beginning of branch http2, {{Jetty
client}} was used for many places. But SOLR-12081 makes some changes
(https://github.com/apache/lucene-solr/blob/2e468abecc98ffc6137fc5de2aefe8cd19cd6c8d/solr/core/src/java/org/apache/solr/cloud/api/collections/CreateCollectionCmd.java#L207).
So instead of using {{Jetty client}} we switched to {{Http Client}} in many
places on merge. I just don't want to revert Mark changes at that point of
time, since I'm not totally understand the reason of that.
But that is the reason why you saw {{the nature of the failure changed}}.
Anyway, l kinda *missed* this
{quote}
but that has been fixed in OpenJDK 11.0.3.
{quote}
If that is the case I'm good with remove the changes for enforcing HttpClient
to uses TLSv1.2 or lower versions.
If possible I will try to do that enforcement for *Java 11.0.2* or lower
versions. Does that makes sense [~hossman]?
was (Author: caomanhdat):
{code}
At some point after that, after http2 was merged to master, the nature of the
failure changed – with openjdk 11.0.2 a NEW similar looing failure caused a
similar looking stack trace from
TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName – but only on the
internode communication – NOT on the connection between the test client and the
first node.
{code}
I understand why this happened, since in beginning of branch http2, {{Jetty
client}} was used for many places. But SOLR-12081 makes some changes
(https://github.com/apache/lucene-solr/blob/2e468abecc98ffc6137fc5de2aefe8cd19cd6c8d/solr/core/src/java/org/apache/solr/cloud/api/collections/CreateCollectionCmd.java#L207).
So instead of using {{Jetty client}} we switched to {{Http Client}} in many
places on merge. I just don't want to revert Mark changes at that point of
time, since I'm not totally understand the reason of that.
But that is the reason why you saw {{the nature of the failure changed}}.
Anyway, l kinda *missed* this
{quote}
but that has been fixed in OpenJDK 11.0.3.
{quote}
If that is the case I'm good with remove the changes for enforcing HttpClient
to uses TLSv1.2 or lower versions.
If possible I will try to do that enforcement for *Java 11.0.2* or lower
versions. Does that makes sense [~hossman]
> Avoid using TLSv1.3 for HttpClient
> --
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should enforce
> HttpClient to uses TLSv1.2 or lower versions.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12988) Avoid using TLSv1.3 for HttpClient
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866833#comment-16866833
]
Cao Manh Dat edited comment on SOLR-12988 at 6/18/19 4:55 PM:
--
{code}
At some point after that, after http2 was merged to master, the nature of the
failure changed – with openjdk 11.0.2 a NEW similar looing failure caused a
similar looking stack trace from
TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName – but only on the
internode communication – NOT on the connection between the test client and the
first node.
{code}
I understand why this happened, since in beginning of branch http2, {{Jetty
client}} was used for many places. But SOLR-12081 makes some changes
(https://github.com/apache/lucene-solr/blob/2e468abecc98ffc6137fc5de2aefe8cd19cd6c8d/solr/core/src/java/org/apache/solr/cloud/api/collections/CreateCollectionCmd.java#L207).
So instead of using {{Jetty client}} we switched to {{Http Client}} in many
places on merge. I just don't want to revert Mark changes at that point of
time, since I'm not totally understand the reason of that.
But that is the reason why you saw {{the nature of the failure changed}}.
Anyway, l kinda *missed* this
{quote}
but that has been fixed in OpenJDK 11.0.3.
{quote}
If that is the case I'm good with remove the changes for enforcing HttpClient
to uses TLSv1.2 or lower versions.
If possible I will try to do that enforcement for *Java 11.0.2* or lower
versions. Does that makes sense [~hossman]
was (Author: caomanhdat):
{code}
At some point after that, after http2 was merged to master, the nature of the
failure changed – with openjdk 11.0.2 a NEW similar looing failure caused a
similar looking stack trace from
TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName – but only on the
internode communication – NOT on the connection between the test client and the
first node.
{code}
I understand why this happened, since in branch http2 we used to use {{Jetty
client}} for many places. But SOLR-12081 makes some changes
(https://github.com/apache/lucene-solr/blob/2e468abecc98ffc6137fc5de2aefe8cd19cd6c8d/solr/core/src/java/org/apache/solr/cloud/api/collections/CreateCollectionCmd.java#L207).
So instead of using {{Jetty client}} we switched to {{Http Client}}. I just
don't want to revert Mark changes at that point of time, since I'm not totally
understand the reason of that.
But that is the reason why you saw {{the nature of the failure changed}}.
Anyway, l kinda *missed* this
{quote}
but that has been fixed in OpenJDK 11.0.3.
{quote}
If that is the case I'm good with remove the changes for enforcing HttpClient
to uses TLSv1.2 or lower versions.
If possible I will try to do that enforcement for *Java 11.0.2* or lower
versions. Does that makes sense [~hossman]
> Avoid using TLSv1.3 for HttpClient
> --
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should enforce
> HttpClient to uses TLSv1.2 or lower versions.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12988) Avoid using TLSv1.3 for HttpClient
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866833#comment-16866833
]
Cao Manh Dat commented on SOLR-12988:
-
{code}
At some point after that, after http2 was merged to master, the nature of the
failure changed – with openjdk 11.0.2 a NEW similar looing failure caused a
similar looking stack trace from
TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName – but only on the
internode communication – NOT on the connection between the test client and the
first node.
{code}
I understand why this happened, since in branch http2 we used to use {{Jetty
client}} for many places. But SOLR-12081 makes some changes
(https://github.com/apache/lucene-solr/blob/2e468abecc98ffc6137fc5de2aefe8cd19cd6c8d/solr/core/src/java/org/apache/solr/cloud/api/collections/CreateCollectionCmd.java#L207).
So instead of using {{Jetty client}} we switched to {{Http Client}}. I just
don't want to revert Mark changes at that point of time, since I'm not totally
understand the reason of that.
But that is the reason why you saw {{the nature of the failure changed}}.
Anyway, l kinda *missed* this
{quote}
but that has been fixed in OpenJDK 11.0.3.
{quote}
If that is the case I'm good with remove the changes for enforcing HttpClient
to uses TLSv1.2 or lower versions.
If possible I will try to do that enforcement for *Java 11.0.2* or lower
versions. Does that makes sense [~hossman]
> Avoid using TLSv1.3 for HttpClient
> --
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should enforce
> HttpClient to uses TLSv1.2 or lower versions.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12988) Avoid using TLSv1.3 for HttpClient
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-12988:
Description:
HTTPCLIENT-1967 indicates that HttpClient can't be used properly with TLSv1.3.
It caused some test failures below, therefore we should enforce HttpClient to
uses TLSv1.2 or lower versions.
TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of the
time when run with java11 (or java12), regardless of seed, on both master & 7x.
The nature of the problem and the way our htp stack works suggests it *may*
ultimately be a jetty bug (perhaps related to [jetty
issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
*HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
been fixed on the {{jira/http2}} branch (as of
52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
merged to master soon.
Filing this issue largely for tracking purpose, although we may also want to
use it for discussions/considerations of other backports/fixes to 7x
was:
HTTPCLIENT-1967 indicates that HttpClient can't be used properly with TLSv1.3.
It caused some test failures below, we should enforce HttpClient to uses
TLSv1.2
TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of the
time when run with java11 (or java12), regardless of seed, on both master & 7x.
The nature of the problem and the way our htp stack works suggests it *may*
ultimately be a jetty bug (perhaps related to [jetty
issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
*HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
been fixed on the {{jira/http2}} branch (as of
52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
merged to master soon.
Filing this issue largely for tracking purpose, although we may also want to
use it for discussions/considerations of other backports/fixes to 7x
> Avoid using TLSv1.3 for HttpClient
> --
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should enforce
> HttpClient to uses TLSv1.2 or lower versions.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12988) Avoid using TLSv1.3 for HttpClient
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-12988:
Summary: Avoid using TLSv1.3 for HttpClient (was: Enforce using TLSv1.2 or
lower TLS versions for HttpClient)
> Avoid using TLSv1.3 for HttpClient
> --
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, we should enforce HttpClient to
> uses TLSv1.2
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12988) Enforce using TLSv1.2 or lower TLS versions for HttpClient
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-12988:
Summary: Enforce using TLSv1.2 or lower TLS versions for HttpClient (was:
Enforce using TLSv1.2 for HttpClient)
> Enforce using TLSv1.2 or lower TLS versions for HttpClient
> --
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, we should enforce HttpClient to
> uses TLSv1.2
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12988) Enforce using TLSv1.2 for HttpClient
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-12988:
Description:
HTTPCLIENT-1967 indicates that HttpClient can't be used properly with TLSv1.3.
It caused some test failures below, we should enforce HttpClient to uses
TLSv1.2
TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of the
time when run with java11 (or java12), regardless of seed, on both master & 7x.
The nature of the problem and the way our htp stack works suggests it *may*
ultimately be a jetty bug (perhaps related to [jetty
issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
*HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
been fixed on the {{jira/http2}} branch (as of
52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
merged to master soon.
Filing this issue largely for tracking purpose, although we may also want to
use it for discussions/considerations of other backports/fixes to 7x
was:
TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of the
time when run with java11 (or java12), regardless of seed, on both master & 7x.
The nature of the problem and the way our htp stack works suggests it *may*
ultimately be a jetty bug (perhaps related to [jetty
issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
*HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
been fixed on the {{jira/http2}} branch (as of
52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
merged to master soon.
Filing this issue largely for tracking purpose, although we may also want to
use it for discussions/considerations of other backports/fixes to 7x
> Enforce using TLSv1.2 for HttpClient
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, we should enforce HttpClient to
> uses TLSv1.2
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12988) Enforce using TLSv1.2 for HttpClient
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-12988:
Summary: Enforce using TLSv1.2 for HttpClient (was:
TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName fails reliably on java11:
"SSLPeerUnverifiedException: peer not authenticated")
> Enforce using TLSv1.2 for HttpClient
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-13413.patch
>
>
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13541) Upgrade Jetty to 9.4.19.v20190610
[ https://issues.apache.org/jira/browse/SOLR-13541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat resolved SOLR-13541. - Resolution: Fixed Fix Version/s: 8.2 master (9.0) > Upgrade Jetty to 9.4.19.v20190610 > - > > Key: SOLR-13541 > URL: https://issues.apache.org/jira/browse/SOLR-13541 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: _test.res > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13413) jetty IdleTimeout bugs with Http2SolrClient, cause sprious timeouts on intranode requests
[ https://issues.apache.org/jira/browse/SOLR-13413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat resolved SOLR-13413. - Resolution: Fixed Fix Version/s: 8.1.2 8.2 master (9.0) > jetty IdleTimeout bugs with Http2SolrClient, cause sprious timeouts on > intranode requests > - > > Key: SOLR-13413 > URL: https://issues.apache.org/jira/browse/SOLR-13413 > Project: Solr > Issue Type: Bug >Affects Versions: 8.0 >Reporter: Hoss Man >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2, 8.1.2 > > Attachments: SOLR-13413.patch, > nocommit_TestDistributedStatsComponentCardinality_trivial-no-http2.patch > > > There is evidence in some recent jenkins failures that we may have some manor > of bug in our http2 client/server code that can cause intra-node query > requests to stall / timeout non-reproducibly. > In at least one known case, forcing the jetty & SolrClients used in the test > to use http1.1, seems to prevent these test failures. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12988) TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName fails reliably on java11: "SSLPeerUnverifiedException: peer not authenticated"
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866425#comment-16866425
]
Cao Manh Dat commented on SOLR-12988:
-
Hi guys, this is a problem belongs to HttpClient + Java 11 (TLSv1.3)
(HTTPCLIENT-1967).
To summary the problem: this only happens on HttpClient + TLSv1.3 which is
supported since Java 11.
The usecase:
* a ssl connection gets resumed
* the server will assume that the client already has the server's certificate
-> server won't try to send certificate to client
* org.apache.http.conn.ssl.DefaultHostnameVerifier in all case (resume or new
connection) always check the host of the server to ensure that it match with
the certificate
* since certificate does not get resent to client therefore at the point of
time org.apache.http.conn.ssl.DefaultHostnameVerifier tried to get server's
certificate it received this error {{throw new SSLPeerUnverifiedException("peer
not authenticated")}}
I took a look at how Jetty client deals with this problem, it seem that the
proper way to handle the problem here is let Java SSLEngine handling endpoint
verification by using {{SSLParameters}} rather than verify hostname manually
like org.apache.http.conn.ssl.DefaultHostnameVerifier.
-> If we completely remove usage of HttpClient in Solr, this problem will be
solved.
The patch fixed the problem by enforcing HttpClient to uses TLSv1.2 or lower
versions.
It seems that the problems affect anyone who uses Solr on Java 11 + SSL. Should
we backport the fixes to branch_8_1? So it can be released with 8.1.2 bug fixes?
[~hossman] [~ctargett] What do you thinks?
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName fails reliably on
> java11: "SSLPeerUnverifiedException: peer not authenticated"
> ---
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-13413.patch
>
>
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12988) TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName fails reliably on java11: "SSLPeerUnverifiedException: peer not authenticated"
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-12988:
Attachment: SOLR-13413.patch
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName fails reliably on
> java11: "SSLPeerUnverifiedException: peer not authenticated"
> ---
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-13413.patch
>
>
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-13541) Upgrade Jetty to 9.4.19.v20190610
[ https://issues.apache.org/jira/browse/SOLR-13541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat updated SOLR-13541: Comment: was deleted (was: [~erickerickson] Basically we disabled it for Java 11 in another issue. That why this error only arises in Java 8 (branch_8x)) > Upgrade Jetty to 9.4.19.v20190610 > - > > Key: SOLR-13541 > URL: https://issues.apache.org/jira/browse/SOLR-13541 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: _test.res > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13541) Upgrade Jetty to 9.4.19.v20190610
[ https://issues.apache.org/jira/browse/SOLR-13541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864151#comment-16864151 ] Cao Manh Dat commented on SOLR-13541: - [~erickerickson] Basically we disabled it for Java 11 in another issue. That why this error only arises in Java 8 (branch_8x) > Upgrade Jetty to 9.4.19.v20190610 > - > > Key: SOLR-13541 > URL: https://issues.apache.org/jira/browse/SOLR-13541 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: _test.res > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13413) IdleTimeout with Http2SolrClient
[ https://issues.apache.org/jira/browse/SOLR-13413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat updated SOLR-13413: Summary: IdleTimeout with Http2SolrClient (was: suspicious test failures caused by jetty TimeoutException related to using HTTP2) > IdleTimeout with Http2SolrClient > > > Key: SOLR-13413 > URL: https://issues.apache.org/jira/browse/SOLR-13413 > Project: Solr > Issue Type: Bug >Affects Versions: 8.0 >Reporter: Hoss Man >Assignee: Cao Manh Dat >Priority: Major > Attachments: SOLR-13413.patch, > nocommit_TestDistributedStatsComponentCardinality_trivial-no-http2.patch > > > There is evidence in some recent jenkins failures that we may have some manor > of bug in our http2 client/server code that can cause intra-node query > requests to stall / timeout non-reproducibly. > In at least one known case, forcing the jetty & SolrClients used in the test > to use http1.1, seems to prevent these test failures. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13413) suspicious test failures caused by jetty TimeoutException related to using HTTP2
[ https://issues.apache.org/jira/browse/SOLR-13413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat updated SOLR-13413: Attachment: SOLR-13413.patch Status: Open (was: Open) Attached a patch to upgrade the transport http2 module to 9.4.19 (which contains the fix). The tests passed + the Hoss's command for running the failed test also passed. [~hossman] I'm planning to commit this patch to branch_8x and master also to see the result of Jenkins run. Does that make sense? > suspicious test failures caused by jetty TimeoutException related to using > HTTP2 > > > Key: SOLR-13413 > URL: https://issues.apache.org/jira/browse/SOLR-13413 > Project: Solr > Issue Type: Bug >Affects Versions: 8.0 >Reporter: Hoss Man >Assignee: Cao Manh Dat >Priority: Major > Attachments: SOLR-13413.patch, > nocommit_TestDistributedStatsComponentCardinality_trivial-no-http2.patch > > > There is evidence in some recent jenkins failures that we may have some manor > of bug in our http2 client/server code that can cause intra-node query > requests to stall / timeout non-reproducibly. > In at least one known case, forcing the jetty & SolrClients used in the test > to use http1.1, seems to prevent these test failures. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13526) BasicAuthIntegrationTest and JWTAuthIntegrationTest fails metrics tests
[ https://issues.apache.org/jira/browse/SOLR-13526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat resolved SOLR-13526. - Resolution: Fixed > BasicAuthIntegrationTest and JWTAuthIntegrationTest fails metrics tests > --- > > Key: SOLR-13526 > URL: https://issues.apache.org/jira/browse/SOLR-13526 > Project: Solr > Issue Type: Bug > Components: Tests >Reporter: Jan Høydahl >Assignee: Cao Manh Dat >Priority: Major > Fix For: 8.1.2 > > > These two tests have been failing a lot recently, so we'll AwaitsFix them for > now > Example: > [https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Windows/133/#showFailuresLink] > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13510) Intermittent 401's for internode requests with basicauth enabled
[
https://issues.apache.org/jira/browse/SOLR-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat resolved SOLR-13510.
-
Resolution: Fixed
Fix Version/s: 8.1.2
8.2
master (9.0)
> Intermittent 401's for internode requests with basicauth enabled
>
>
> Key: SOLR-13510
> URL: https://issues.apache.org/jira/browse/SOLR-13510
> Project: Solr
> Issue Type: Bug
> Components: Authentication
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2, 8.1.2
>
> Attachments: SOLR-13510.patch
>
>
> We recently got a bug report on the mailing list:
> {quote}
> On Solr 8.1.1, using our previously working security.json, running queries
> (through the admin UI currently) I non-deterministically get 401 responses
> on queries when a collection has more than 1 shard. Increasing the number
> of shards in the collection makes the errors more likely.
> {
> "responseHeader":{
> "zkConnected":true,
> "status":401,
> "QTime":30,
> "params":{
> "q":"*:*",
> "_":"1559474550365"}},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
> "root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
> require authentication\n\n\n",
> "code":401}}
> {quote}
> The reporter (credit to Colvin Cowie) also gives reproduction steps:
> {quote}
># Extract solr 8.1.1.
># bin\solr start -e cloud
> 1 node / [default port] / [default collection name] / 4 shards / 1
> replica / [_default configuration]
># server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
> /security.json
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{ "name": "all", "role": "admin"} ],
> "user-role": {"solradmin": "admin"}
> }
> }
> {quote}
> (Minor edits for conciseness)
> I'm able to reproduce this bug as well. Other auth issues (SOLR-13472) look
> like they're impacted by the topography of the collection and cluster. But
> this doesn't seem affected by that at all (401's occur on inter-node requests
> regardless of the recipient of the initial request, and even when all nodes
> have a shard replica).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[
https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862088#comment-16862088
]
Cao Manh Dat commented on SOLR-13434:
-
Hi, When I run {{mvn dependency:tree}} It show some thing like this
{code}
[main] INFO org.apache.maven.cli.event.ExecutionEventLogger -
[main] INFO org.apache.maven.cli.event.ExecutionEventLogger - Building Apache
Solr Core tests 9.0.0-SNAPSHOT
[main] INFO org.apache.maven.cli.event.ExecutionEventLogger -
[main] INFO org.apache.maven.cli.event.ExecutionEventLogger -
[main] INFO org.apache.maven.cli.event.ExecutionEventLogger - ---
maven-dependency-plugin:3.1.1:tree (default-cli) @ solr-core-tests ---
[main] INFO org.apache.maven.plugins.dependency.tree.TreeMojo -
org.apache.solr:solr-core-tests:jar:9.0.0-SNAPSHOT
[main] INFO org.apache.maven.plugins.dependency.tree.TreeMojo - +-
org.apache.lucene:lucene-test-framework:jar:9.0.0-SNAPSHOT:test
[main] INFO org.apache.maven.plugins.dependency.tree.TreeMojo - | \-
org.hamcrest:hamcrest-core:jar:1.3:test
[main] INFO org.apache.maven.plugins.dependency.tree.TreeMojo - +-
org.apache.solr:solr-test-framework:jar:9.0.0-SNAPSHOT:test
[main] INFO org.apache.maven.plugins.dependency.tree.TreeMojo - +-
org.apache.solr:solr-core:jar:9.0.0-SNAPSHOT:test
[main] INFO org.apache.maven.plugins.dependency.tree.TreeMojo - +-
org.apache.lucene:lucene-queryparser:test-jar:tests:9.0.0-SNAPSHOT:test
{code}
What I'm expecting here is all dependencies of solr-test-framework should also
be included here. Did I miss something here?
> OpenTracing support for Solr
>
>
> Key: SOLR-13434
> URL: https://issues.apache.org/jira/browse/SOLR-13434
> Project: Solr
> Issue Type: New Feature
>Reporter: Shalin Shekhar Mangar
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13434.patch
>
> Time Spent: 7h 40m
> Remaining Estimate: 0h
>
> [OpenTracing|https://opentracing.io/] is a vendor neutral API and
> infrastructure for distributed tracing. Many OSS tracers just as Jaeger,
> OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing
> APIs. Ideally, we can implement it once and have integrations for popular
> tracers like we have with metrics and prometheus.
> I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack
> of activity so this is a fresh attempt at solving this problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13526) BasicAuthIntegrationTest and JWTAuthIntegrationTest fails metrics tests
[ https://issues.apache.org/jira/browse/SOLR-13526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862023#comment-16862023 ] Cao Manh Dat commented on SOLR-13526: - Yeah, so SOLR-13510 was incompleted (contains a bug). But accidentally, the bug was fixed by SOLR-13434 which were backported to branch_8x and master but not branch_8_1. > BasicAuthIntegrationTest and JWTAuthIntegrationTest fails metrics tests > --- > > Key: SOLR-13526 > URL: https://issues.apache.org/jira/browse/SOLR-13526 > Project: Solr > Issue Type: Bug > Components: Tests >Reporter: Jan Høydahl >Assignee: Cao Manh Dat >Priority: Major > Fix For: 8.1.2 > > > These two tests have been failing a lot recently, so we'll AwaitsFix them for > now > Example: > [https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Windows/133/#showFailuresLink] > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13526) BasicAuthIntegrationTest and JWTAuthIntegrationTest fails metrics tests
[ https://issues.apache.org/jira/browse/SOLR-13526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862023#comment-16862023 ] Cao Manh Dat edited comment on SOLR-13526 at 6/12/19 11:31 AM: --- Yeah, so SOLR-13510 was incompleted (contains a bug). But accidentally, the bug was fixed by SOLR-13434 which were backported to branch_8x and master but not branch_8_1. That explains why only branch_8_1 sees the test failures. was (Author: caomanhdat): Yeah, so SOLR-13510 was incompleted (contains a bug). But accidentally, the bug was fixed by SOLR-13434 which were backported to branch_8x and master but not branch_8_1. > BasicAuthIntegrationTest and JWTAuthIntegrationTest fails metrics tests > --- > > Key: SOLR-13526 > URL: https://issues.apache.org/jira/browse/SOLR-13526 > Project: Solr > Issue Type: Bug > Components: Tests >Reporter: Jan Høydahl >Assignee: Cao Manh Dat >Priority: Major > Fix For: 8.1.2 > > > These two tests have been failing a lot recently, so we'll AwaitsFix them for > now > Example: > [https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Windows/133/#showFailuresLink] > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862002#comment-16862002 ] Cao Manh Dat edited comment on SOLR-13434 at 6/12/19 11:09 AM: --- Hi [~janhoy] The Maven build is quite a mess. I don't even know how to reproduce the problem? was (Author: caomanhdat): [~janhoy] The Maven build is quite a mess, how can I re-produce the problem? > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 7h 40m > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862002#comment-16862002 ] Cao Manh Dat commented on SOLR-13434: - [~janhoy] The Maven build is quite a mess, how can I re-produce the problem? > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 7h 40m > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13526) BasicAuthIntegrationTest and JWTAuthIntegrationTest fails metrics tests
[ https://issues.apache.org/jira/browse/SOLR-13526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861987#comment-16861987 ] Cao Manh Dat edited comment on SOLR-13526 at 6/12/19 10:57 AM: --- Hi [~janhoy], should we do that? I means this commit completed SOLR-13510 (which already have a CHANGES entry). was (Author: caomanhdat): Hi [~janhoy], should we do that, I means this commit completed SOLR-13510 (which already have a CHANGES entry). > BasicAuthIntegrationTest and JWTAuthIntegrationTest fails metrics tests > --- > > Key: SOLR-13526 > URL: https://issues.apache.org/jira/browse/SOLR-13526 > Project: Solr > Issue Type: Bug > Components: Tests >Reporter: Jan Høydahl >Assignee: Cao Manh Dat >Priority: Major > Fix For: 8.1.2 > > > These two tests have been failing a lot recently, so we'll AwaitsFix them for > now > Example: > [https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Windows/133/#showFailuresLink] > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13526) BasicAuthIntegrationTest and JWTAuthIntegrationTest fails metrics tests
[ https://issues.apache.org/jira/browse/SOLR-13526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861987#comment-16861987 ] Cao Manh Dat commented on SOLR-13526: - Hi [~janhoy], should we do that, I means this commit completed SOLR-13510 (which already have a CHANGES entry). > BasicAuthIntegrationTest and JWTAuthIntegrationTest fails metrics tests > --- > > Key: SOLR-13526 > URL: https://issues.apache.org/jira/browse/SOLR-13526 > Project: Solr > Issue Type: Bug > Components: Tests >Reporter: Jan Høydahl >Assignee: Cao Manh Dat >Priority: Major > Fix For: 8.1.2 > > > These two tests have been failing a lot recently, so we'll AwaitsFix them for > now > Example: > [https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Windows/133/#showFailuresLink] > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13526) BasicAuthIntegrationTest and JWTAuthIntegrationTest fails metrics tests
[ https://issues.apache.org/jira/browse/SOLR-13526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861968#comment-16861968 ] Cao Manh Dat commented on SOLR-13526: - Thanks [~janhoy] for tracking this problem. > BasicAuthIntegrationTest and JWTAuthIntegrationTest fails metrics tests > --- > > Key: SOLR-13526 > URL: https://issues.apache.org/jira/browse/SOLR-13526 > Project: Solr > Issue Type: Bug > Components: Tests >Reporter: Jan Høydahl >Priority: Major > > These two tests have been failing a lot recently, so we'll AwaitsFix them for > now > Example: > [https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Windows/133/#showFailuresLink] > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13510) Intermittent 401's for internode requests with basicauth enabled
[
https://issues.apache.org/jira/browse/SOLR-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858389#comment-16858389
]
Cao Manh Dat commented on SOLR-13510:
-
[~janhoy] I kinda think that the old metrics assertion was wrong?
> Intermittent 401's for internode requests with basicauth enabled
>
>
> Key: SOLR-13510
> URL: https://issues.apache.org/jira/browse/SOLR-13510
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-13510.patch
>
>
> We recently got a bug report on the mailing list:
> {quote}
> On Solr 8.1.1, using our previously working security.json, running queries
> (through the admin UI currently) I non-deterministically get 401 responses
> on queries when a collection has more than 1 shard. Increasing the number
> of shards in the collection makes the errors more likely.
> {
> "responseHeader":{
> "zkConnected":true,
> "status":401,
> "QTime":30,
> "params":{
> "q":"*:*",
> "_":"1559474550365"}},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
> "root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
> require authentication\n\n\n",
> "code":401}}
> {quote}
> The reporter (credit to Colvin Cowie) also gives reproduction steps:
> {quote}
># Extract solr 8.1.1.
># bin\solr start -e cloud
> 1 node / [default port] / [default collection name] / 4 shards / 1
> replica / [_default configuration]
># server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
> /security.json
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{ "name": "all", "role": "admin"} ],
> "user-role": {"solradmin": "admin"}
> }
> }
> {quote}
> (Minor edits for conciseness)
> I'm able to reproduce this bug as well. Other auth issues (SOLR-13472) look
> like they're impacted by the topography of the collection and cluster. But
> this doesn't seem affected by that at all (401's occur on inter-node requests
> regardless of the recipient of the initial request, and even when all nodes
> have a shard replica).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat resolved SOLR-13434. - Resolution: Fixed > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 7h 40m > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[
https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857446#comment-16857446
]
Cao Manh Dat commented on SOLR-13434:
-
Hi [~dsmiley], sorry for the confusion but as soon as I run {{precommit}} on
branch_8x, there are several problems were detected (which was not on master)
about missing {{package-info.java}} and {{overview.html}} so all of them
including the fix was packed in a commit, then get cherry-pick to master branch.
> OpenTracing support for Solr
>
>
> Key: SOLR-13434
> URL: https://issues.apache.org/jira/browse/SOLR-13434
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Shalin Shekhar Mangar
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13434.patch
>
> Time Spent: 7h 40m
> Remaining Estimate: 0h
>
> [OpenTracing|https://opentracing.io/] is a vendor neutral API and
> infrastructure for distributed tracing. Many OSS tracers just as Jaeger,
> OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing
> APIs. Ideally, we can implement it once and have integrations for popular
> tracers like we have with metrics and prometheus.
> I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack
> of activity so this is a fresh attempt at solving this problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat resolved SOLR-13434. - Resolution: Fixed > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 7h 40m > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12859) DocExpirationUpdateProcessorFactory does not work with BasicAuth
[
https://issues.apache.org/jira/browse/SOLR-12859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856010#comment-16856010
]
Cao Manh Dat commented on SOLR-12859:
-
[~janhoy] {{PKIAuthenticationPlugin}} why should need that flag
{{isSolrServerThread}}, any request get intercepted by PKIAuthenticationPlugin
will be an internal request right?
> DocExpirationUpdateProcessorFactory does not work with BasicAuth
>
>
> Key: SOLR-12859
> URL: https://issues.apache.org/jira/browse/SOLR-12859
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.5
>Reporter: Varun Thacker
>Priority: Major
>
> I setup a cluster with basic auth and then wanted to use Solr's TTL feature (
> DocExpirationUpdateProcessorFactory ) to auto-delete documents.
>
> Turns out it doesn't work when Basic Auth is enabled. I get the following
> stacktrace from the logs
> {code:java}
> 2018-10-12 22:06:38.967 ERROR (autoExpireDocs-42-thread-1) [ ]
> o.a.s.u.p.DocExpirationUpdateProcessorFactory Runtime error in periodic
> deletion of expired docs: Async exception during distributed update: Error
> from server at http://192.168.0.8:8983/solr/gettingstarted_shard2_replica_n6:
> require authentication
> request:
> http://192.168.0.8:8983/solr/gettingstarted_shard2_replica_n6/update?update.distrib=TOLEADER=http%3A%2F%2F192.168.0.8%3A8983%2Fsolr%2Fgettingstarted_shard1_replica_n2%2F=javabin=2
> org.apache.solr.update.processor.DistributedUpdateProcessor$DistributedUpdatesAsyncException:
> Async exception during distributed update: Error from server at
> http://192.168.0.8:8983/solr/gettingstarted_shard2_replica_n6: require
> authentication
> request:
> http://192.168.0.8:8983/solr/gettingstarted_shard2_replica_n6/update?update.distrib=TOLEADER=http%3A%2F%2F192.168.0.8%3A8983%2Fsolr%2Fgettingstarted_shard1_replica_n2%2F=javabin=2
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.doFinish(DistributedUpdateProcessor.java:964)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:1976)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.finish(LogUpdateProcessorFactory.java:182)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:80)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:80)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:80)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:80)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:80)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:80)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:80)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:80)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:80)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:80)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
>
[jira] [Commented] (SOLR-13510) Intermittent 401's for internode requests with basicauth enabled
[
https://issues.apache.org/jira/browse/SOLR-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855952#comment-16855952
]
Cao Manh Dat commented on SOLR-13510:
-
[~ctargett], yeah, sure!
> Intermittent 401's for internode requests with basicauth enabled
>
>
> Key: SOLR-13510
> URL: https://issues.apache.org/jira/browse/SOLR-13510
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-13510.patch
>
>
> We recently got a bug report on the mailing list:
> {quote}
> On Solr 8.1.1, using our previously working security.json, running queries
> (through the admin UI currently) I non-deterministically get 401 responses
> on queries when a collection has more than 1 shard. Increasing the number
> of shards in the collection makes the errors more likely.
> {
> "responseHeader":{
> "zkConnected":true,
> "status":401,
> "QTime":30,
> "params":{
> "q":"*:*",
> "_":"1559474550365"}},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
> "root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
> require authentication\n\n\n",
> "code":401}}
> {quote}
> The reporter (credit to Colvin Cowie) also gives reproduction steps:
> {quote}
># Extract solr 8.1.1.
># bin\solr start -e cloud
> 1 node / [default port] / [default collection name] / 4 shards / 1
> replica / [_default configuration]
># server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
> /security.json
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{ "name": "all", "role": "admin"} ],
> "user-role": {"solradmin": "admin"}
> }
> }
> {quote}
> (Minor edits for conciseness)
> I'm able to reproduce this bug as well. Other auth issues (SOLR-13472) look
> like they're impacted by the topography of the collection and cluster. But
> this doesn't seem affected by that at all (401's occur on inter-node requests
> regardless of the recipient of the initial request, and even when all nodes
> have a shard replica).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13413) suspicious test failures caused by jetty TimeoutException related to using HTTP2
[
https://issues.apache.org/jira/browse/SOLR-13413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855950#comment-16855950
]
Cao Manh Dat commented on SOLR-13413:
-
Hi [~hossman], the next release version 9.4.19 will contain the fix. But I'm
not sure when it will be released.
{quote}
is there any work around we can do in solr code in the meantime?
{quote}
I can only come up with the idea of moving Jetty classes (around 5,6 classes)
with fixes and use them in Solr.
> suspicious test failures caused by jetty TimeoutException related to using
> HTTP2
>
>
> Key: SOLR-13413
> URL: https://issues.apache.org/jira/browse/SOLR-13413
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.0
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments:
> nocommit_TestDistributedStatsComponentCardinality_trivial-no-http2.patch
>
>
> There is evidence in some recent jenkins failures that we may have some manor
> of bug in our http2 client/server code that can cause intra-node query
> requests to stall / timeout non-reproducibly.
> In at least one known case, forcing the jetty & SolrClients used in the test
> to use http1.1, seems to prevent these test failures.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13510) Intermittent 401's for internode requests with basicauth enabled
[
https://issues.apache.org/jira/browse/SOLR-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat reassigned SOLR-13510:
---
Assignee: Cao Manh Dat
> Intermittent 401's for internode requests with basicauth enabled
>
>
> Key: SOLR-13510
> URL: https://issues.apache.org/jira/browse/SOLR-13510
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-13510.patch
>
>
> We recently got a bug report on the mailing list:
> {quote}
> On Solr 8.1.1, using our previously working security.json, running queries
> (through the admin UI currently) I non-deterministically get 401 responses
> on queries when a collection has more than 1 shard. Increasing the number
> of shards in the collection makes the errors more likely.
> {
> "responseHeader":{
> "zkConnected":true,
> "status":401,
> "QTime":30,
> "params":{
> "q":"*:*",
> "_":"1559474550365"}},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
> "root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
> require authentication\n\n\n",
> "code":401}}
> {quote}
> The reporter (credit to Colvin Cowie) also gives reproduction steps:
> {quote}
># Extract solr 8.1.1.
># bin\solr start -e cloud
> 1 node / [default port] / [default collection name] / 4 shards / 1
> replica / [_default configuration]
># server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
> /security.json
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{ "name": "all", "role": "admin"} ],
> "user-role": {"solradmin": "admin"}
> }
> }
> {quote}
> (Minor edits for conciseness)
> I'm able to reproduce this bug as well. Other auth issues (SOLR-13472) look
> like they're impacted by the topography of the collection and cluster. But
> this doesn't seem affected by that at all (401's occur on inter-node requests
> regardless of the recipient of the initial request, and even when all nodes
> have a shard replica).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13510) Intermittent 401's for internode requests with basicauth enabled
[
https://issues.apache.org/jira/browse/SOLR-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855779#comment-16855779
]
Cao Manh Dat commented on SOLR-13510:
-
[~cjcowie] I beleived the attached patch will solve the problem.
Explain: in {{Http2SolrClient}} listeners will can be called in another thread
than the thread calling execute request method, therefore SolrRequestInfo will
return null on that case.
> Intermittent 401's for internode requests with basicauth enabled
>
>
> Key: SOLR-13510
> URL: https://issues.apache.org/jira/browse/SOLR-13510
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13510.patch
>
>
> We recently got a bug report on the mailing list:
> {quote}
> On Solr 8.1.1, using our previously working security.json, running queries
> (through the admin UI currently) I non-deterministically get 401 responses
> on queries when a collection has more than 1 shard. Increasing the number
> of shards in the collection makes the errors more likely.
> {
> "responseHeader":{
> "zkConnected":true,
> "status":401,
> "QTime":30,
> "params":{
> "q":"*:*",
> "_":"1559474550365"}},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
> "root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
> require authentication\n\n\n",
> "code":401}}
> {quote}
> The reporter (credit to Colvin Cowie) also gives reproduction steps:
> {quote}
># Extract solr 8.1.1.
># bin\solr start -e cloud
> 1 node / [default port] / [default collection name] / 4 shards / 1
> replica / [_default configuration]
># server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
> /security.json
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{ "name": "all", "role": "admin"} ],
> "user-role": {"solradmin": "admin"}
> }
> }
> {quote}
> (Minor edits for conciseness)
> I'm able to reproduce this bug as well. Other auth issues (SOLR-13472) look
> like they're impacted by the topography of the collection and cluster. But
> this doesn't seem affected by that at all (401's occur on inter-node requests
> regardless of the recipient of the initial request, and even when all nodes
> have a shard replica).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13510) Intermittent 401's for internode requests with basicauth enabled
[
https://issues.apache.org/jira/browse/SOLR-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855779#comment-16855779
]
Cao Manh Dat edited comment on SOLR-13510 at 6/4/19 2:49 PM:
-
[~cjcowie] I beleived the attached patch will solve the problem. Can you rerun
with this patch?
Explain: in {{Http2SolrClient}} listeners will can be called in another thread
than the thread calling execute request method, therefore SolrRequestInfo will
return null on that case.
was (Author: caomanhdat):
[~cjcowie] I beleived the attached patch will solve the problem.
Explain: in {{Http2SolrClient}} listeners will can be called in another thread
than the thread calling execute request method, therefore SolrRequestInfo will
return null on that case.
> Intermittent 401's for internode requests with basicauth enabled
>
>
> Key: SOLR-13510
> URL: https://issues.apache.org/jira/browse/SOLR-13510
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13510.patch
>
>
> We recently got a bug report on the mailing list:
> {quote}
> On Solr 8.1.1, using our previously working security.json, running queries
> (through the admin UI currently) I non-deterministically get 401 responses
> on queries when a collection has more than 1 shard. Increasing the number
> of shards in the collection makes the errors more likely.
> {
> "responseHeader":{
> "zkConnected":true,
> "status":401,
> "QTime":30,
> "params":{
> "q":"*:*",
> "_":"1559474550365"}},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
> "root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
> require authentication\n\n\n",
> "code":401}}
> {quote}
> The reporter (credit to Colvin Cowie) also gives reproduction steps:
> {quote}
># Extract solr 8.1.1.
># bin\solr start -e cloud
> 1 node / [default port] / [default collection name] / 4 shards / 1
> replica / [_default configuration]
># server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
> /security.json
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{ "name": "all", "role": "admin"} ],
> "user-role": {"solradmin": "admin"}
> }
> }
> {quote}
> (Minor edits for conciseness)
> I'm able to reproduce this bug as well. Other auth issues (SOLR-13472) look
> like they're impacted by the topography of the collection and cluster. But
> this doesn't seem affected by that at all (401's occur on inter-node requests
> regardless of the recipient of the initial request, and even when all nodes
> have a shard replica).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13510) Intermittent 401's for internode requests with basicauth enabled
[
https://issues.apache.org/jira/browse/SOLR-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-13510:
Attachment: SOLR-13510.patch
> Intermittent 401's for internode requests with basicauth enabled
>
>
> Key: SOLR-13510
> URL: https://issues.apache.org/jira/browse/SOLR-13510
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13510.patch
>
>
> We recently got a bug report on the mailing list:
> {quote}
> On Solr 8.1.1, using our previously working security.json, running queries
> (through the admin UI currently) I non-deterministically get 401 responses
> on queries when a collection has more than 1 shard. Increasing the number
> of shards in the collection makes the errors more likely.
> {
> "responseHeader":{
> "zkConnected":true,
> "status":401,
> "QTime":30,
> "params":{
> "q":"*:*",
> "_":"1559474550365"}},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
> "root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
> require authentication\n\n\n",
> "code":401}}
> {quote}
> The reporter (credit to Colvin Cowie) also gives reproduction steps:
> {quote}
># Extract solr 8.1.1.
># bin\solr start -e cloud
> 1 node / [default port] / [default collection name] / 4 shards / 1
> replica / [_default configuration]
># server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
> /security.json
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{ "name": "all", "role": "admin"} ],
> "user-role": {"solradmin": "admin"}
> }
> }
> {quote}
> (Minor edits for conciseness)
> I'm able to reproduce this bug as well. Other auth issues (SOLR-13472) look
> like they're impacted by the topography of the collection and cluster. But
> this doesn't seem affected by that at all (401's occur on inter-node requests
> regardless of the recipient of the initial request, and even when all nodes
> have a shard replica).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13510) Intermittent 401's for internode requests with basicauth enabled
[
https://issues.apache.org/jira/browse/SOLR-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855665#comment-16855665
]
Cao Manh Dat commented on SOLR-13510:
-
Hi [~gerlowskija], even with {{-Dsolr.http1=true}}, we are still using
{{Http2SolrClient}} for internal communication, so If this is a problem relate
to Solr 8.0 only, it might be caused by {{Http2SolrClient}}
> Intermittent 401's for internode requests with basicauth enabled
>
>
> Key: SOLR-13510
> URL: https://issues.apache.org/jira/browse/SOLR-13510
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Priority: Major
>
> We recently got a bug report on the mailing list:
> {quote}
> On Solr 8.1.1, using our previously working security.json, running queries
> (through the admin UI currently) I non-deterministically get 401 responses
> on queries when a collection has more than 1 shard. Increasing the number
> of shards in the collection makes the errors more likely.
> {
> "responseHeader":{
> "zkConnected":true,
> "status":401,
> "QTime":30,
> "params":{
> "q":"*:*",
> "_":"1559474550365"}},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
> "root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
> require authentication\n\n\n",
> "code":401}}
> {quote}
> The reporter (credit to Colvin Cowie) also gives reproduction steps:
> {quote}
># Extract solr 8.1.1.
># bin\solr start -e cloud
> 1 node / [default port] / [default collection name] / 4 shards / 1
> replica / [_default configuration]
># server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
> /security.json
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{ "name": "all", "role": "admin"} ],
> "user-role": {"solradmin": "admin"}
> }
> }
> {quote}
> (Minor edits for conciseness)
> I'm able to reproduce this bug as well. Other auth issues (SOLR-13472) look
> like they're impacted by the topography of the collection and cluster. But
> this doesn't seem affected by that at all (401's occur on inter-node requests
> regardless of the recipient of the initial request, and even when all nodes
> have a shard replica).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13396) SolrCloud will delete the core data for any core that is not referenced in the clusterstate
[ https://issues.apache.org/jira/browse/SOLR-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855560#comment-16855560 ] Cao Manh Dat commented on SOLR-13396: - I'm taking a look. > SolrCloud will delete the core data for any core that is not referenced in > the clusterstate > --- > > Key: SOLR-13396 > URL: https://issues.apache.org/jira/browse/SOLR-13396 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 7.3.1, 8.0 >Reporter: Shawn Heisey >Priority: Major > > SOLR-12066 is an improvement designed to delete core data for replicas that > were deleted while the node was down -- better cleanup. > In practice, that change causes SolrCloud to delete all core data for cores > that are not referenced in the ZK clusterstate. If all the ZK data gets > deleted or the Solr instance is pointed at a ZK ensemble with no data, it > will proceed to delete all of the cores in the solr home, with no possibility > of recovery. > I do not think that Solr should ever delete core data unless an explicit > DELETE action has been made and the node is operational at the time of the > request. If a core exists during startup that cannot be found in the ZK > clusterstate, it should be ignored (not started) and a helpful message should > be logged. I think that message should probably be at WARN so that it shows > up in the admin UI logging tab with default settings. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[
https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854725#comment-16854725
]
Cao Manh Dat commented on SOLR-13434:
-
Hi [~janhoy], I see the PR get failed with {{JWTAuthPluginIntegrationTest}}, I
did some modification in the test, so it can be passed, if you have time please
taking a look at changes.
Basically, Http2SolrClient does not set attribute {{REQ_PRINCIPAL_KEY}} on
update requests, so it uses PKI instead of JWT. But I think it should uses JWT
whenever the listener is registered in Http2SolrClient and userPrincipal is not
null.
> OpenTracing support for Solr
>
>
> Key: SOLR-13434
> URL: https://issues.apache.org/jira/browse/SOLR-13434
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Shalin Shekhar Mangar
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13434.patch
>
> Time Spent: 7.5h
> Remaining Estimate: 0h
>
> [OpenTracing|https://opentracing.io/] is a vendor neutral API and
> infrastructure for distributed tracing. Many OSS tracers just as Jaeger,
> OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing
> APIs. Ideally, we can implement it once and have integrations for popular
> tracers like we have with metrics and prometheus.
> I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack
> of activity so this is a fresh attempt at solving this problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13450) Objects were not released error in CloudHttp2SolrClientTest and CloudSolrClientTest
[ https://issues.apache.org/jira/browse/SOLR-13450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat updated SOLR-13450: Fix Version/s: 8.2 master (9.0) Component/s: Tests > Objects were not released error in CloudHttp2SolrClientTest and > CloudSolrClientTest > --- > > Key: SOLR-13450 > URL: https://issues.apache.org/jira/browse/SOLR-13450 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: thetaphi-Lucene-Solr-8.1-Windows-92.txt, > thetaphi-Lucene-Solr-master-Windows-7921.txt > > > This problem is get noticed first by [~hossman] in SOLR-13276, this seems > appear most frequently in Windows box. > I tried to get rid of this problem in SOLR-13339, but I'm still seeing the > problems appear. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13450) Objects were not released error in CloudHttp2SolrClientTest and CloudSolrClientTest
[ https://issues.apache.org/jira/browse/SOLR-13450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat resolved SOLR-13450. - Resolution: Fixed > Objects were not released error in CloudHttp2SolrClientTest and > CloudSolrClientTest > --- > > Key: SOLR-13450 > URL: https://issues.apache.org/jira/browse/SOLR-13450 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Attachments: thetaphi-Lucene-Solr-8.1-Windows-92.txt, > thetaphi-Lucene-Solr-master-Windows-7921.txt > > > This problem is get noticed first by [~hossman] in SOLR-13276, this seems > appear most frequently in Windows box. > I tried to get rid of this problem in SOLR-13339, but I'm still seeing the > problems appear. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13450) Objects were not released error in CloudHttp2SolrClientTest and CloudSolrClientTest
[ https://issues.apache.org/jira/browse/SOLR-13450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat reassigned SOLR-13450: --- Assignee: Cao Manh Dat > Objects were not released error in CloudHttp2SolrClientTest and > CloudSolrClientTest > --- > > Key: SOLR-13450 > URL: https://issues.apache.org/jira/browse/SOLR-13450 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Attachments: thetaphi-Lucene-Solr-8.1-Windows-92.txt, > thetaphi-Lucene-Solr-master-Windows-7921.txt > > > This problem is get noticed first by [~hossman] in SOLR-13276, this seems > appear most frequently in Windows box. > I tried to get rid of this problem in SOLR-13339, but I'm still seeing the > problems appear. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849572#comment-16849572 ] Cao Manh Dat commented on SOLR-13434: - I took a look at OpenTelemetry, and * its api is very similar to OpenTracing. * a beta version is still pending, so I think it will take a while for the project to become mature (with lots of backend support like OpenTracing). * A bridge api for using OpenTelemetry on top of OpenTracing is introduced so we can always switch to OpenTelemetry in future. Therefore, I still follow the idea of supporting OpenTracing to Solr first. > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 2h 20m > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848759#comment-16848759 ] Cao Manh Dat commented on SOLR-13434: - [~otis] Thanks a lot for, it is quite a suprise. > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 1h 40m > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846825#comment-16846825 ] Cao Manh Dat commented on SOLR-13434: - Sorry for the mess of gitbox. I was accidentally pushed the branch to origin instead of the cloned one (was quite sleepy) > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 1h 20m > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846742#comment-16846742 ] Cao Manh Dat edited comment on SOLR-13434 at 5/23/19 4:00 PM: -- My initial patch for this one, almost finish, but I still meet some problem on adding a new module named jeagertracer-configurator in Solr (failed to run ant generate-maven-artifacts). Areas that this issue should cover * A basic distributed tracing for SolrCloud (outbound communications) on queries and indexing, other things like tracing on Overseer operations or Collections APIs can be added later. * A jaeger-contrib module so users can use Solr with Jaeger as backend * In case of Datadog, the Tracer is injected through Javaagent, so this also needs be supported in this issue. was (Author: caomanhdat): My initial patch for this one, almost finish, but I still meet some problem on adding a new module named jeagertracer-configurator in Solr (failed to run ant generate-maven-artifacts). > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 1h 20m > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846763#comment-16846763 ] Cao Manh Dat commented on SOLR-13434: - Hi [~krisden] Sure I created a PR. > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 10m > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat reassigned SOLR-13434: --- Assignee: Cao Manh Dat Attachment: SOLR-13434.patch My initial patch for this one, almost finish, but I still meet some problem on adding a new module named jeagertracer-configurator in Solr (failed to run ant generate-maven-artifacts). > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13445) Preferred replicas on nodes with same system properties as the query master
[
https://issues.apache.org/jira/browse/SOLR-13445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat resolved SOLR-13445.
-
Resolution: Fixed
> Preferred replicas on nodes with same system properties as the query master
> ---
>
> Key: SOLR-13445
> URL: https://issues.apache.org/jira/browse/SOLR-13445
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13445.patch, SOLR-13445.patch, SOLR-13445.patch
>
>
> Currently, Solr chooses a random replica for each shard to fan out the query
> request. However, this presents a problem when running Solr in multiple
> availability zones.
> If one availability zone fails then it affects all Solr nodes because they
> will try to connect to Solr nodes in the failed availability zone until the
> request times out. This can lead to a build up of threads on each Solr node
> until the node goes out of memory. This results in a cascading failure.
> This issue try to solve this problem by adding
> * another shardPreference param named {{node.sysprop}}, so the query will be
> routed to nodes with same defined system properties as the current one.
> * default shardPreferences on the whole cluster, which will be stored in
> {{/clusterprops.json}}.
> * a cacher for fetching other nodes system properties whenever /live_nodes
> get changed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13445) Preferred replicas on nodes with same system properties as the query master
[
https://issues.apache.org/jira/browse/SOLR-13445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16837323#comment-16837323
]
Cao Manh Dat commented on SOLR-13445:
-
Hi [~hossman], thanks a lot for your comment.
It seems that with -Dtests.dups, static instance are reused. That makes the
code query to gone nodes of previous tests.
> Preferred replicas on nodes with same system properties as the query master
> ---
>
> Key: SOLR-13445
> URL: https://issues.apache.org/jira/browse/SOLR-13445
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13445.patch, SOLR-13445.patch, SOLR-13445.patch
>
>
> Currently, Solr chooses a random replica for each shard to fan out the query
> request. However, this presents a problem when running Solr in multiple
> availability zones.
> If one availability zone fails then it affects all Solr nodes because they
> will try to connect to Solr nodes in the failed availability zone until the
> request times out. This can lead to a build up of threads on each Solr node
> until the node goes out of memory. This results in a cascading failure.
> This issue try to solve this problem by adding
> * another shardPreference param named {{node.sysprop}}, so the query will be
> routed to nodes with same defined system properties as the current one.
> * default shardPreferences on the whole cluster, which will be stored in
> {{/clusterprops.json}}.
> * a cacher for fetching other nodes system properties whenever /live_nodes
> get changed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13413) suspicious test failures caused by jetty TimeoutException related to using HTTP2
[ https://issues.apache.org/jira/browse/SOLR-13413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16836259#comment-16836259 ] Cao Manh Dat commented on SOLR-13413: - The problem is solved by https://github.com/eclipse/jetty.project/issues/3605 > suspicious test failures caused by jetty TimeoutException related to using > HTTP2 > > > Key: SOLR-13413 > URL: https://issues.apache.org/jira/browse/SOLR-13413 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Cao Manh Dat >Priority: Major > Attachments: > nocommit_TestDistributedStatsComponentCardinality_trivial-no-http2.patch > > > There is evidence in some recent jenkins failures that we may have some manor > of bug in our http2 client/server code that can cause intra-node query > requests to stall / timeout non-reproducibly. > In at least one known case, forcing the jetty & SolrClients used in the test > to use http1.1, seems to prevent these test failures. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13413) suspicious test failures caused by jetty TimeoutException related to using HTTP2
[ https://issues.apache.org/jira/browse/SOLR-13413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat reassigned SOLR-13413: --- Assignee: Cao Manh Dat > suspicious test failures caused by jetty TimeoutException related to using > HTTP2 > > > Key: SOLR-13413 > URL: https://issues.apache.org/jira/browse/SOLR-13413 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Cao Manh Dat >Priority: Major > Attachments: > nocommit_TestDistributedStatsComponentCardinality_trivial-no-http2.patch > > > There is evidence in some recent jenkins failures that we may have some manor > of bug in our http2 client/server code that can cause intra-node query > requests to stall / timeout non-reproducibly. > In at least one known case, forcing the jetty & SolrClients used in the test > to use http1.1, seems to prevent these test failures. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13455) JettySolrRunner does not enable HTTP2 unless jetty.testMode is set.
Cao Manh Dat created SOLR-13455: --- Summary: JettySolrRunner does not enable HTTP2 unless jetty.testMode is set. Key: SOLR-13455 URL: https://issues.apache.org/jira/browse/SOLR-13455 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Cao Manh Dat Assignee: Cao Manh Dat Right now JettySolrRunner does not add HTTP2ConnectionFactory unless "jetty.testMode" is set in system properties. This will affect anyone who want to run embedded Solr or using solr-test-framework. https://stackoverflow.com/questions/55417706/solr-8-minisolrcloudcluster-with-multiple-servers-gives-java-io-ioexception -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13445) Preferred replicas on nodes with same system properties as the query master
[
https://issues.apache.org/jira/browse/SOLR-13445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat resolved SOLR-13445.
-
Resolution: Fixed
Fix Version/s: 8.2
master (9.0)
> Preferred replicas on nodes with same system properties as the query master
> ---
>
> Key: SOLR-13445
> URL: https://issues.apache.org/jira/browse/SOLR-13445
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13445.patch, SOLR-13445.patch, SOLR-13445.patch
>
>
> Currently, Solr chooses a random replica for each shard to fan out the query
> request. However, this presents a problem when running Solr in multiple
> availability zones.
> If one availability zone fails then it affects all Solr nodes because they
> will try to connect to Solr nodes in the failed availability zone until the
> request times out. This can lead to a build up of threads on each Solr node
> until the node goes out of memory. This results in a cascading failure.
> This issue try to solve this problem by adding
> * another shardPreference param named {{node.sysprop}}, so the query will be
> routed to nodes with same defined system properties as the current one.
> * default shardPreferences on the whole cluster, which will be stored in
> {{/clusterprops.json}}.
> * a cacher for fetching other nodes system properties whenever /live_nodes
> get changed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13449) SolrClientNodeStateProvider always retries on requesting metrics from other nodes
[ https://issues.apache.org/jira/browse/SOLR-13449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat resolved SOLR-13449. - Resolution: Fixed > SolrClientNodeStateProvider always retries on requesting metrics from other > nodes > - > > Key: SOLR-13449 > URL: https://issues.apache.org/jira/browse/SOLR-13449 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7.1, 8.0 >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Fix For: 7.7.2, 8.1, master (9.0) > > Attachments: failure.txt > > > Even in case of a success call, SolrClientNodeStateProvider always retry the > getting metrics request. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13445) Preferred replicas on nodes with same system properties as the query master
[
https://issues.apache.org/jira/browse/SOLR-13445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16835486#comment-16835486
]
Cao Manh Dat commented on SOLR-13445:
-
Adding minor change to the patch because of TestHttpShardHandlerFactory failure.
> Preferred replicas on nodes with same system properties as the query master
> ---
>
> Key: SOLR-13445
> URL: https://issues.apache.org/jira/browse/SOLR-13445
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-13445.patch, SOLR-13445.patch, SOLR-13445.patch
>
>
> Currently, Solr chooses a random replica for each shard to fan out the query
> request. However, this presents a problem when running Solr in multiple
> availability zones.
> If one availability zone fails then it affects all Solr nodes because they
> will try to connect to Solr nodes in the failed availability zone until the
> request times out. This can lead to a build up of threads on each Solr node
> until the node goes out of memory. This results in a cascading failure.
> This issue try to solve this problem by adding
> * another shardPreference param named {{node.sysprop}}, so the query will be
> routed to nodes with same defined system properties as the current one.
> * default shardPreferences on the whole cluster, which will be stored in
> {{/clusterprops.json}}.
> * a cacher for fetching other nodes system properties whenever /live_nodes
> get changed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13445) Preferred replicas on nodes with same system properties as the query master
[
https://issues.apache.org/jira/browse/SOLR-13445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-13445:
Attachment: SOLR-13445.patch
> Preferred replicas on nodes with same system properties as the query master
> ---
>
> Key: SOLR-13445
> URL: https://issues.apache.org/jira/browse/SOLR-13445
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-13445.patch, SOLR-13445.patch, SOLR-13445.patch
>
>
> Currently, Solr chooses a random replica for each shard to fan out the query
> request. However, this presents a problem when running Solr in multiple
> availability zones.
> If one availability zone fails then it affects all Solr nodes because they
> will try to connect to Solr nodes in the failed availability zone until the
> request times out. This can lead to a build up of threads on each Solr node
> until the node goes out of memory. This results in a cascading failure.
> This issue try to solve this problem by adding
> * another shardPreference param named {{node.sysprop}}, so the query will be
> routed to nodes with same defined system properties as the current one.
> * default shardPreferences on the whole cluster, which will be stored in
> {{/clusterprops.json}}.
> * a cacher for fetching other nodes system properties whenever /live_nodes
> get changed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13453) JWTAuthPluginIntegrationTest and TestSolrCloudWithHadoopAuthPlugin get failed when SolrClientNodeStateProvider behave nicely
Cao Manh Dat created SOLR-13453: --- Summary: JWTAuthPluginIntegrationTest and TestSolrCloudWithHadoopAuthPlugin get failed when SolrClientNodeStateProvider behave nicely Key: SOLR-13453 URL: https://issues.apache.org/jira/browse/SOLR-13453 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Cao Manh Dat SOLR-13449 is a trivial fix for SolrClientNodeStateProvider, it makes the provider stop retry once the metrics are successfully grabbed. In an unexpected way, JWTAuthPluginIntegrationTest and TestSolrCloudWithHadoopAuthPlugin get failed 100%. This is bugs of tests for sure. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13449) SolrClientNodeStateProvider always retries on requesting metrics from other nodes
[ https://issues.apache.org/jira/browse/SOLR-13449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16834811#comment-16834811 ] Cao Manh Dat commented on SOLR-13449: - I think so since both of them are modified in SOLR-13248. > SolrClientNodeStateProvider always retries on requesting metrics from other > nodes > - > > Key: SOLR-13449 > URL: https://issues.apache.org/jira/browse/SOLR-13449 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7.1, 8.0 >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Fix For: 7.7.2, 8.1, master (9.0) > > Attachments: failure.txt > > > Even in case of a success call, SolrClientNodeStateProvider always retry the > getting metrics request. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13449) SolrClientNodeStateProvider always retries on requesting metrics from other nodes
[ https://issues.apache.org/jira/browse/SOLR-13449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16834803#comment-16834803 ] Cao Manh Dat commented on SOLR-13449: - Hi [~ichattopadhyaya] I think the problem here is the test is not correctly written, not because of the fix. The better way here is remove the assertion failure or mark the test as BadApples or AwaisFix. > SolrClientNodeStateProvider always retries on requesting metrics from other > nodes > - > > Key: SOLR-13449 > URL: https://issues.apache.org/jira/browse/SOLR-13449 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7.1, 8.0 >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Fix For: 7.7.2, 8.1, master (9.0) > > Attachments: failure.txt > > > Even in case of a success call, SolrClientNodeStateProvider always retry the > getting metrics request. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13449) SolrClientNodeStateProvider always retries on requesting metrics from other nodes
[ https://issues.apache.org/jira/browse/SOLR-13449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16834662#comment-16834662 ] Cao Manh Dat commented on SOLR-13449: - Hmm weird, I don't think the change can cause any problem? > SolrClientNodeStateProvider always retries on requesting metrics from other > nodes > - > > Key: SOLR-13449 > URL: https://issues.apache.org/jira/browse/SOLR-13449 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7.1, 8.0 >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Fix For: 7.7.2, 8.1, master (9.0) > > > Even in case of a success call, SolrClientNodeStateProvider always retry the > getting metrics request. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13276) Adding Http2 equivalent classes of CloudSolrClient and HttpClusterStateProvider
[ https://issues.apache.org/jira/browse/SOLR-13276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16834562#comment-16834562 ] Cao Manh Dat commented on SOLR-13276: - Hi [~ichattopadhyaya] I already pushed the fix to branch_8_1. Since the test failure appear on both test CloudHttp2SolrClientTest and CloudSolrClientTest, so I don't think that is the reason to hold off the release. > Adding Http2 equivalent classes of CloudSolrClient and > HttpClusterStateProvider > > > Key: SOLR-13276 > URL: https://issues.apache.org/jira/browse/SOLR-13276 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Fix For: 8.1 > > Attachments: SOLR-13276.patch, SOLR-13276.patch, SOLR-13276.patch, > thetaphi-Lucene-Solr-master-Windows-7810.txt, > thetaphi_Lucene-Solr-8.x-Windows_69.log.txt, > thetaphi_Lucene-Solr-master-Windows_7754.log.txt > > > Before we can move on and wipe out the usage of apache httpclient inside > Solr-core. We need to create Http/2 equivalent classes of CloudSolrClient and > HttpClusterStateProvider -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13449) SolrClientNodeStateProvider always retries on requesting metrics from other nodes
[ https://issues.apache.org/jira/browse/SOLR-13449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat updated SOLR-13449: Fix Version/s: 7.7.2 > SolrClientNodeStateProvider always retries on requesting metrics from other > nodes > - > > Key: SOLR-13449 > URL: https://issues.apache.org/jira/browse/SOLR-13449 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7.1, 8.0 >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Fix For: 7.7.2, 8.1, master (9.0) > > > Even in case of a success call, SolrClientNodeStateProvider always retry the > getting metrics request. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13450) Objects were not released error in CloudHttp2SolrClientTest and CloudSolrClientTest
[ https://issues.apache.org/jira/browse/SOLR-13450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat updated SOLR-13450: Description: This problem is get noticed first by [~hossman] in SOLR-13276, this seems appear most frequently in Windows box. I tried to get rid of this problem in SOLR-13339, but I'm still seeing the problems appear. was: This problem is get noticed first by [~hossman], this seems appear most frequently in Windows box. I tried to get rid of this problem in SOLR-13339, but I'm still seeing the problems appear. > Objects were not released error in CloudHttp2SolrClientTest and > CloudSolrClientTest > --- > > Key: SOLR-13450 > URL: https://issues.apache.org/jira/browse/SOLR-13450 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Priority: Major > > This problem is get noticed first by [~hossman] in SOLR-13276, this seems > appear most frequently in Windows box. > I tried to get rid of this problem in SOLR-13339, but I'm still seeing the > problems appear. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13276) Adding Http2 equivalent classes of CloudSolrClient and HttpClusterStateProvider
[ https://issues.apache.org/jira/browse/SOLR-13276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16834551#comment-16834551 ] Cao Manh Dat commented on SOLR-13276: - I may be wrong since the last commit only pushed to master and we have not seen any leaking problem for master branch since then, so probably that is the way for fixing the test failure. I will push the change to branch_8_1 and branch_8x as well and continue tracking the test. > Adding Http2 equivalent classes of CloudSolrClient and > HttpClusterStateProvider > > > Key: SOLR-13276 > URL: https://issues.apache.org/jira/browse/SOLR-13276 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Fix For: 8.1 > > Attachments: SOLR-13276.patch, SOLR-13276.patch, SOLR-13276.patch, > thetaphi-Lucene-Solr-master-Windows-7810.txt, > thetaphi_Lucene-Solr-8.x-Windows_69.log.txt, > thetaphi_Lucene-Solr-master-Windows_7754.log.txt > > > Before we can move on and wipe out the usage of apache httpclient inside > Solr-core. We need to create Http/2 equivalent classes of CloudSolrClient and > HttpClusterStateProvider -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13450) Objects were not released error in CloudHttp2SolrClientTest and CloudSolrClientTest
[ https://issues.apache.org/jira/browse/SOLR-13450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat updated SOLR-13450: Attachment: thetaphi-Lucene-Solr-8.1-Windows-92.txt > Objects were not released error in CloudHttp2SolrClientTest and > CloudSolrClientTest > --- > > Key: SOLR-13450 > URL: https://issues.apache.org/jira/browse/SOLR-13450 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Priority: Major > Attachments: thetaphi-Lucene-Solr-8.1-Windows-92.txt, > thetaphi-Lucene-Solr-master-Windows-7921.txt > > > This problem is get noticed first by [~hossman] in SOLR-13276, this seems > appear most frequently in Windows box. > I tried to get rid of this problem in SOLR-13339, but I'm still seeing the > problems appear. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13450) Objects were not released error in CloudHttp2SolrClientTest and CloudSolrClientTest
[ https://issues.apache.org/jira/browse/SOLR-13450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat updated SOLR-13450: Attachment: thetaphi-Lucene-Solr-master-Windows-7921.txt > Objects were not released error in CloudHttp2SolrClientTest and > CloudSolrClientTest > --- > > Key: SOLR-13450 > URL: https://issues.apache.org/jira/browse/SOLR-13450 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Priority: Major > Attachments: thetaphi-Lucene-Solr-8.1-Windows-92.txt, > thetaphi-Lucene-Solr-master-Windows-7921.txt > > > This problem is get noticed first by [~hossman] in SOLR-13276, this seems > appear most frequently in Windows box. > I tried to get rid of this problem in SOLR-13339, but I'm still seeing the > problems appear. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13450) Objects were not released error in CloudHttp2SolrClientTest and CloudSolrClientTest
Cao Manh Dat created SOLR-13450: --- Summary: Objects were not released error in CloudHttp2SolrClientTest and CloudSolrClientTest Key: SOLR-13450 URL: https://issues.apache.org/jira/browse/SOLR-13450 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Cao Manh Dat This problem is get noticed first by [~hossman], this seems appear most frequently in Windows box. I tried to get rid of this problem in SOLR-13339, but I'm still seeing the problems appear. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13276) Adding Http2 equivalent classes of CloudSolrClient and HttpClusterStateProvider
[ https://issues.apache.org/jira/browse/SOLR-13276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat resolved SOLR-13276. - Resolution: Fixed > Adding Http2 equivalent classes of CloudSolrClient and > HttpClusterStateProvider > > > Key: SOLR-13276 > URL: https://issues.apache.org/jira/browse/SOLR-13276 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Fix For: 8.1 > > Attachments: SOLR-13276.patch, SOLR-13276.patch, SOLR-13276.patch, > thetaphi-Lucene-Solr-master-Windows-7810.txt, > thetaphi_Lucene-Solr-8.x-Windows_69.log.txt, > thetaphi_Lucene-Solr-master-Windows_7754.log.txt > > > Before we can move on and wipe out the usage of apache httpclient inside > Solr-core. We need to create Http/2 equivalent classes of CloudSolrClient and > HttpClusterStateProvider -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13276) Adding Http2 equivalent classes of CloudSolrClient and HttpClusterStateProvider
[ https://issues.apache.org/jira/browse/SOLR-13276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16834533#comment-16834533 ] Cao Manh Dat commented on SOLR-13276: - I'm still seeing a thread leak problem in http://fucit.org/solr-jenkins-reports/job-data/thetaphi/Lucene-Solr-8.1-Windows/92/. But the chance here is 1/225, therefore I will open another issue for tracking the problem and close this one. > Adding Http2 equivalent classes of CloudSolrClient and > HttpClusterStateProvider > > > Key: SOLR-13276 > URL: https://issues.apache.org/jira/browse/SOLR-13276 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Fix For: 8.1 > > Attachments: SOLR-13276.patch, SOLR-13276.patch, SOLR-13276.patch, > thetaphi-Lucene-Solr-master-Windows-7810.txt, > thetaphi_Lucene-Solr-8.x-Windows_69.log.txt, > thetaphi_Lucene-Solr-master-Windows_7754.log.txt > > > Before we can move on and wipe out the usage of apache httpclient inside > Solr-core. We need to create Http/2 equivalent classes of CloudSolrClient and > HttpClusterStateProvider -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
