[jira] [Assigned] (SOLR-15154) Let Http2SolrClient pass Basic Auth credentials to all requests
[
https://issues.apache.org/jira/browse/SOLR-15154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe reassigned SOLR-15154:
Assignee: Tomas Eduardo Fernandez Lobbe
> Let Http2SolrClient pass Basic Auth credentials to all requests
> ---
>
> Key: SOLR-15154
> URL: https://issues.apache.org/jira/browse/SOLR-15154
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In {{HttpSolrClient}}, one could specify credentials [at the JVM
> level|https://lucene.apache.org/solr/guide/8_8/basic-authentication-plugin.html#global-jvm-basic-auth-credentials],
> and that would make all requests to Solr have them. This doesn't work with
> the Http2 clients case and I think it's very useful.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-15216) Invalid JS Object Key data.followers.currentData
[ https://issues.apache.org/jira/browse/SOLR-15216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Eduardo Fernandez Lobbe resolved SOLR-15216. -- Fix Version/s: 8.9 Resolution: Fixed Merged the PR. Thanks [~deanpearce]! > Invalid JS Object Key data.followers.currentData > > > Key: SOLR-15216 > URL: https://issues.apache.org/jira/browse/SOLR-15216 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 8.7, 8.8, 8.8.1 >Reporter: Dean Pearce >Priority: Major > Fix For: 8.9 > > Time Spent: 40m > Remaining Estimate: 0h > > Minor bug in the Admin UI Angular code, a line was changed to ` > settings.currentTime = parseDateToEpoch(data.follower.currentDate);` but the > underlying API still refers to `data.slave`. I believe this is fixed in the > master stream as the migration to the new leader/follower naming was > complete, but is broken in 8.x (8.7 an onwards). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-15216) Invalid JS Object Key data.followers.currentData
[ https://issues.apache.org/jira/browse/SOLR-15216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Eduardo Fernandez Lobbe updated SOLR-15216: - Priority: Minor (was: Major) > Invalid JS Object Key data.followers.currentData > > > Key: SOLR-15216 > URL: https://issues.apache.org/jira/browse/SOLR-15216 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 8.7, 8.8, 8.8.1 >Reporter: Dean Pearce >Priority: Minor > Fix For: 8.9 > > Time Spent: 40m > Remaining Estimate: 0h > > Minor bug in the Admin UI Angular code, a line was changed to ` > settings.currentTime = parseDateToEpoch(data.follower.currentDate);` but the > underlying API still refers to `data.slave`. I believe this is fixed in the > master stream as the migration to the new leader/follower naming was > complete, but is broken in 8.x (8.7 an onwards). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15155) Let CloudHttp2SolrClient accept an external Http2SolrClient Builder
[
https://issues.apache.org/jira/browse/SOLR-15155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17294873#comment-17294873
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-15155:
--
I linked a PR with the change suggestion. Note that this adds a new method to
the Builder's API:
{code:java}
public Builder withInternalClientBuilder(Http2SolrClient.Builder
internalClientBuilder)
{code}
It's optional and backwards compatible.
> Let CloudHttp2SolrClient accept an external Http2SolrClient Builder
> ---
>
> Key: SOLR-15155
> URL: https://issues.apache.org/jira/browse/SOLR-15155
> Project: Solr
> Issue Type: Improvement
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{CloudHttp2SolrClient}} doesn't provide much of the options that
> {{Http2SolrClient}} does (timeouts, max connections per hosts, etc).
> Technically it accepts a fully built {{Http2SolrClient}}, however, in such
> case the client becomes "external", which means it won't be closed when the
> CloudClient is closed (one needs to maintain a reference and close explicitly
> after closing CloudClient).
> {{CloudHttp2SolrClient}} will use an empty/default
> {{Http2SolrClient.Builder}} to build it's internal client. I propose we allow
> providing a configured {{Http2SolrClient.Builder}} instead and let the
> {{CloudHttp2SolrClient}} just build from it. This would be optional of
> course, and backwards compatible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14749) Provide a clean API for cluster-level event processing
[
https://issues.apache.org/jira/browse/SOLR-14749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17294211#comment-17294211
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14749:
--
[~dsmiley] brought up
[here|https://issues.apache.org/jira/browse/SOLR-14663?focusedCommentId=17293955=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17293955]
that {{TestContainerPlugin.testApi}} has been failing intermittently. I
believe the timeline and context of the failures aligns with the commit done in
Oct 21st for this Jira issue
> Provide a clean API for cluster-level event processing
> --
>
> Key: SOLR-14749
> URL: https://issues.apache.org/jira/browse/SOLR-14749
> Project: Solr
> Issue Type: Improvement
> Components: AutoScaling
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Labels: clean-api
> Fix For: master (9.0)
>
> Time Spent: 22h
> Remaining Estimate: 0h
>
> This is a companion issue to SOLR-14613 and it aims at providing a clean,
> strongly typed API for the functionality formerly known as "triggers" - that
> is, a component for generating cluster-level events corresponding to changes
> in the cluster state, and a pluggable API for processing these events.
> The 8x triggers have been removed so this functionality is currently missing
> in 9.0. However, this functionality is crucial for implementing the automatic
> collection repair and re-balancing as the cluster state changes (nodes going
> down / up, becoming overloaded / unused / decommissioned, etc).
> For this reason we need this API and a default implementation of triggers
> that at least can perform automatic collection repair (maintaining the
> desired replication factor in presence of live node changes).
> As before, the actual changes to the collections will be executed using
> existing CollectionAdmin API, which in turn may use the placement plugins
> from SOLR-14613.
> h3. Division of responsibility
> * built-in Solr components (non-pluggable):
> ** cluster state monitoring and event generation,
> ** simple scheduler to periodically generate scheduled events
> * plugins:
> ** automatic collection repair on {{nodeLost}} events (provided by default)
> ** re-balancing of replicas (periodic or on {{nodeAdded}} events)
> ** reporting (eg. requesting additional node provisioning)
> ** scheduled maintenance (eg. removing inactive shards after split)
> h3. Other considerations
> These plugins (unlike the placement plugins) need to execute on one
> designated node in the cluster. Currently the easiest way to implement this
> is to run them on the Overseer leader node.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15154) Let Http2SolrClient pass Basic Auth credentials to all requests
[
https://issues.apache.org/jira/browse/SOLR-15154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17294205#comment-17294205
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-15154:
--
Created a PR with the suggested changes. Note that it includes a new (optional)
method in the {{Http2SolrClient.Builder}}:
{code:java}
public Builder withBasicAuthCredentials(String user, String pass)
{code}
Other {{HttpClientBuilderFactory}} are also supported (similar to
HttpSolrClient}}, by passing a system property as we document in the ref guide.
> Let Http2SolrClient pass Basic Auth credentials to all requests
> ---
>
> Key: SOLR-15154
> URL: https://issues.apache.org/jira/browse/SOLR-15154
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In {{HttpSolrClient}}, one could specify credentials [at the JVM
> level|https://lucene.apache.org/solr/guide/8_8/basic-authentication-plugin.html#global-jvm-basic-auth-credentials],
> and that would make all requests to Solr have them. This doesn't work with
> the Http2 clients case and I think it's very useful.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14663) ConfigSets CREATE does not set trusted flag
[
https://issues.apache.org/jira/browse/SOLR-14663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293964#comment-17293964
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14663:
--
[~dsmiley], I believe you mixed up the tests (or I don't understand the
relation). You said {{TestConfigsApi}} is failing, but you point to
{{TestContainerPlugin.testApi}}, and I don't see any {{TestConfigsApi}} in
Hoss' report at all. Also, the dates don't match. The failures in
{{TestContainerPlugin.testApi}} started in Oct 22 (from what I can see in my
Jenkins emails), so most likely related to this commit:
https://issues.apache.org/jira/browse/SOLR-14749?focusedCommentId=17218444=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17218444
> ConfigSets CREATE does not set trusted flag
> ---
>
> Key: SOLR-14663
> URL: https://issues.apache.org/jira/browse/SOLR-14663
> Project: Solr
> Issue Type: Task
>Reporter: Andras Salamon
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Fix For: 8.6.3, 8.7, master (9.0)
>
> Attachments: SOLR-14663.patch, SOLR-14663.patch
>
>
> If I upload a configset using [ConfigSets
> API|https://lucene.apache.org/solr/guide/8_6/configsets-api.html] UPLOAD Solr
> sets the trusted flag. The config set will be trusted if authentication is
> enabled and the upload operation is performed as an authenticated request.
> On the other hand if I use the ConfigSets API CREATE which creates a new
> configset based on an already uploaded one, this flag will not be set, so the
> configset will be effectively untrusted.
> I don't really understand the difference here, I think CREATE API call should
> set this flag just like UPLOAD sets it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-15089) Allow backup/restoration to Amazon's S3 blobstore
[
https://issues.apache.org/jira/browse/SOLR-15089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17286747#comment-17286747
]
Tomas Eduardo Fernandez Lobbe edited comment on SOLR-15089 at 2/18/21, 10:08 PM:
-
{quote}But on the other hand I thought there was a certain amount of consensus
about net-new optional modules being created as plugins (and not contribs).
{quote}
I don't think there is a consensus for that? Some contribs were removed from
the code recently but I don't think that means no-more-contribs, I believe each
deserves it's own discussion, like the one we are having here. The closer there
is about this discussion in [the thread you
referenced|http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3Calpine.DEB.2.21.2101141026530.13436%40slate%3E],
and people isn't in favor of moving "first party plugins" out of Solr repo
{quote}I don't want to go against consensus just out of convenience.
{quote}
contribs are convenient, for you, for users, for other devs, which make them a
good option IMO. Again, I think there is specific discussion to be had about
each one of them (new and old), we certainly don't want to allow code dumps
that fall unsupported and largely unused.
{quote} # I don't want bloat in the main repository with code that is clearly
optional to the search engine. solr-sandbox or solr-extras is better,
IMHO.{quote}
I understand Ishan, but that is exactly the discussion going on in the dev list
thread linked above. Most people agree that these first party
plugins/modules/contribs are better off with the Solr code, for various reasons
stated there.
{quote} # I don't want to be blocked on committing something to the main
repository, just because it breaks tests in s3mock, S3 support etc.{quote}
I know that it may be annoying for a feature you don't want/use/need. I see
failures for features I don't use all the time, but that's exactly what
supporting a feature means. We want to know in advance if a change in Solr is
breaking our officially supported plugins, and we don't want to release a Solr
version that inadvertently breaks things we support. I want our testing to
prevent it.
{quote}I would like to see a situation where we have a "main" solr download
that is a third of the current download size, or smaller if possible. That
download would only include core functionality, no bells or whistles. On the
code side, there should be a main repository that builds the main download. We
would need to decide whether we want individual repositories for other
components, or one big "plugins" repository. The same decision would need to
be made for the release side – one big plugins download, or a bunch of small
ones. I can see advantages and disadvantages to either approach.
{quote}
This is the discussion going on
[here|http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3Calpine.DEB.2.21.2101141026530.13436%40slate%3E]
right now. Docker already has a "slim" and a "fat" distribution, we can
certainly do that with Solr tars too if we want (I do believe we aren't there
yet, see my comment
[here|https://issues.apache.org/jira/browse/SOLR-14688?focusedCommentId=17246314=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17246314]).
But again, I don't think we should block this work until that decision is made.
This particular feature has been requested multiple times, different users have
had to built their own, it's obviously something people want and need, lets
have it!
was (Author: tomasflobbe):
{quote}But on the other hand I thought there was a certain amount of consensus
about net-new optional modules being created as plugins (and not contribs).
{quote}
I don't think there is a consensus for that? Some contribs were removed from
the code recently but I don't think that means no-more-contribs, I believe each
deserves it's own discussion, like the one we are having here. The closer there
is about this discussion in [the thread you
referenced|http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3Calpine.DEB.2.21.2101141026530.13436%40slate%3E],
and people isn't in favor of moving "first party plugins" out of Solr repo
{quote}I don't want to go against consensus just out of convenience.
{quote}
contribs are convenient, for you, for users, for other devs, which make them a
good option IMO. Again, I think there is specific discussion to be had about
each one of them (new and old), we certainly don't want to allow code dumps
that fall unsupported and largely unused.
{quote} # I don't want bloat in the main repository with code that is clearly
optional to the search engine. solr-sandbox or solr-extras is better,
IMHO.{quote}
I understand Ishan, but that is exactly the discussion going on in the dev list
thread linked above. Most people agree that these first party
[jira] [Comment Edited] (SOLR-15089) Allow backup/restoration to Amazon's S3 blobstore
[
https://issues.apache.org/jira/browse/SOLR-15089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17286747#comment-17286747
]
Tomas Eduardo Fernandez Lobbe edited comment on SOLR-15089 at 2/18/21, 10:02 PM:
-
{quote}But on the other hand I thought there was a certain amount of consensus
about net-new optional modules being created as plugins (and not contribs).
{quote}
I don't think there is a consensus for that? Some contribs were removed from
the code recently but I don't think that means no-more-contribs, I believe each
deserves it's own discussion, like the one we are having here. The closer there
is about this discussion in [the thread you
referenced|http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3Calpine.DEB.2.21.2101141026530.13436%40slate%3E],
and people isn't in favor of moving "first party plugins" out of Solr repo
{quote}I don't want to go against consensus just out of convenience.
{quote}
contribs are convenient, for you, for users, for other devs, which make them a
good option IMO. Again, I think there is specific discussion to be had about
each one of them (new and old), we certainly don't want to allow code dumps
that fall unsupported and largely unused.
{quote} # I don't want bloat in the main repository with code that is clearly
optional to the search engine. solr-sandbox or solr-extras is better,
IMHO.{quote}
I understand Ishan, but that is exactly the discussion going on in the dev list
thread linked above. Most people agree that these first party
plugins/modules/contribs are better off with the Solr code, for various reasons
stated there.
{quote} # I don't want to be blocked on committing something to the main
repository, just because it breaks tests in s3mock, S3 support etc.{quote}
I know that it may be annoying for a feature you don't want/use/need. I see
failures for features I don't use all the time, but that's exactly what
supporting a feature means. We want to know in advance if a change in Solr is
breaking our officially supported plugins, and we don't want to release a Solr
version that inadvertently breaks things we support. I want our testing to
prevent it.
{quote}I would like to see a situation where we have a "main" solr download
that is a third of the current download size, or smaller if possible. That
download would only include core functionality, no bells or whistles. On the
code side, there should be a main repository that builds the main download. We
would need to decide whether we want individual repositories for other
components, or one big "plugins" repository. The same decision would need to
be made for the release side – one big plugins download, or a bunch of small
ones. I can see advantages and disadvantages to either approach.
{quote}
This is the discussion going on
[here|http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3Calpine.DEB.2.21.2101141026530.13436%40slate%3E]
right now. Docker already has a "slim" and a "fat" distribution, we can
certainly do that with Solr tars too if we want (I do believe we aren't there
yet, see my comment here). But again, I don't think we should block this work
until that decision is made.
This particular feature has been requested multiple times, different users have
had to built their own, it's obviously something people want and need, lets
have it!
was (Author: tomasflobbe):
{quote}But on the other hand I thought there was a certain amount of consensus
about net-new optional modules being created as plugins (and not contribs).
{quote}
I don't think there is a consensus for that? Some contribs were removed from
the code recently but I don't think that means no-more-contribs, I believe each
deserves it's own discussion, like the one we are having here. The closer there
is about this discussion in [the thread you
referenced|http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3Calpine.DEB.2.21.2101141026530.13436%40slate%3E],
and people isn't in favor of moving "first party plugins" out of Solr repo
{quote}I don't want to go against consensus just out of convenience.
{quote}
contribs are convenient, for you, for users, for other devs, which make them a
good option IMO. Again, I think there is specific discussion to be had about
each one of them (new and old), we certainly don't want to allow code dumps
that fall unsupported and largely unused.
{quote}# I don't want bloat in the main repository with code that is clearly
optional to the search engine. solr-sandbox or solr-extras is better, IMHO.
{quote}
I understand Ishan, but that is exactly the discussion going on in the dev list
thread linked above. Most people agree that these first party
plugins/modules/contribs are better off with the Solr code, for various reasons
stated there.
{quote}# I don't want to be blocked on committing something to the main
[jira] [Commented] (SOLR-15089) Allow backup/restoration to Amazon's S3 blobstore
[
https://issues.apache.org/jira/browse/SOLR-15089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17286747#comment-17286747
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-15089:
--
{quote}But on the other hand I thought there was a certain amount of consensus
about net-new optional modules being created as plugins (and not contribs).
{quote}
I don't think there is a consensus for that? Some contribs were removed from
the code recently but I don't think that means no-more-contribs, I believe each
deserves it's own discussion, like the one we are having here. The closer there
is about this discussion in [the thread you
referenced|http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3Calpine.DEB.2.21.2101141026530.13436%40slate%3E],
and people isn't in favor of moving "first party plugins" out of Solr repo
{quote}I don't want to go against consensus just out of convenience.
{quote}
contribs are convenient, for you, for users, for other devs, which make them a
good option IMO. Again, I think there is specific discussion to be had about
each one of them (new and old), we certainly don't want to allow code dumps
that fall unsupported and largely unused.
{quote}# I don't want bloat in the main repository with code that is clearly
optional to the search engine. solr-sandbox or solr-extras is better, IMHO.
{quote}
I understand Ishan, but that is exactly the discussion going on in the dev list
thread linked above. Most people agree that these first party
plugins/modules/contribs are better off with the Solr code, for various reasons
stated there.
{quote}# I don't want to be blocked on committing something to the main
repository, just because it breaks tests in s3mock, S3 support etc.
{quote}
I know that it may be annoying for a feature you don't want/use/need. I see
failures for features I don't use all the time, but that's exactly what
supporting a feature means. We want to know in advance if a change in Solr is
breaking our officially supported plugins, and we don't want to release a Solr
version that inadvertently breaks things we support. I want our testing to
prevent it.
{quote}I would like to see a situation where we have a "main" solr download
that is a third of the current download size, or smaller if possible. That
download would only include core functionality, no bells or whistles. On the
code side, there should be a main repository that builds the main download. We
would need to decide whether we want individual repositories for other
components, or one big "plugins" repository. The same decision would need to
be made for the release side – one big plugins download, or a bunch of small
ones. I can see advantages and disadvantages to either approach.
{quote}
This is the discussion going on
[here|http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3Calpine.DEB.2.21.2101141026530.13436%40slate%3E]
right now. Docker already has a "slim" and a "fat" distribution, we can
certainly do that with Solr tars too if we want (I do believe we aren't there
yet, see my comment here). But again, I don't think we should block this work
until that decision is made. This particular feature has been requested
multiple times, different users have had to built their own, it's obviously
something people want and need, lets have it!
> Allow backup/restoration to Amazon's S3 blobstore
> --
>
> Key: SOLR-15089
> URL: https://issues.apache.org/jira/browse/SOLR-15089
> Project: Solr
> Issue Type: Sub-task
>Reporter: Jason Gerlowski
>Priority: Major
>
> Solr's BackupRepository interface provides an abstraction around the physical
> location/format that backups are stored in. This allows plugin writers to
> create "repositories" for a variety of storage mediums. It'd be nice if Solr
> offered more mediums out of the box though, such as some of the "blobstore"
> offerings provided by various cloud providers.
> This ticket proposes that a "BackupRepository" implementation for Amazon's
> popular 'S3' blobstore, so that Solr users can use it for backups without
> needing to write their own code.
> Amazon offers a s3 Java client with acceptable licensing, and the required
> code is relatively simple. The biggest challenge in supporting this will
> likely be procedural - integration testing requires S3 access and S3 access
> costs money. We can check with INFRA to see if there is any way to get cloud
> credits for an integration test to run in nightly Jenkins runs on the ASF
> Jenkins server. Alternatively we can try to stub out the blobstore in some
> reliable way.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail:
[jira] [Commented] (SOLR-15089) Allow backup/restoration to Amazon's S3 blobstore
[ https://issues.apache.org/jira/browse/SOLR-15089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17286626#comment-17286626 ] Tomas Eduardo Fernandez Lobbe commented on SOLR-15089: -- I think most people in that thread agree that the best place for plugins that need to be developed and released with Solr is the Solr repo itself. Honestly, I feel this should just be a contrib, the same as the existing ones. There is SOLR-14688 for discussing if we want to move to a different strategy. Let's get S3 backup support in Solr first, it's obviously a very important feature that everyone seems to be building on their own these days. bq. or one of the parallel tickets for GCS or Azure Wondering if this implementation using the S3 client could just work with GCS? https://cloud.google.com/storage/docs/migrating#migration-simple > Allow backup/restoration to Amazon's S3 blobstore > -- > > Key: SOLR-15089 > URL: https://issues.apache.org/jira/browse/SOLR-15089 > Project: Solr > Issue Type: Sub-task >Reporter: Jason Gerlowski >Priority: Major > > Solr's BackupRepository interface provides an abstraction around the physical > location/format that backups are stored in. This allows plugin writers to > create "repositories" for a variety of storage mediums. It'd be nice if Solr > offered more mediums out of the box though, such as some of the "blobstore" > offerings provided by various cloud providers. > This ticket proposes that a "BackupRepository" implementation for Amazon's > popular 'S3' blobstore, so that Solr users can use it for backups without > needing to write their own code. > Amazon offers a s3 Java client with acceptable licensing, and the required > code is relatively simple. The biggest challenge in supporting this will > likely be procedural - integration testing requires S3 access and S3 access > costs money. We can check with INFRA to see if there is any way to get cloud > credits for an integration test to run in nightly Jenkins runs on the ASF > Jenkins server. Alternatively we can try to stub out the blobstore in some > reliable way. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15154) Let Http2SolrClient pass Basic Auth credentials to all requests
[
https://issues.apache.org/jira/browse/SOLR-15154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17286106#comment-17286106
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-15154:
--
OK, I've spent much more time looking at this than what I was expecting to, and
I'm still not 100% clear what's the best path forward. We have the
{{PreemptiveBasicAuthClientBuilderFactory}} class for setting up the basic auth
credentials in the case of using the System props as documented
[here|https://lucene.apache.org/solr/guide/8_8/basic-authentication-plugin.html#global-jvm-basic-auth-credentials].
It looks like this class was created for the older HttpClient, and adapted
later to also work for the jetty http2 one (but It doesn't seem to be used
right now, thus, this Jira issue). When the {{setup}} method in this class is
called, it'll do this:
{code:java}
HttpAuthenticationStore authenticationStore = new HttpAuthenticationStore();
authenticationStore.addAuthentication(new
SolrBasicAuthentication(basicAuthUser, basicAuthPass));
client.getHttpClient().setAuthenticationStore(authenticationStore);
client.getProtocolHandlers().put(new
WWWAuthenticationProtocolHandler(client.getHttpClient()));
client.getProtocolHandlers().put(new
ProxyAuthenticationProtocolHandler(client.getHttpClient()));
{code}
My understanding (and if someone has pointers to good docs on this, please let
me know, I couldn't find much) is that this will instruct the client to attempt
authentication using {{basicAuthUser}} and {{basicAuthPass}} after a 401 is
received from the server. It'll then cache the server and from then on, send
the authentication headers in advance to that particular server. This will
repeat for each different Solr server.
For explicit credentials (set on the request), we do something much more
straightforward, we manually add the header on the request:
{code:java}
private void setBasicAuthHeader(@SuppressWarnings({"rawtypes"})SolrRequest
solrRequest, Request req) {
if (solrRequest.getBasicAuthUser() != null &&
solrRequest.getBasicAuthPassword() != null) {
String userPass = solrRequest.getBasicAuthUser() + ":" +
solrRequest.getBasicAuthPassword();
String encoded =
Base64.byteArrayToBase64(userPass.getBytes(FALLBACK_CHARSET));
req.header("Authorization", "Basic " + encoded);
}
{code}
I'm wondering why we need to go through the authentication store for a
client-wide auth configuration instead of just adding the header like we do for
explicit authentication requests? Something like:
{code:java}
private void setBasicAuthHeader(@SuppressWarnings({"rawtypes"})SolrRequest
solrRequest, Request req) {
if (solrRequest.getBasicAuthUser() != null &&
solrRequest.getBasicAuthPassword() != null) {
String encoded =
basicAuthCredentialsToAuthorizationString(solrRequest.getBasicAuthUser(),
solrRequest.getBasicAuthPassword());
req.header("Authorization", encoded);
} else if (this.basicAuthAuthorizationStr != null) {
req.header("Authorization", this.basicAuthAuthorizationStr);
}
}
{code}
where {{this.basicAuthAuthorizationStr}} is set via the builder?
> Let Http2SolrClient pass Basic Auth credentials to all requests
> ---
>
> Key: SOLR-15154
> URL: https://issues.apache.org/jira/browse/SOLR-15154
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Minor
>
> In {{HttpSolrClient}}, one could specify credentials [at the JVM
> level|https://lucene.apache.org/solr/guide/8_8/basic-authentication-plugin.html#global-jvm-basic-auth-credentials],
> and that would make all requests to Solr have them. This doesn't work with
> the Http2 clients case and I think it's very useful.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14510) Remove deprecations added with the BlockMax WAND support
[ https://issues.apache.org/jira/browse/SOLR-14510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Eduardo Fernandez Lobbe resolved SOLR-14510. -- Fix Version/s: master (9.0) Assignee: Tomas Eduardo Fernandez Lobbe Resolution: Fixed > Remove deprecations added with the BlockMax WAND support > > > Key: SOLR-14510 > URL: https://issues.apache.org/jira/browse/SOLR-14510 > Project: Solr > Issue Type: Improvement >Affects Versions: master (9.0) >Reporter: Tomas Eduardo Fernandez Lobbe >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Minor > Fix For: master (9.0) > > Time Spent: 40m > Remaining Estimate: 0h > > I'd like to remove some of the deprecations added by the work in SOLR-132899. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-15155) Let CloudHttp2SolrClient accept an external Http2SolrClient Builder
Tomas Eduardo Fernandez Lobbe created SOLR-15155:
Summary: Let CloudHttp2SolrClient accept an external
Http2SolrClient Builder
Key: SOLR-15155
URL: https://issues.apache.org/jira/browse/SOLR-15155
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Tomas Eduardo Fernandez Lobbe
{{CloudHttp2SolrClient}} doesn't provide much of the options that
{{Http2SolrClient}} does (timeouts, max connections per hosts, etc).
Technically it accepts a fully built {{Http2SolrClient}}, however, in such case
the client becomes "external", which means it won't be closed when the
CloudClient is closed (one needs to maintain a reference and close explicitly
after closing CloudClient).
{{CloudHttp2SolrClient}} will use an empty/default {{Http2SolrClient.Builder}}
to build it's internal client. I propose we allow providing a configured
{{Http2SolrClient.Builder}} instead and let the {{CloudHttp2SolrClient}} just
build from it. This would be optional of course, and backwards compatible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-15154) Let Http2SolrClient pass Basic Auth credentials to all requests
Tomas Eduardo Fernandez Lobbe created SOLR-15154:
Summary: Let Http2SolrClient pass Basic Auth credentials to all
requests
Key: SOLR-15154
URL: https://issues.apache.org/jira/browse/SOLR-15154
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: SolrJ
Reporter: Tomas Eduardo Fernandez Lobbe
In {{HttpSolrClient}}, one could specify credentials [at the JVM
level|https://lucene.apache.org/solr/guide/8_8/basic-authentication-plugin.html#global-jvm-basic-auth-credentials],
and that would make all requests to Solr have them. This doesn't work with the
Http2 clients case and I think it's very useful.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-15114) WAND does not work correctly on multiple segments in Solr 8.6.3
[ https://issues.apache.org/jira/browse/SOLR-15114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Eduardo Fernandez Lobbe updated SOLR-15114: - Affects Version/s: (was: 8.6.3) (was: master (9.0)) 8.8 8.6 8.7 > WAND does not work correctly on multiple segments in Solr 8.6.3 > --- > > Key: SOLR-15114 > URL: https://issues.apache.org/jira/browse/SOLR-15114 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.6, 8.7, 8.8 >Reporter: Naoto Minami >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Blocker > Fix For: master (9.0), 8.9, 8.8.1 > > Attachments: wand.pdf > > Time Spent: 20m > Remaining Estimate: 0h > > In Solr 8.6.3, minCompetitiveScore of WANDScorer resets to zero for each > index segment and remain zero until maxScore is updated. > There are two causes of this problem: > - MaxScoreCollector does not set minCompetitiveScore of > MinCompetitiveScoreAwareScorable newly generated for another index segment. > - MaxScoreCollector updates minCompetitiveScore only if maxScore is updated. > This behavior is correct considering the purpose of MaxScoreCollector. > For details, see the attached pdf. > *Note* > This problem occurs in distributed search (SolrCloud) or the fl=score > parameter specified. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-15114) WAND does not work correctly on multiple segments in Solr 8.6.3
[ https://issues.apache.org/jira/browse/SOLR-15114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Eduardo Fernandez Lobbe updated SOLR-15114: - Fix Version/s: 8.9 Resolution: Fixed Status: Resolved (was: Patch Available) Merged. Thanks [~nminami]! > WAND does not work correctly on multiple segments in Solr 8.6.3 > --- > > Key: SOLR-15114 > URL: https://issues.apache.org/jira/browse/SOLR-15114 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.6.3, master (9.0) >Reporter: Naoto Minami >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Blocker > Fix For: master (9.0), 8.9, 8.8.1 > > Attachments: wand.pdf > > Time Spent: 20m > Remaining Estimate: 0h > > In Solr 8.6.3, minCompetitiveScore of WANDScorer resets to zero for each > index segment and remain zero until maxScore is updated. > There are two causes of this problem: > - MaxScoreCollector does not set minCompetitiveScore of > MinCompetitiveScoreAwareScorable newly generated for another index segment. > - MaxScoreCollector updates minCompetitiveScore only if maxScore is updated. > This behavior is correct considering the purpose of MaxScoreCollector. > For details, see the attached pdf. > *Note* > This problem occurs in distributed search (SolrCloud) or the fl=score > parameter specified. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-15114) WAND does not work correctly on multiple segments in Solr 8.6.3
[
https://issues.apache.org/jira/browse/SOLR-15114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17282783#comment-17282783
]
Tomas Eduardo Fernandez Lobbe edited comment on SOLR-15114 at 2/11/21, 5:08 PM:
I've run a perf test on the change using Gatling:
* Using a wikipedia snapshot (20M docs, shortened to 1k characters)
* Using Mike McCandless [query
set|https://github.com/mikemccand/luceneutil/blob/master/tasks/wikimedium.10M.tasks]
* 10k queries per type (180k queries total)
* 2 shards, 1 replica each (on the same node).
* Each shard has ~30 segments
* search on the article body
* 10 parallel users
* Single Solr instance (iMac Pro 3.2 GHz 8-Core Intel Xeon W with 128 GB RAM).
* Gatling running in the machine
* The default example Solr parameters
* Always used {{rows=2}}, in the case of WAND I also added {{minExactCount=2}}
While there is some noise in the tests (I'd expect master WAND, master no-WAND
and patch no-WAND to perform similarly), the WAND scenario with the patch
applied is definitely faster:
||Stat||master WAND||master no-WAND||patch WAND||patch no-WAND||
|QPS|97.72|103.687|153.061|111.732|
|min|1|1|1|1|
|p50|39|39|23|36|
|p75|102|95|57|87|
|p95|387|350|245|322|
|p99|829|809|668|769|
|max|2405|2416|1331|2447|
|mean|95|89|59|82|
|std dev|155|147|110|139|
was (Author: tomasflobbe):
I've run a perf test on the change using Gatling:
* Using a wikipedia snapshot (20M docs, shortened to 1k characters)
* Using Mike McCandless [query
set|https://github.com/mikemccand/luceneutil/blob/master/tasks/wikimedium.10M.tasks]
* 10k queries per type (18k queries total)
* 2 shards, 1 replica each (on the same node).
* Each shard has ~30 segments
* search on the article body
* 10 parallel users
* Single Solr instance (iMac Pro 3.2 GHz 8-Core Intel Xeon W with 128 GB RAM).
* Gatling running in the machine
* The default example Solr parameters
* Always used {{rows=2}}, in the case of WAND I also added {{minExactCount=2}}
While there is some noise in the tests (I'd expect master WAND, master no-WAND
and patch no-WAND to perform similarly), the WAND scenario with the patch
applied is definitely faster:
||Stat||master WAND||master no-WAND||patch WAND||patch no-WAND||
|QPS|97.72|103.687|153.061|111.732|
|min|1|1|1|1|
|p50|39|39|23|36|
|p75|102|95|57|87|
|p95|387|350|245|322|
|p99|829|809|668|769|
|max|2405|2416|1331|2447|
|mean|95|89|59|82|
|std dev|155|147|110|139|
> WAND does not work correctly on multiple segments in Solr 8.6.3
> ---
>
> Key: SOLR-15114
> URL: https://issues.apache.org/jira/browse/SOLR-15114
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.6.3, master (9.0)
>Reporter: Naoto Minami
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Blocker
> Fix For: master (9.0), 8.8.1
>
> Attachments: wand.pdf
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In Solr 8.6.3, minCompetitiveScore of WANDScorer resets to zero for each
> index segment and remain zero until maxScore is updated.
> There are two causes of this problem:
> - MaxScoreCollector does not set minCompetitiveScore of
> MinCompetitiveScoreAwareScorable newly generated for another index segment.
> - MaxScoreCollector updates minCompetitiveScore only if maxScore is updated.
> This behavior is correct considering the purpose of MaxScoreCollector.
> For details, see the attached pdf.
> *Note*
> This problem occurs in distributed search (SolrCloud) or the fl=score
> parameter specified.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15114) WAND does not work correctly on multiple segments in Solr 8.6.3
[
https://issues.apache.org/jira/browse/SOLR-15114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17282783#comment-17282783
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-15114:
--
I've run a perf test on the change using Gatling:
* Using a wikipedia snapshot (20M docs, shortened to 1k characters)
* Using Mike McCandless [query
set|https://github.com/mikemccand/luceneutil/blob/master/tasks/wikimedium.10M.tasks]
* 10k queries per type (18k queries total)
* 2 shards, 1 replica each (on the same node).
* Each shard has ~30 segments
* search on the article body
* 10 parallel users
* Single Solr instance (iMac Pro 3.2 GHz 8-Core Intel Xeon W with 128 GB RAM).
* Gatling running in the machine
* The default example Solr parameters
* Always used {{rows=2}}, in the case of WAND I also added {{minExactCount=2}}
While there is some noise in the tests (I'd expect master WAND, master no-WAND
and patch no-WAND to perform similarly), the WAND scenario with the patch
applied is definitely faster:
||Stat||master WAND||master no-WAND||patch WAND||patch no-WAND||
|QPS|97.72|103.687|153.061|111.732|
|min|1|1|1|1|
|p50|39|39|23|36|
|p75|102|95|57|87|
|p95|387|350|245|322|
|p99|829|809|668|769|
|max|2405|2416|1331|2447|
|mean|95|89|59|82|
|std dev|155|147|110|139|
> WAND does not work correctly on multiple segments in Solr 8.6.3
> ---
>
> Key: SOLR-15114
> URL: https://issues.apache.org/jira/browse/SOLR-15114
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.6.3, master (9.0)
>Reporter: Naoto Minami
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Blocker
> Fix For: master (9.0), 8.8.1
>
> Attachments: wand.pdf
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In Solr 8.6.3, minCompetitiveScore of WANDScorer resets to zero for each
> index segment and remain zero until maxScore is updated.
> There are two causes of this problem:
> - MaxScoreCollector does not set minCompetitiveScore of
> MinCompetitiveScoreAwareScorable newly generated for another index segment.
> - MaxScoreCollector updates minCompetitiveScore only if maxScore is updated.
> This behavior is correct considering the purpose of MaxScoreCollector.
> For details, see the attached pdf.
> *Note*
> This problem occurs in distributed search (SolrCloud) or the fl=score
> parameter specified.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15114) WAND does not work correctly on multiple segments in Solr 8.6.3
[
https://issues.apache.org/jira/browse/SOLR-15114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17281428#comment-17281428
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-15114:
--
bq. Can we have a test for the optimization itself somehow?
I remember looking when this was implemented and I couldn't find a way to
really assert if the optimization was being applied, I'll take another look,
but let me know if you have any idea. Maybe [~jpountz]? In this particular
case, even the {{ImpactDISI}} would have been used, except that the skipping
would have been very sub-optimal.
bq. was this bug here from the beginning when Solr added support for the
optimization, or it it unique to 8.6.3, or some release inbetween?
This has been like this since 8.6.0: SOLR-14554
> WAND does not work correctly on multiple segments in Solr 8.6.3
> ---
>
> Key: SOLR-15114
> URL: https://issues.apache.org/jira/browse/SOLR-15114
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.6.3, master (9.0)
>Reporter: Naoto Minami
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Blocker
> Fix For: master (9.0), 8.8.1
>
> Attachments: wand.pdf
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In Solr 8.6.3, minCompetitiveScore of WANDScorer resets to zero for each
> index segment and remain zero until maxScore is updated.
> There are two causes of this problem:
> - MaxScoreCollector does not set minCompetitiveScore of
> MinCompetitiveScoreAwareScorable newly generated for another index segment.
> - MaxScoreCollector updates minCompetitiveScore only if maxScore is updated.
> This behavior is correct considering the purpose of MaxScoreCollector.
> For details, see the attached pdf.
> *Note*
> This problem occurs in distributed search (SolrCloud) or the fl=score
> parameter specified.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-15114) WAND does not work correctly on multiple segments in Solr 8.6.3
[ https://issues.apache.org/jira/browse/SOLR-15114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Eduardo Fernandez Lobbe updated SOLR-15114: - Priority: Blocker (was: Major) > WAND does not work correctly on multiple segments in Solr 8.6.3 > --- > > Key: SOLR-15114 > URL: https://issues.apache.org/jira/browse/SOLR-15114 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.6.3, master (9.0) >Reporter: Naoto Minami >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Blocker > Fix For: master (9.0), 8.8.1 > > Attachments: wand.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > In Solr 8.6.3, minCompetitiveScore of WANDScorer resets to zero for each > index segment and remain zero until maxScore is updated. > There are two causes of this problem: > - MaxScoreCollector does not set minCompetitiveScore of > MinCompetitiveScoreAwareScorable newly generated for another index segment. > - MaxScoreCollector updates minCompetitiveScore only if maxScore is updated. > This behavior is correct considering the purpose of MaxScoreCollector. > For details, see the attached pdf. > *Note* > This problem occurs in distributed search (SolrCloud) or the fl=score > parameter specified. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-15114) WAND does not work correctly on multiple segments in Solr 8.6.3
[ https://issues.apache.org/jira/browse/SOLR-15114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Eduardo Fernandez Lobbe updated SOLR-15114: - Fix Version/s: 8.8.1 master (9.0) > WAND does not work correctly on multiple segments in Solr 8.6.3 > --- > > Key: SOLR-15114 > URL: https://issues.apache.org/jira/browse/SOLR-15114 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.6.3, master (9.0) >Reporter: Naoto Minami >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Major > Fix For: master (9.0), 8.8.1 > > Attachments: wand.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > In Solr 8.6.3, minCompetitiveScore of WANDScorer resets to zero for each > index segment and remain zero until maxScore is updated. > There are two causes of this problem: > - MaxScoreCollector does not set minCompetitiveScore of > MinCompetitiveScoreAwareScorable newly generated for another index segment. > - MaxScoreCollector updates minCompetitiveScore only if maxScore is updated. > This behavior is correct considering the purpose of MaxScoreCollector. > For details, see the attached pdf. > *Note* > This problem occurs in distributed search (SolrCloud) or the fl=score > parameter specified. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15114) WAND does not work correctly on multiple segments in Solr 8.6.3
[ https://issues.apache.org/jira/browse/SOLR-15114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17281316#comment-17281316 ] Tomas Eduardo Fernandez Lobbe commented on SOLR-15114: -- Thanks for reporting [~nminami]. I think your assessment is correct (introduced in SOLR-14554). From the looks of it, the bug doesn't cause incorrect results, but breaks the optimization. I want to run some tests before merging, but the PR LGTM. > WAND does not work correctly on multiple segments in Solr 8.6.3 > --- > > Key: SOLR-15114 > URL: https://issues.apache.org/jira/browse/SOLR-15114 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.6.3, master (9.0) >Reporter: Naoto Minami >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Major > Attachments: wand.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > In Solr 8.6.3, minCompetitiveScore of WANDScorer resets to zero for each > index segment and remain zero until maxScore is updated. > There are two causes of this problem: > - MaxScoreCollector does not set minCompetitiveScore of > MinCompetitiveScoreAwareScorable newly generated for another index segment. > - MaxScoreCollector updates minCompetitiveScore only if maxScore is updated. > This behavior is correct considering the purpose of MaxScoreCollector. > For details, see the attached pdf. > *Note* > This problem occurs in distributed search (SolrCloud) or the fl=score > parameter specified. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-15114) WAND does not work correctly on multiple segments in Solr 8.6.3
[ https://issues.apache.org/jira/browse/SOLR-15114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Eduardo Fernandez Lobbe reassigned SOLR-15114: Assignee: Tomas Eduardo Fernandez Lobbe > WAND does not work correctly on multiple segments in Solr 8.6.3 > --- > > Key: SOLR-15114 > URL: https://issues.apache.org/jira/browse/SOLR-15114 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.6.3, master (9.0) >Reporter: Naoto Minami >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Major > Attachments: wand.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > In Solr 8.6.3, minCompetitiveScore of WANDScorer resets to zero for each > index segment and remain zero until maxScore is updated. > There are two causes of this problem: > - MaxScoreCollector does not set minCompetitiveScore of > MinCompetitiveScoreAwareScorable newly generated for another index segment. > - MaxScoreCollector updates minCompetitiveScore only if maxScore is updated. > This behavior is correct considering the purpose of MaxScoreCollector. > For details, see the attached pdf. > *Note* > This problem occurs in distributed search (SolrCloud) or the fl=score > parameter specified. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-6059) Basic support for Cross-Origin resource sharing (CORS) in search requests
[
https://issues.apache.org/jira/browse/SOLR-6059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17271758#comment-17271758
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-6059:
-
In this Jira, the idea was to allow CORS in search requests only via a
{{SearchComponent}} (the main use was for an autocomplete feature), so it's
unrelated to the V1/V2 admin APIs. Not sure if this is the right approach
compared to the {{web.xml}} changes suggested in SOLR-12292.
> Basic support for Cross-Origin resource sharing (CORS) in search requests
> -
>
> Key: SOLR-6059
> URL: https://issues.apache.org/jira/browse/SOLR-6059
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 4.9, 6.0
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Attachments: SOLR-6059.patch
>
>
> Support cross-origin requests to specific search request handlers.
> See http://www.w3.org/TR/cors
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14723) Rremove the class atribute for the caches in the _default/example configsets
[
https://issues.apache.org/jira/browse/SOLR-14723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe resolved SOLR-14723.
--
Fix Version/s: 8.8
Resolution: Fixed
> Rremove the class atribute for the caches in the _default/example configsets
>
>
> Key: SOLR-14723
> URL: https://issues.apache.org/jira/browse/SOLR-14723
> Project: Solr
> Issue Type: Improvement
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Trivial
> Labels: newdev
> Fix For: 8.8
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> In 8.x branch, the default and example configsets include LRUCache and
> FastLRUCache as the implementation for the various caches.
> {code:xml}
> size="512"
> initialSize="512"
> autowarmCount="0"/>
> {code}
> Those implementations are deprecated. We should remove the attribute
> completely and let the default take over (as it's in master), this should
> make upgrading configsets easier:
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14723) Rremove the class atribute for the caches in the _default/example configsets
[
https://issues.apache.org/jira/browse/SOLR-14723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256367#comment-17256367
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14723:
--
Thanks [~trdillon], merged the PR. And thanks [~shshnk28] for the initial
contribution.
> Rremove the class atribute for the caches in the _default/example configsets
>
>
> Key: SOLR-14723
> URL: https://issues.apache.org/jira/browse/SOLR-14723
> Project: Solr
> Issue Type: Improvement
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Trivial
> Labels: newdev
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> In 8.x branch, the default and example configsets include LRUCache and
> FastLRUCache as the implementation for the various caches.
> {code:xml}
> size="512"
> initialSize="512"
> autowarmCount="0"/>
> {code}
> Those implementations are deprecated. We should remove the attribute
> completely and let the default take over (as it's in master), this should
> make upgrading configsets easier:
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-14723) Rremove the class atribute for the caches in the _default/example configsets
[
https://issues.apache.org/jira/browse/SOLR-14723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe updated SOLR-14723:
-
Comment: was deleted
(was: Commit 196632d538a26b0c92a67941ad7c47e2f9cd2e1d in lucene-solr's branch
refs/heads/branch_8x from Tomas Eduardo Fernandez Lobbe
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=196632d ]
SOLR-14723: Remove the class attribute for the caches in the _default/example
configsets
This is an 8.x change only. Closes #2169
Squashed commit of the following:
commit c638cbcfdb58b57cde8c4be641a7847b8a37422a
Merge: b13011e97ae a22abe8ae0d
Author: Tomas Fernandez Lobbe
Date: Tue Dec 29 23:33:38 2020 -0800
Merge branch 'jira/SOLR-14723' of https://github.com/trdillon/lucene-solr
into trdillon-jira/SOLR-14723
commit a22abe8ae0ddd5934dd8f74f4a48599e188ffc73
Author: Tim Dillon
Date: Wed Dec 30 15:34:34 2020 +0900
Add SOLR-14723 to CHANGES.txt
commit 655bba5db63118c3055c30d331d1d082e0dd6050
Author: Tim Dillon
Date: Wed Dec 30 15:02:16 2020 +0900
Fix TestSolr4Spatial2 test
commit 2d8544fc455de8b596c6fbf3ecd2feb2ca6a84fc
Author: Tim Dillon
Date: Tue Dec 29 20:40:03 2020 +0900
Update doc to state default cache class
commit 3c5ee62d8fe87da080595822b46a3390510dea41
Author: Tim Dillon
Date: Tue Dec 29 19:51:57 2020 +0900
Replaced the class attribute in solrconfig-caching
commit 2341eef4a63696068b010d8da51f2fa818790fc0
Author: Tim Dillon
Date: Sun Dec 27 15:52:07 2020 +0900
Remove REQUIRE_CLASS from SolrCache plugin
commit 627995aba1a29dc4deaf726c0a49599224ea2de5
Author: Tim Dillon
Date: Sat Dec 26 11:14:03 2020 +0900
Remove cast to FastLRUCache in TestJsonRequest
commit 11319c119570c861d62f09fc6b482a6993dd38ff
Author: Tim Dillon
Date: Sat Dec 19 16:53:07 2020 +0900
Removed class attribute from caches
)
> Rremove the class atribute for the caches in the _default/example configsets
>
>
> Key: SOLR-14723
> URL: https://issues.apache.org/jira/browse/SOLR-14723
> Project: Solr
> Issue Type: Improvement
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Trivial
> Labels: newdev
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> In 8.x branch, the default and example configsets include LRUCache and
> FastLRUCache as the implementation for the various caches.
> {code:xml}
> size="512"
> initialSize="512"
> autowarmCount="0"/>
> {code}
> Those implementations are deprecated. We should remove the attribute
> completely and let the default take over (as it's in master), this should
> make upgrading configsets easier:
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-14723) Rremove the class atribute for the caches in the _default/example configsets
[
https://issues.apache.org/jira/browse/SOLR-14723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe updated SOLR-14723:
-
Comment: was deleted
(was: Commit 196632d538a26b0c92a67941ad7c47e2f9cd2e1d in lucene-solr's branch
refs/heads/branch_8x from Tomas Eduardo Fernandez Lobbe
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=196632d ]
SOLR-14723: Remove the class attribute for the caches in the _default/example
configsets
This is an 8.x change only. Closes #2169
Squashed commit of the following:
commit c638cbcfdb58b57cde8c4be641a7847b8a37422a
Merge: b13011e97ae a22abe8ae0d
Author: Tomas Fernandez Lobbe
Date: Tue Dec 29 23:33:38 2020 -0800
Merge branch 'jira/SOLR-14723' of https://github.com/trdillon/lucene-solr
into trdillon-jira/SOLR-14723
commit a22abe8ae0ddd5934dd8f74f4a48599e188ffc73
Author: Tim Dillon
Date: Wed Dec 30 15:34:34 2020 +0900
Add SOLR-14723 to CHANGES.txt
commit 655bba5db63118c3055c30d331d1d082e0dd6050
Author: Tim Dillon
Date: Wed Dec 30 15:02:16 2020 +0900
Fix TestSolr4Spatial2 test
commit 2d8544fc455de8b596c6fbf3ecd2feb2ca6a84fc
Author: Tim Dillon
Date: Tue Dec 29 20:40:03 2020 +0900
Update doc to state default cache class
commit 3c5ee62d8fe87da080595822b46a3390510dea41
Author: Tim Dillon
Date: Tue Dec 29 19:51:57 2020 +0900
Replaced the class attribute in solrconfig-caching
commit 2341eef4a63696068b010d8da51f2fa818790fc0
Author: Tim Dillon
Date: Sun Dec 27 15:52:07 2020 +0900
Remove REQUIRE_CLASS from SolrCache plugin
commit 627995aba1a29dc4deaf726c0a49599224ea2de5
Author: Tim Dillon
Date: Sat Dec 26 11:14:03 2020 +0900
Remove cast to FastLRUCache in TestJsonRequest
commit 11319c119570c861d62f09fc6b482a6993dd38ff
Author: Tim Dillon
Date: Sat Dec 19 16:53:07 2020 +0900
Removed class attribute from caches
)
> Rremove the class atribute for the caches in the _default/example configsets
>
>
> Key: SOLR-14723
> URL: https://issues.apache.org/jira/browse/SOLR-14723
> Project: Solr
> Issue Type: Improvement
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Trivial
> Labels: newdev
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> In 8.x branch, the default and example configsets include LRUCache and
> FastLRUCache as the implementation for the various caches.
> {code:xml}
> size="512"
> initialSize="512"
> autowarmCount="0"/>
> {code}
> Those implementations are deprecated. We should remove the attribute
> completely and let the default take over (as it's in master), this should
> make upgrading configsets easier:
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-14723) Rremove the class atribute for the caches in the _default/example configsets
[
https://issues.apache.org/jira/browse/SOLR-14723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe updated SOLR-14723:
-
Comment: was deleted
(was: Commit 196632d538a26b0c92a67941ad7c47e2f9cd2e1d in lucene-solr's branch
refs/heads/branch_8x from Tomas Eduardo Fernandez Lobbe
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=196632d ]
SOLR-14723: Remove the class attribute for the caches in the _default/example
configsets
This is an 8.x change only. Closes #2169
Squashed commit of the following:
commit c638cbcfdb58b57cde8c4be641a7847b8a37422a
Merge: b13011e97ae a22abe8ae0d
Author: Tomas Fernandez Lobbe
Date: Tue Dec 29 23:33:38 2020 -0800
Merge branch 'jira/SOLR-14723' of https://github.com/trdillon/lucene-solr
into trdillon-jira/SOLR-14723
commit a22abe8ae0ddd5934dd8f74f4a48599e188ffc73
Author: Tim Dillon
Date: Wed Dec 30 15:34:34 2020 +0900
Add SOLR-14723 to CHANGES.txt
commit 655bba5db63118c3055c30d331d1d082e0dd6050
Author: Tim Dillon
Date: Wed Dec 30 15:02:16 2020 +0900
Fix TestSolr4Spatial2 test
commit 2d8544fc455de8b596c6fbf3ecd2feb2ca6a84fc
Author: Tim Dillon
Date: Tue Dec 29 20:40:03 2020 +0900
Update doc to state default cache class
commit 3c5ee62d8fe87da080595822b46a3390510dea41
Author: Tim Dillon
Date: Tue Dec 29 19:51:57 2020 +0900
Replaced the class attribute in solrconfig-caching
commit 2341eef4a63696068b010d8da51f2fa818790fc0
Author: Tim Dillon
Date: Sun Dec 27 15:52:07 2020 +0900
Remove REQUIRE_CLASS from SolrCache plugin
commit 627995aba1a29dc4deaf726c0a49599224ea2de5
Author: Tim Dillon
Date: Sat Dec 26 11:14:03 2020 +0900
Remove cast to FastLRUCache in TestJsonRequest
commit 11319c119570c861d62f09fc6b482a6993dd38ff
Author: Tim Dillon
Date: Sat Dec 19 16:53:07 2020 +0900
Removed class attribute from caches
)
> Rremove the class atribute for the caches in the _default/example configsets
>
>
> Key: SOLR-14723
> URL: https://issues.apache.org/jira/browse/SOLR-14723
> Project: Solr
> Issue Type: Improvement
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Trivial
> Labels: newdev
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> In 8.x branch, the default and example configsets include LRUCache and
> FastLRUCache as the implementation for the various caches.
> {code:xml}
> size="512"
> initialSize="512"
> autowarmCount="0"/>
> {code}
> Those implementations are deprecated. We should remove the attribute
> completely and let the default take over (as it's in master), this should
> make upgrading configsets easier:
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14723) Rremove the class atribute for the caches in the _default/example configsets
[
https://issues.apache.org/jira/browse/SOLR-14723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255166#comment-17255166
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14723:
--
Thanks for working on this [~trdillon].
bq. I am now investigating a failing
org.apache.solr.search.join.CrossCollectionJoinQueryTest and the error log is
making me think it might be caused by
org.apache.solr.core.SolrConfig.PluginOpts.REQUIRE_CLASS but I'm not sure.
I believe you are right. It seems like (Looking at the
{{CacheConfig.getConfig}} method) could be optional, but we are requiring it
for custom caches (not for the main caches though). I think you are right, and
we should remove the
{{org.apache.solr.core.SolrConfig.PluginOpts.REQUIRE_CLASS}} to the
{{SolrCache}} plugin, since we anyway have a default for that attribute.
bq. Also there was a failure in org.apache.solr.search.TestLFUCache, which
along with org.apache.solr.search.TestLRUCache and
org.apache.solr.search.TestFastLRUCache have not yet been deprecated it seems.
You mean the tests aren't deprecated? What's the error?
bq. Tomas Eduardo Fernandez Lobbe Erick Erickson should I open a PR with what
I've done already and try to sort these other issues out within that?
Yes. please do.
> Rremove the class atribute for the caches in the _default/example configsets
>
>
> Key: SOLR-14723
> URL: https://issues.apache.org/jira/browse/SOLR-14723
> Project: Solr
> Issue Type: Improvement
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Trivial
> Labels: newdev
>
> In 8.x branch, the default and example configsets include LRUCache and
> FastLRUCache as the implementation for the various caches.
> {code:xml}
> size="512"
> initialSize="512"
> autowarmCount="0"/>
> {code}
> Those implementations are deprecated. We should remove the attribute
> completely and let the default take over (as it's in master), this should
> make upgrading configsets easier:
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14688) First party package implementation design
[
https://issues.apache.org/jira/browse/SOLR-14688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17246314#comment-17246314
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14688:
--
There were some discussions in Slack the last couple days that I'd like to
bring here since they are related to this Jira issue. The threads are
[this|https://the-asf.slack.com/archives/CNMTSU970/p1582794103004800] and
[this|https://the-asf.slack.com/archives/CNMTSU970/p1607019429038000]. While
there are different opinions expressed in those threads, the general sentiment
is that there are missing pieces to the stories of packages/plugins, that need
to be resolved before we proceed here. In particular, compatibility and offline
installs. I'm now going to bring a summary of my comments and concerns here.
In the current state of things with package manager and if this issue is
implemented, someone could technically install a package from a different
version, but this can only be achieved by ensuring binary compatibility between
core and the packages across those different versions. This is way more than
what we guarantee today (think of something in analysis-extras calling
{{coreContainer.getCore().getLatestSchema().callSomethingAddedIn8.9()}}, would
break in any core version previous to 8.9). Guaranteeing this binary
compatibility would require a ton of testing (every package version against
every core version that's supported), it would put a lot of burden on us
developers, making it very difficult to add/change/deprecate/retire code and
may even make major upgrades impossible, or if we just take binary
compatibility as a "best effort", we'll make it difficult on the users to
figure out which version of what is compatible with other versions.
One question that I raised is, why do we want people to install a newer
contribs/packages into an older core version? Why don't we instead encourage
people to upgrade Solr by making it easier to do? Major version upgrades could
be more problematic because of index compatibility, yes, but really, having
binary compatibility across major upgrades is going to be very, very hard.
There is also great concern about the inability to install packages offline,
and how that affects the ability to install/deploy first/third party plugins (a
bunch of people expressed this in particular in those Slack threads I
mentioned). I believe the root of the problem is the fact that packages *have*
to be cluster-wide now. Instead of being able to create the deployable in some
build infrastructure, away from production environments, and then move that
deployable across your different environments such as "dev", "qa", "prod", or
whatever you have, the current implementation only allows one to configure a
cluster once it's created and running, doing API calls (forcing to enable
package manager AFAIK, even if no code needs to be added dynamically later),
and exposing the production environment to either a package repository or even
internet.
I believe packages (first, or third party) could work better if they could be
local to a node (and this doesn't mean there can't be cluster-wide packages,
but we need at least the "local" option). People could then, for example,
create their Docker image like (and these are not real commands, just get the
idea):
{noformat}
FROM official-docker-image-slim:x.y.z
ADD /some/build/path/custom-plugin1 /some/location/in/solr/custom-plugin1
RUN /solr/bin/solr install custom-plugin1 /some/location/in/solr/custom-plugin1
RUN /solr/bin/solr install analysis-extra
solr.apache.org/packages/analysis-extra/x.y.z
#or RUN /solr/bin/solr install analysis-extra /first/party/plugins/location
{noformat}
(The example is with Docker, but similar things can be done with other
deployables, like AMIs in AWS, or I'm sure any container technology.)
And then just build it and deploy it. If you are using the Kubernetes Solr
operator, it's a single command and the upgrade will start safely and
automatically. It's also important to mention that any upgrade could look just
the same, regardless if what you changed was Solr core, first party or third
party plugin.
I'm +1 on making the code more modular and independent, have better, well
thought interfaces like the one created for the replica placement framework and
much of the work ab has been doing to define higher level interfaces of things
currently need rework, but I think with the current state of package manager,
with cluster-wide packages, this issue is very dangerous.
> First party package implementation design
> -
>
> Key: SOLR-14688
> URL: https://issues.apache.org/jira/browse/SOLR-14688
> Project: Solr
> Issue Type: Improvement
>Reporter: Noble Paul
>Priority: Major
> Labels:
[jira] [Commented] (SOLR-15029) Allow Shard Leader to give up leadership gracefully via shard terms
[
https://issues.apache.org/jira/browse/SOLR-15029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243575#comment-17243575
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-15029:
--
+1. While the current approach works, it is a big heavy handed, as you say.
{quote}The current leader would know it is ineligible
{quote}
How would this happen?
> Allow Shard Leader to give up leadership gracefully via shard terms
> ---
>
> Key: SOLR-15029
> URL: https://issues.apache.org/jira/browse/SOLR-15029
> Project: Solr
> Issue Type: Improvement
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Major
>
> Currently we have (via SOLR-12412) that when a leader sees an index writing
> error during an update it will give up leadership by deleting the replica and
> adding a new replica. One stated benefit of this was that because we are
> using the overseer and a known code path, that this is done asynchronous and
> very efficiently.
> I would argue that this approach is too heavy handed.
> In the case of a corrupt index exception, it makes some sense to completely
> delete the index dir and attempt to sync from a good peer. Even in this case,
> however, it might be better to allow fingerprinting and other index delta
> mechanisms take over and allow for a more efficient data transfer.
> In an alternate case where the index error arises due to a disconnected file
> system (possible with shared file systems, i.e. S3, HDFS, some k8s systems)
> and the required solution is some kind of reconnect, then this approach has
> several shortcomings - the core delete and creations are going to fail
> leaving dangling replicas. Further, the data is still present so there is no
> need to do so many extra copies.
> I propose that we bring in a mechanism to give up leadership via the existing
> shard terms language. I believe we would be able to set all replicas
> currently equal to leader term T to T+1, and then trigger a new leader
> election. The current leader would know it is ineligible, while the other
> replicas that were current before the failed update would be eligible. This
> improvement would entail adding an additional possible operation to terms
> state machine.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14182) Move metric reporters config from solr.xml to ZK cluster properties
[
https://issues.apache.org/jira/browse/SOLR-14182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17242821#comment-17242821
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14182:
--
{quote}metric reporters configuration should be moved to container-level
plugins, ie. {{/clusterprops.json:/plugin}} and the corresponding API. This
will make the reporters easier to configure and change dynamically without
restarting Solr nodes.
{quote}
I really don't see the point in moving this configuration to clusterprops. This
will be bad for people that keep configuration as code, specially if they have
multiple clusters, and it requires very solr-specific deployments processes.
i.e. instead of building the Docker image and deploy it as you normally do, you
need to, in addition, do this particular request to each Solr cluster, that's
specific to this change so you'll never have to do do again unless we do
changes in this particular component again (handle errors accordingly).
I wish we could tackle SOLR-14843, before doing these changes, hopefully in a
way where the use-case "long-lived Solr nodes where things can be installed on
it" can coexist better with other strategies, such us rolling restarts,
blue-green deployments or any kind of immutable deployments strategies.
> Move metric reporters config from solr.xml to ZK cluster properties
> ---
>
> Key: SOLR-14182
> URL: https://issues.apache.org/jira/browse/SOLR-14182
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 8.4
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
>
> Metric reporters are currently configured statically in solr.xml, which makes
> it difficult to change dynamically or in a containerized environment.
> We should move this section to ZK /cluster.properties and add a back-compat
> migration shim.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14992) TestPullReplicaErrorHandling.testCantConnectToPullReplica Failures
[
https://issues.apache.org/jira/browse/SOLR-14992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241715#comment-17241715
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14992:
--
bq. the failure talks about numshards
I believe the problem is that {{testCloseHooksDeletedOnReconnect}} disconnects
nodes, so when {{testCantConnectToPullReplica}} tries to create a collection
with a certain number of shards, there aren't enough nodes to match the
{{maxShardsPerNode}} setting. If that's the case, the fix should be to make
sure all nodes are up after running {{testCloseHooksDeletedOnReconnect}} (or
any other test in this suite). [This
comment|https://issues.apache.org/jira/browse/SOLR-14940?focusedCommentId=17229764=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17229764]
has a suggestion for a possible fix I haven't had tie to try.
> TestPullReplicaErrorHandling.testCantConnectToPullReplica Failures
> --
>
> Key: SOLR-14992
> URL: https://issues.apache.org/jira/browse/SOLR-14992
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Minor
>
> I've noticed this test started failing very frequently with an error like:
> {noformat}
> Error Message:
> Error from server at http://127.0.0.1:39037/solr: Cannot create collection
> pull_replica_error_handling_test_cant_connect_to_pull_replica. Value of
> maxShardsPerNode is 1, and the number of nodes currently live or live and
> part of your createNodeSet is 3. This allows a maximum of 3 to be created.
> Value of numShards is 2, value of nrtReplicas is 1, value of tlogReplicas is
> 0 and value of pullReplicas is 1. This requires 4 shards to be created
> (higher than the allowed number)
> Stack Trace:
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://127.0.0.1:39037/solr: Cannot create collection
> pull_replica_error_handling_test_cant_connect_to_pull_replica. Value of
> maxShardsPerNode is 1, and the number of nodes currently live or live and
> part of your createNodeSet is 3. This allows a maximum of 3 to be created.
> Value of numShards is 2, value of nrtReplicas is 1, value of tlogReplicas is
> 0 and value of pullReplicas is 1. This requires 4 shards to be created
> (higher than the allowed number)
> at
> __randomizedtesting.SeedInfo.seed([3D670DC4BEABD958:3550EB0C6505ADD6]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:681)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:266)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
> at
> org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:369)
> at
> org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:297)
> at
> org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1173)
> at
> org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:934)
> at
> org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:866)
> at
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:214)
> at
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:231)
> at
> org.apache.solr.cloud.TestPullReplicaErrorHandling.testCantConnectToPullReplica(TestPullReplicaErrorHandling.java:149)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
> at
>
[jira] [Commented] (SOLR-14992) TestPullReplicaErrorHandling.testCantConnectToPullReplica Failures
[
https://issues.apache.org/jira/browse/SOLR-14992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17229765#comment-17229765
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14992:
--
Maybe related to SOLR-14940. It's strange that it only fails in 8.x
> TestPullReplicaErrorHandling.testCantConnectToPullReplica Failures
> --
>
> Key: SOLR-14992
> URL: https://issues.apache.org/jira/browse/SOLR-14992
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Minor
>
> I've noticed this test started failing very frequently with an error like:
> {noformat}
> Error Message:
> Error from server at http://127.0.0.1:39037/solr: Cannot create collection
> pull_replica_error_handling_test_cant_connect_to_pull_replica. Value of
> maxShardsPerNode is 1, and the number of nodes currently live or live and
> part of your createNodeSet is 3. This allows a maximum of 3 to be created.
> Value of numShards is 2, value of nrtReplicas is 1, value of tlogReplicas is
> 0 and value of pullReplicas is 1. This requires 4 shards to be created
> (higher than the allowed number)
> Stack Trace:
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://127.0.0.1:39037/solr: Cannot create collection
> pull_replica_error_handling_test_cant_connect_to_pull_replica. Value of
> maxShardsPerNode is 1, and the number of nodes currently live or live and
> part of your createNodeSet is 3. This allows a maximum of 3 to be created.
> Value of numShards is 2, value of nrtReplicas is 1, value of tlogReplicas is
> 0 and value of pullReplicas is 1. This requires 4 shards to be created
> (higher than the allowed number)
> at
> __randomizedtesting.SeedInfo.seed([3D670DC4BEABD958:3550EB0C6505ADD6]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:681)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:266)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
> at
> org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:369)
> at
> org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:297)
> at
> org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1173)
> at
> org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:934)
> at
> org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:866)
> at
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:214)
> at
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:231)
> at
> org.apache.solr.cloud.TestPullReplicaErrorHandling.testCantConnectToPullReplica(TestPullReplicaErrorHandling.java:149)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
>
[jira] [Reopened] (SOLR-14940) ReplicationHandler memory leak through SolrCore.closeHooks
[ https://issues.apache.org/jira/browse/SOLR-14940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Eduardo Fernandez Lobbe reopened SOLR-14940: -- > ReplicationHandler memory leak through SolrCore.closeHooks > -- > > Key: SOLR-14940 > URL: https://issues.apache.org/jira/browse/SOLR-14940 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: replication (java) > Environment: Solr Cloud Cluster on v.8.6.2 configured as 3 TLOG nodes > with 2 cores in each JVM. > >Reporter: Anver Sotnikov >Assignee: Mike Drob >Priority: Major > Fix For: master (9.0), 8.8 > > Attachments: Actual references to hooks that in turn hold references > to ReplicationHandlers.png, Memory Analyzer SolrCore.closeHooks .png > > Time Spent: 2h 10m > Remaining Estimate: 0h > > We are experiencing a memory leak in Solr Cloud cluster configured as 3 TLOG > nodes. > Leader does not seem to be affected while Followers are. > > Looking at memory dump we noticed that SolrCore holds lots of references to > ReplicationHandler through anonymous inner classes in SolrCore.closeHooks, > which in turn holds ReplicationHandlers. > ReplicationHandler registers hooks as anonymous inner classes in > SolrCore.closeHooks through ReplicationHandler.inform() -> > ReplicationHandler.registerCloseHook(). > > Whenever ZkController.stopReplicationFromLeader is called - it would shutdown > ReplicationHandler (ReplicationHandler.shutdown()), BUT reference to > ReplicationHandler will stay in SolrCore.closeHooks. Once replication is > started again on same SolrCore - new ReplicationHandler will be created and > registered in closeHooks. > > It looks like there are few scenarios when replication is stopped and > restarted on same core and in our TLOG setup it shows up quite often. > > Potential solutions: > # Allow unregistering SolrCore.closeHooks so it can be used from > ReplicationHandler.shutdown > # Hack but easier - break the link between ReplicationHandler close hooks > and full ReplicationHandler object so ReplicationHandler can be GCed even > when hooks are still registered in SolrCore.closeHooks -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14940) ReplicationHandler memory leak through SolrCore.closeHooks
[
https://issues.apache.org/jira/browse/SOLR-14940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17229764#comment-17229764
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14940:
--
I believe the test added to {{TestPullReplicaErrorHandling}} is causing the
failures described in https://issues.apache.org/jira/browse/SOLR-14992. The
failures happen in the tests running immediately after
{{testCloseHooksDeletedOnReconnect}}, for example:
{noformat}
[junit4] 2> 37296 INFO
(TEST-TestPullReplicaErrorHandling.testCloseHooksDeletedOnReconnect-seed#[64BCF377B675F037])
[ ] o.a.s.c.MiniSolrCloudCluster Expired zookeeper session
72103195153465373 from node http://127.0.0.1:64010/solr
[junit4] 2> 37296 INFO
(TEST-TestPullReplicaErrorHandling.testCloseHooksDeletedOnReconnect-seed#[64BCF377B675F037])
[ ] o.a.s.c.SolrCloudTestCase waitForState
(pull_replica_error_handling_test_close_hooks_deleted_on_reconnect): Expecting
node to reconnect
[junit4] 2> 37296 WARN (NIOWorkerThread-1) [ ] o.a.z.s.NIOServerCnxn
Unexpected exception
[junit4] 2> => EndOfStreamException: Unable to read additional
data from client, it probably closed the socket: address = /127.0.0.1:64510,
session = 0x1002979564b001d
[junit4] 2>at
org.apache.zookeeper.server.NIOServerCnxn.handleFailedRead(NIOServerCnxn.java:163)
[junit4] 2> org.apache.zookeeper.server.ServerCnxn$EndOfStreamException:
Unable to read additional data from client, it probably closed the socket:
address = /127.0.0.1:64510, session = 0x1002979564b001d
[junit4] 2>at
org.apache.zookeeper.server.NIOServerCnxn.handleFailedRead(NIOServerCnxn.java:163)
~[zookeeper-3.6.2.jar:3.6.2]
[junit4] 2>at
org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:326)
[zookeeper-3.6.2.jar:3.6.2]
[junit4] 2>at
org.apache.zookeeper.server.NIOServerCnxnFactory$IOWorkRequest.doWork(NIOServerCnxnFactory.java:522)
[zookeeper-3.6.2.jar:3.6.2]
[junit4] 2>at
org.apache.zookeeper.server.WorkerService$ScheduledWorkRequest.run(WorkerService.java:154)
[zookeeper-3.6.2.jar:3.6.2]
[junit4] 2>at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
[?:?]
[junit4] 2>at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
[?:?]
[junit4] 2>at java.lang.Thread.run(Thread.java:832) [?:?]
[junit4] 2> 37299 INFO (zkCallback-214-thread-1) [ ]
o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (4) -> (3)
[junit4] 2> 37299 INFO (zkCallback-184-thread-3) [ ]
o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (4) -> (3)
[junit4] 2> 37299 INFO (zkCallback-154-thread-1) [ ]
o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (4) -> (3)
[junit4] 2> 37299 INFO (zkCallback-100-thread-1) [ ]
o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (4) -> (3)
[junit4] 2> 37304 INFO
(TEST-TestPullReplicaErrorHandling.testCloseHooksDeletedOnReconnect-seed#[64BCF377B675F037])
[ ] o.a.s.c.TestPullReplicaErrorHandling tearDown deleting collection
[junit4] 2> 37306 INFO (SocketProxy-Acceptor-64086) [ ]
o.a.s.c.s.c.SocketProxy accepted
Socket[addr=/127.0.0.1,port=64511,localport=64086], receiveBufferSize: 65536
[junit4] 2> 37306 INFO (SocketProxy-Acceptor-64086) [ ]
o.a.s.c.s.c.SocketProxy proxy connection
Socket[addr=/127.0.0.1,port=64102,localport=64512], receiveBufferSize=65536
[junit4] 2> 37308 INFO (qtp1774678962-277) [n:127.0.0.1:64086_solr ]
o.a.s.h.a.CollectionsHandler Invoked Collection Action :delete with params
name=pull_replica_error_handling_test_close_hooks_deleted_on_reconnect=DELETE=javabin=2
and sendToOCPQueue=true
[junit4] 2> 37319 INFO
(OverseerThreadFactory-238-thread-1-processing-n:127.0.0.1:64086_solr)
[n:127.0.0.1:64086_solr ] o.a.s.c.a.c.OverseerCollectionMessageHandler
Executing Collection
Cmd=action=UNLOAD=true=true=true,
asyncId=null
[junit4] 2> 37321 INFO (SocketProxy-Acceptor-64180) [ ]
o.a.s.c.s.c.SocketProxy accepted
Socket[addr=/127.0.0.1,port=64513,localport=64180], receiveBufferSize: 65536
[junit4] 2> 37322 INFO (SocketProxy-Acceptor-64180) [ ]
o.a.s.c.s.c.SocketProxy proxy connection
Socket[addr=/127.0.0.1,port=64194,localport=64514], receiveBufferSize=65536
[junit4] 2> 37324 INFO (qtp420303283-332) [n:127.0.0.1:64180_solr
x:pull_replica_error_handling_test_close_hooks_deleted_on_reconnect_shard1_replica_n1
] o.a.s.m.SolrMetricManager Closing metric reporters for
registry=solr.core.pull_replica_error_handling_test_close_hooks_deleted_on_reconnect.shard1.replica_n1
tag=null
[junit4] 2> 37324 INFO (qtp420303283-332) [n:127.0.0.1:64180_solr ]
o.a.s.c.SolrCore
[jira] [Created] (SOLR-14992) TestPullReplicaErrorHandling.testCantConnectToPullReplica Failures
Tomas Eduardo Fernandez Lobbe created SOLR-14992:
Summary: TestPullReplicaErrorHandling.testCantConnectToPullReplica
Failures
Key: SOLR-14992
URL: https://issues.apache.org/jira/browse/SOLR-14992
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Tomas Eduardo Fernandez Lobbe
I've noticed this test started failing very frequently with an error like:
{noformat}
Error Message:
Error from server at http://127.0.0.1:39037/solr: Cannot create collection
pull_replica_error_handling_test_cant_connect_to_pull_replica. Value of
maxShardsPerNode is 1, and the number of nodes currently live or live and part
of your createNodeSet is 3. This allows a maximum of 3 to be created. Value of
numShards is 2, value of nrtReplicas is 1, value of tlogReplicas is 0 and value
of pullReplicas is 1. This requires 4 shards to be created (higher than the
allowed number)
Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
from server at http://127.0.0.1:39037/solr: Cannot create collection
pull_replica_error_handling_test_cant_connect_to_pull_replica. Value of
maxShardsPerNode is 1, and the number of nodes currently live or live and part
of your createNodeSet is 3. This allows a maximum of 3 to be created. Value of
numShards is 2, value of nrtReplicas is 1, value of tlogReplicas is 0 and value
of pullReplicas is 1. This requires 4 shards to be created (higher than the
allowed number)
at
__randomizedtesting.SeedInfo.seed([3D670DC4BEABD958:3550EB0C6505ADD6]:0)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:681)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:266)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
at
org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:369)
at
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:297)
at
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1173)
at
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:934)
at
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:866)
at
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:214)
at
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:231)
at
org.apache.solr.cloud.TestPullReplicaErrorHandling.testCantConnectToPullReplica(TestPullReplicaErrorHandling.java:149)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at
[jira] [Commented] (SOLR-14925) CVE-2020-13957: The checks added to unauthenticated configset uploads can be circumvented
[
https://issues.apache.org/jira/browse/SOLR-14925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224835#comment-17224835
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14925:
--
Hi Rakesh, The exact steps to reproduce are not typically included in the
description. Make sure to have one or more of the mitigation options in place.
> CVE-2020-13957: The checks added to unauthenticated configset uploads can be
> circumvented
> -
>
> Key: SOLR-14925
> URL: https://issues.apache.org/jira/browse/SOLR-14925
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 7.0,
> 7.0.1, 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1, 7.7.2, 8.0,
> 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.6, 8.5.1, 8.5.2,
> 8.6.1, 8.6.2
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Fix For: master (9.0), 8.7, 8.6.3
>
>
> Severity: High
> Vendor: The Apache Software Foundation
> Versions Affected:
> 6.6.0 to 6.6.5
> 7.0.0 to 7.7.3
> 8.0.0 to 8.6.2
> Description:
> Solr prevents some features considered dangerous (which could be used for
> remote code execution) to be configured in a ConfigSet that's uploaded via
> API without authentication/authorization. The checks in place to prevent such
> features can be circumvented by using a combination of UPLOAD/CREATE actions.
> Mitigation:
> Any of the following are enough to prevent this vulnerability:
> * Disable UPLOAD command in ConfigSets API if not used by setting the system
> property: {{configset.upload.enabled}} to {{false}} [1]
> * Use Authentication/Authorization and make sure unknown requests aren't
> allowed [2]
> * Upgrade to Solr 8.6.3 or greater.
> * If upgrading is not an option, consider applying the patch in SOLR-14663
> ([3])
> * No Solr API, including the Admin UI, is designed to be exposed to
> non-trusted parties. Tune your firewall so that only trusted computers and
> people are allowed access
> Credit:
> Tomás Fernández Löbbe, András Salamon
> References:
> [1] https://lucene.apache.org/solr/guide/8_6/configsets-api.html
> [2]
> https://lucene.apache.org/solr/guide/8_6/authentication-and-authorization-plugins.html
> [3] https://issues.apache.org/jira/browse/SOLR-14663
> [4] https://issues.apache.org/jira/browse/SOLR-14925
> [5] https://wiki.apache.org/solr/SolrSecurity
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14925) CVE-2020-13957: The checks added to unauthenticated configset uploads can be circumvented
[
https://issues.apache.org/jira/browse/SOLR-14925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe updated SOLR-14925:
-
Description:
Severity: High
Vendor: The Apache Software Foundation
Versions Affected:
6.6.0 to 6.6.6
7.0.0 to 7.7.3
8.0.0 to 8.6.2
Description:
Solr prevents some features considered dangerous (which could be used for
remote code execution) to be configured in a ConfigSet that's uploaded via API
without authentication/authorization. The checks in place to prevent such
features can be circumvented by using a combination of UPLOAD/CREATE actions.
Mitigation:
Any of the following are enough to prevent this vulnerability:
* Disable UPLOAD command in ConfigSets API if not used by setting the system
property: {{configset.upload.enabled}} to {{false}} [1]
* Use Authentication/Authorization and make sure unknown requests aren't
allowed [2]
* Upgrade to Solr 8.6.3 or greater.
* If upgrading is not an option, consider applying the patch in SOLR-14663 ([3])
* No Solr API, including the Admin UI, is designed to be exposed to non-trusted
parties. Tune your firewall so that only trusted computers and people are
allowed access
Credit:
Tomás Fernández Löbbe, András Salamon
References:
[1] https://lucene.apache.org/solr/guide/8_6/configsets-api.html
[2]
https://lucene.apache.org/solr/guide/8_6/authentication-and-authorization-plugins.html
[3] https://issues.apache.org/jira/browse/SOLR-14663
[4] https://issues.apache.org/jira/browse/SOLR-14925
[5] https://wiki.apache.org/solr/SolrSecurity
was:
Severity: High
Vendor: The Apache Software Foundation
Versions Affected:
6.6.0 to 6.6.5
7.0.0 to 7.7.3
8.0.0 to 8.6.2
Description:
Solr prevents some features considered dangerous (which could be used for
remote code execution) to be configured in a ConfigSet that's uploaded via API
without authentication/authorization. The checks in place to prevent such
features can be circumvented by using a combination of UPLOAD/CREATE actions.
Mitigation:
Any of the following are enough to prevent this vulnerability:
* Disable UPLOAD command in ConfigSets API if not used by setting the system
property: {{configset.upload.enabled}} to {{false}} [1]
* Use Authentication/Authorization and make sure unknown requests aren't
allowed [2]
* Upgrade to Solr 8.6.3 or greater.
* If upgrading is not an option, consider applying the patch in SOLR-14663 ([3])
* No Solr API, including the Admin UI, is designed to be exposed to non-trusted
parties. Tune your firewall so that only trusted computers and people are
allowed access
Credit:
Tomás Fernández Löbbe, András Salamon
References:
[1] https://lucene.apache.org/solr/guide/8_6/configsets-api.html
[2]
https://lucene.apache.org/solr/guide/8_6/authentication-and-authorization-plugins.html
[3] https://issues.apache.org/jira/browse/SOLR-14663
[4] https://issues.apache.org/jira/browse/SOLR-14925
[5] https://wiki.apache.org/solr/SolrSecurity
> CVE-2020-13957: The checks added to unauthenticated configset uploads can be
> circumvented
> -
>
> Key: SOLR-14925
> URL: https://issues.apache.org/jira/browse/SOLR-14925
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 7.0,
> 7.0.1, 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1, 7.7.2, 8.0,
> 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.6, 8.5.1, 8.5.2,
> 8.6.1, 8.6.2
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Fix For: master (9.0), 8.7, 8.6.3
>
>
> Severity: High
> Vendor: The Apache Software Foundation
> Versions Affected:
> 6.6.0 to 6.6.6
> 7.0.0 to 7.7.3
> 8.0.0 to 8.6.2
> Description:
> Solr prevents some features considered dangerous (which could be used for
> remote code execution) to be configured in a ConfigSet that's uploaded via
> API without authentication/authorization. The checks in place to prevent such
> features can be circumvented by using a combination of UPLOAD/CREATE actions.
> Mitigation:
> Any of the following are enough to prevent this vulnerability:
> * Disable UPLOAD command in ConfigSets API if not used by setting the system
> property: {{configset.upload.enabled}} to {{false}} [1]
> * Use Authentication/Authorization and make sure unknown requests aren't
> allowed [2]
> * Upgrade to Solr 8.6.3 or greater.
> * If upgrading is not an option, consider applying the patch in SOLR-14663
> ([3])
> * No Solr API, including the Admin UI, is designed to be exposed to
> non-trusted parties. Tune your firewall so that only trusted computers and
> people are allowed access
> Credit:
> Tomás
[jira] [Commented] (SOLR-14067) Move StatelessScriptUpdateProcessor to a contrib
[ https://issues.apache.org/jira/browse/SOLR-14067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219964#comment-17219964 ] Tomas Eduardo Fernandez Lobbe commented on SOLR-14067: -- Here is another, more recent, example: https://github.com/apache/lucene-solr/commit/0836ea5/ > Move StatelessScriptUpdateProcessor to a contrib > > > Key: SOLR-14067 > URL: https://issues.apache.org/jira/browse/SOLR-14067 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Assignee: David Eric Pugh >Priority: Major > Time Spent: 2h 10m > Remaining Estimate: 0h > > Move server-side scripting out of core and into a new contrib. This is > better for security. > Former description: > > We should eliminate all scripting capabilities within Solr. Let us start with > the StatelessScriptUpdateProcessor deprecation/removal. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14067) Move StatelessScriptUpdateProcessor to a contrib
[ https://issues.apache.org/jira/browse/SOLR-14067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219962#comment-17219962 ] Tomas Eduardo Fernandez Lobbe commented on SOLR-14067: -- bq. Tomas Eduardo Fernandez Lobbe do you have an example of where we have done the rename? I like that idea, that way I can go through and use the cleaned up "ScriptingUpdateRequestProcessor" everywhere, and have it still be backwards compatible. I'm sure this has been done in other places, but see for example the SolrServer -> SolrClient rename: https://issues.apache.org/jira/browse/SOLR-6895 > Move StatelessScriptUpdateProcessor to a contrib > > > Key: SOLR-14067 > URL: https://issues.apache.org/jira/browse/SOLR-14067 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Assignee: David Eric Pugh >Priority: Major > Time Spent: 2h 10m > Remaining Estimate: 0h > > Move server-side scripting out of core and into a new contrib. This is > better for security. > Former description: > > We should eliminate all scripting capabilities within Solr. Let us start with > the StatelessScriptUpdateProcessor deprecation/removal. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14067) Deprecate StatelessScriptUpdateProcessor and disabled by default
[
https://issues.apache.org/jira/browse/SOLR-14067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219380#comment-17219380
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14067:
--
The rename can still be done in a backwards compatible way, right? If we:
1) Rename {{StatelessScriptUpdateProcessorFactory}} ->
{{ScriptUpdateProcessorFactory}}
2) Create a new {{StatelessScriptUpdateProcessorFactory}} that extends
{{ScriptUpdateProcessorFactory}} and delegates everything to it (maybe also log
a warning)
3) Mark {{StatelessScriptUpdateProcessorFactory}} as deprecated, in favor of
{{ScriptUpdateProcessorFactory}}
That should allow upgrades without changing configs (and even if someone is
extending {{StatelessScriptUpdateProcessorFactory}} it would work, plus they'd
get the deprecation warning). I'd argue that we may want to keep that in 9 too,
if we want to support rolling upgrades from 8.x.
Regarding moving to a contrib, is that something that needs to wait for 9? If
we don't, someone upgradeing to 8.8 would just have to make sure the
"script-update-processor" jar is in the classpath, but no changes to config if
we keep the same package name. It can just be an upgrade note, right? or am I
missing something?
> Deprecate StatelessScriptUpdateProcessor and disabled by default
>
>
> Key: SOLR-14067
> URL: https://issues.apache.org/jira/browse/SOLR-14067
> Project: Solr
> Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>Assignee: David Eric Pugh
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> We should eliminate all scripting capabilities within Solr. Let us start with
> the StatelessScriptUpdateProcessor deprecation/removal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14925) CVE-2020-13957: The checks added to unauthenticated configset uploads can be circumvented
[
https://issues.apache.org/jira/browse/SOLR-14925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe updated SOLR-14925:
-
Affects Version/s: 6.6.6
> CVE-2020-13957: The checks added to unauthenticated configset uploads can be
> circumvented
> -
>
> Key: SOLR-14925
> URL: https://issues.apache.org/jira/browse/SOLR-14925
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 7.0,
> 7.0.1, 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1, 7.7.2, 8.0,
> 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.6, 8.5.1, 8.5.2,
> 8.6.1, 8.6.2
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Fix For: master (9.0), 8.7, 8.6.3
>
>
> Severity: High
> Vendor: The Apache Software Foundation
> Versions Affected:
> 6.6.0 to 6.6.5
> 7.0.0 to 7.7.3
> 8.0.0 to 8.6.2
> Description:
> Solr prevents some features considered dangerous (which could be used for
> remote code execution) to be configured in a ConfigSet that's uploaded via
> API without authentication/authorization. The checks in place to prevent such
> features can be circumvented by using a combination of UPLOAD/CREATE actions.
> Mitigation:
> Any of the following are enough to prevent this vulnerability:
> * Disable UPLOAD command in ConfigSets API if not used by setting the system
> property: {{configset.upload.enabled}} to {{false}} [1]
> * Use Authentication/Authorization and make sure unknown requests aren't
> allowed [2]
> * Upgrade to Solr 8.6.3 or greater.
> * If upgrading is not an option, consider applying the patch in SOLR-14663
> ([3])
> * No Solr API, including the Admin UI, is designed to be exposed to
> non-trusted parties. Tune your firewall so that only trusted computers and
> people are allowed access
> Credit:
> Tomás Fernández Löbbe, András Salamon
> References:
> [1] https://lucene.apache.org/solr/guide/8_6/configsets-api.html
> [2]
> https://lucene.apache.org/solr/guide/8_6/authentication-and-authorization-plugins.html
> [3] https://issues.apache.org/jira/browse/SOLR-14663
> [4] https://issues.apache.org/jira/browse/SOLR-14925
> [5] https://wiki.apache.org/solr/SolrSecurity
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14925) CVE-2020-13957: The checks added to unauthenticated configset uploads can be circumvented
[
https://issues.apache.org/jira/browse/SOLR-14925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe updated SOLR-14925:
-
Security: Public (was: Private (Security Issue))
> CVE-2020-13957: The checks added to unauthenticated configset uploads can be
> circumvented
> -
>
> Key: SOLR-14925
> URL: https://issues.apache.org/jira/browse/SOLR-14925
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 7.0, 7.0.1, 7.1,
> 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1, 7.7.2, 8.0, 8.1, 8.2,
> 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.6, 8.5.1, 8.5.2, 8.6.1, 8.6.2
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Fix For: master (9.0), 8.7, 8.6.3
>
>
> Severity: High
> Vendor: The Apache Software Foundation
> Versions Affected:
> 6.6.0 to 6.6.5
> 7.0.0 to 7.7.3
> 8.0.0 to 8.6.2
> Description:
> Solr prevents some features considered dangerous (which could be used for
> remote code execution) to be configured in a ConfigSet that's uploaded via
> API without authentication/authorization. The checks in place to prevent such
> features can be circumvented by using a combination of UPLOAD/CREATE actions.
> Mitigation:
> Any of the following are enough to prevent this vulnerability:
> * Disable UPLOAD command in ConfigSets API if not used by setting the system
> property: {{configset.upload.enabled}} to {{false}} [1]
> * Use Authentication/Authorization and make sure unknown requests aren't
> allowed [2]
> * Upgrade to Solr 8.6.3 or greater.
> * If upgrading is not an option, consider applying the patch in SOLR-14663
> ([3])
> * No Solr API, including the Admin UI, is designed to be exposed to
> non-trusted parties. Tune your firewall so that only trusted computers and
> people are allowed access
> Credit:
> Tomás Fernández Löbbe, András Salamon
> References:
> [1] https://lucene.apache.org/solr/guide/8_6/configsets-api.html
> [2]
> https://lucene.apache.org/solr/guide/8_6/authentication-and-authorization-plugins.html
> [3] https://issues.apache.org/jira/browse/SOLR-14663
> [4] https://issues.apache.org/jira/browse/SOLR-14925
> [5] https://wiki.apache.org/solr/SolrSecurity
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14708) Backward-Compatible Replication
[
https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17210498#comment-17210498
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14708:
--
bq. If I understand this work correctly, there should be no compatibility
issues for someone moving from 8.x to 8.7 if they do not change their
solrconfig.xml, is that correct?
Right, that was the intent.
bq. I'm wondering, though, that we should tell them to update their
solrconfig.xml files manually because if they don't, they will have issues
upgrading to 9.0? I mean, at some point they will need to excise the old terms
we're trying to get rid of or else they'll keep carrying it along forever. The
message I'm thinking would be something like "go ahead and do your rolling
upgrade, but you should fix your configs after at a convenient time".
The thing is that they can't upgrade their configuration until all the nodes
are at least in 8.7, because 8.6 won't know how to read those conf changes.
There are some [upgrade notes in
9|https://github.com/apache/lucene-solr/pull/1718/files] (which I'm noticing
don't say anything about solrconfig, so they may need some improvement). The
point when someone HAS to make changes is when upgrading to 9 (I believe only
in metrics). Note that Solr 9 can still read the old nomenclature in both,
configs and parameters.
> Backward-Compatible Replication
> ---
>
> Key: SOLR-14708
> URL: https://issues.apache.org/jira/browse/SOLR-14708
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Reporter: Marcus Eagan
>Priority: Critical
>
> In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed
> that we remove master/slave terminology from the Solr codebase. Now that's
> complete, we need to ensure it is backward compatible to support rolling
> upgrades from 8.7.x to 9.x because we really ought not to make it harder to
> upgrade Solr.
> Tomas offered a helpful path in a now abandoned PR:
> {quote}One way to get back compatibility and rolling upgrades could be to
> make 9.x code be able to read previous formats, but write new format, and
> make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a
> rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to
> 8.7 would still work.
> All the code other than the requests/responses could be changed in 8_x
> branch, in addition to master.
> {quote}
> The approach that we will take is to add a ternary operator in 9_X to accept
> parameter values for the legacy verbiage, or leader/follower, but only write
> leader/follower. We need to then make 8_x work in the inverse way. The burden
> here is not on that proposal or on the code in my view. Instead, the burden
> is on the test plan.
> If anyone has any guidance please share but here are my thoughts:
> Case A:
> Test the case where a user is running a standalone cluster in 8 with three
> nodes but then updates one of the nodes.
> Case B:
> Test the case where a user is running a mixed cluster standalone cluster, and
> the leader node is forced to fail and then is brought back.
> Case C:
> A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a
> rolling upgrade and a follower needs to become leader.
> I know haven't listed all possible scenarios or everything that could happen.
> Please let me know if you have thoughts or guidance on how best to accomplish
> this work.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14663) ConfigSets CREATE does not set trusted flag
[ https://issues.apache.org/jira/browse/SOLR-14663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Eduardo Fernandez Lobbe resolved SOLR-14663. -- Fix Version/s: 8.6.3 8.7 master (9.0) Resolution: Fixed > ConfigSets CREATE does not set trusted flag > --- > > Key: SOLR-14663 > URL: https://issues.apache.org/jira/browse/SOLR-14663 > Project: Solr > Issue Type: Task >Reporter: Andras Salamon >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Major > Fix For: master (9.0), 8.7, 8.6.3 > > Attachments: SOLR-14663.patch, SOLR-14663.patch > > > If I upload a configset using [ConfigSets > API|https://lucene.apache.org/solr/guide/8_6/configsets-api.html] UPLOAD Solr > sets the trusted flag. The config set will be trusted if authentication is > enabled and the upload operation is performed as an authenticated request. > On the other hand if I use the ConfigSets API CREATE which creates a new > configset based on an already uploaded one, this flag will not be set, so the > configset will be effectively untrusted. > I don't really understand the difference here, I think CREATE API call should > set this flag just like UPLOAD sets it. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14663) ConfigSets CREATE does not set trusted flag
[ https://issues.apache.org/jira/browse/SOLR-14663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Eduardo Fernandez Lobbe updated SOLR-14663: - Attachment: SOLR-14663.patch > ConfigSets CREATE does not set trusted flag > --- > > Key: SOLR-14663 > URL: https://issues.apache.org/jira/browse/SOLR-14663 > Project: Solr > Issue Type: Task >Reporter: Andras Salamon >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Major > Attachments: SOLR-14663.patch, SOLR-14663.patch > > > If I upload a configset using [ConfigSets > API|https://lucene.apache.org/solr/guide/8_6/configsets-api.html] UPLOAD Solr > sets the trusted flag. The config set will be trusted if authentication is > enabled and the upload operation is performed as an authenticated request. > On the other hand if I use the ConfigSets API CREATE which creates a new > configset based on an already uploaded one, this flag will not be set, so the > configset will be effectively untrusted. > I don't really understand the difference here, I think CREATE API call should > set this flag just like UPLOAD sets it. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14663) ConfigSets CREATE does not set trusted flag
[ https://issues.apache.org/jira/browse/SOLR-14663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205827#comment-17205827 ] Tomas Eduardo Fernandez Lobbe commented on SOLR-14663: -- This does seem like a bug to me. Sorry Andras, I wasn't aware of this Jira issue when I started looking, so I didn't use your patch, but I think this one addresses the problem too. > ConfigSets CREATE does not set trusted flag > --- > > Key: SOLR-14663 > URL: https://issues.apache.org/jira/browse/SOLR-14663 > Project: Solr > Issue Type: Task >Reporter: Andras Salamon >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Major > Attachments: SOLR-14663.patch, SOLR-14663.patch > > > If I upload a configset using [ConfigSets > API|https://lucene.apache.org/solr/guide/8_6/configsets-api.html] UPLOAD Solr > sets the trusted flag. The config set will be trusted if authentication is > enabled and the upload operation is performed as an authenticated request. > On the other hand if I use the ConfigSets API CREATE which creates a new > configset based on an already uploaded one, this flag will not be set, so the > configset will be effectively untrusted. > I don't really understand the difference here, I think CREATE API call should > set this flag just like UPLOAD sets it. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Reopened] (SOLR-14663) ConfigSets CREATE does not set trusted flag
[ https://issues.apache.org/jira/browse/SOLR-14663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Eduardo Fernandez Lobbe reopened SOLR-14663: -- Assignee: Tomas Eduardo Fernandez Lobbe > ConfigSets CREATE does not set trusted flag > --- > > Key: SOLR-14663 > URL: https://issues.apache.org/jira/browse/SOLR-14663 > Project: Solr > Issue Type: Task >Reporter: Andras Salamon >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Major > Attachments: SOLR-14663.patch > > > If I upload a configset using [ConfigSets > API|https://lucene.apache.org/solr/guide/8_6/configsets-api.html] UPLOAD Solr > sets the trusted flag. The config set will be trusted if authentication is > enabled and the upload operation is performed as an authenticated request. > On the other hand if I use the ConfigSets API CREATE which creates a new > configset based on an already uploaded one, this flag will not be set, so the > configset will be effectively untrusted. > I don't really understand the difference here, I think CREATE API call should > set this flag just like UPLOAD sets it. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205712#comment-17205712
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14151:
--
bq. this build was triggered after Noble did a flawed cherry-pick from master
to branch_8x. I fixed it immediately after that, but this run may have been
triggered between those two commits.
Ah, thanks Ishan!
> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Blocker
> Labels: packagemanager
> Fix For: 8.7
>
> Time Spent: 13.5h
> Remaining Estimate: 0h
>
> Example:
> {code:xml}
>
>
>
>generateNumberParts="0" catenateWords="0"
> catenateNumbers="0" catenateAll="0"/>
>
>
>
>
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed,
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205277#comment-17205277
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14151:
--
I believe [this
failure|https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/4533/consoleFull]
is also related to the changes here:
{noformat}
[junit4] 2> 11557 ERROR (qtp351699759-119) [n:127.0.0.1:35307_solr ]
o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: Error
CREATEing SolrCore 'collection1_shard1_replica_n1': Unable to create core
[collection1_shard1_replica_n1] Caused by: org.apache.solr.schema.IndexSchema$1
cannot be cast to org.apache.solr.core.SolrResourceLoader
[junit4] 2>at
org.apache.solr.core.CoreContainer.create(CoreContainer.java:1318)
[junit4] 2>at
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:95)
[junit4] 2>at
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:367)
[junit4] 2>at
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:397)
[junit4] 2>at
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:181)
[junit4] 2>at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
[junit4] 2>at
org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
[junit4] 2>at
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
[junit4] 2>at
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
[junit4] 2>at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
[junit4] 2>at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
[junit4] 2>at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604)
[junit4] 2>at
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:166)
[junit4] 2>at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604)
[junit4] 2>at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
[junit4] 2>at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
[junit4] 2>at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
[junit4] 2>at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
[junit4] 2>at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
[junit4] 2>at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
[junit4] 2>at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
[junit4] 2>at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
[junit4] 2>at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
[junit4] 2>at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
[junit4] 2>at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
[junit4] 2>at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
[junit4] 2>at
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
[junit4] 2>at
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:717)
[junit4] 2>at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
[junit4] 2>at
org.eclipse.jetty.server.Server.handle(Server.java:500)
[junit4] 2>at
org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
[junit4] 2>at
org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
[junit4] 2>at
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
[junit4] 2>at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
[junit4] 2>at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
[junit4] 2>at
org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
[junit4] 2>at
org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:543)
[junit4] 2>at
org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:398)
[junit4] 2>at
org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:161)
[junit4]
[jira] [Commented] (SOLR-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17203625#comment-17203625
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14151:
--
bq. How is it not threadsafe?
That {{schema}} field that you added is shared memory that is accessed by
different threads. You should either make it volatile, an atomic reference or
alternatively always access it in synchronized blocks.
> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Blocker
> Labels: packagemanager
> Fix For: 8.7
>
> Time Spent: 13.5h
> Remaining Estimate: 0h
>
> Example:
> {code:xml}
>
>
>
>generateNumberParts="0" catenateWords="0"
> catenateNumbers="0" catenateAll="0"/>
>
>
>
>
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed,
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17203454#comment-17203454
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14151:
--
Thanks for fixing the test Noble.
bq. Regarding the async reload of SolrCore, I think you should just remove that
method. It's just dead and untested code now.
bq. (y)
You didn’t remove this yet.
{quote}
Commit cc31e23341ba9e4e409c0bc7d0beb434743744e4 in lucene-solr's branch
refs/heads/master from noblepaul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=cc31e23 ]
SOLR-14151: Fixing TestBulkSchemaConcurrent failures
{quote}
This change is not thread safe, looks like it should.
> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Blocker
> Labels: packagemanager
> Fix For: 8.7
>
> Time Spent: 13.5h
> Remaining Estimate: 0h
>
> Example:
> {code:xml}
>
>
>
>generateNumberParts="0" catenateWords="0"
> catenateNumbers="0" catenateAll="0"/>
>
>
>
>
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed,
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14843) Define strongly-typed cluster configuration API
[
https://issues.apache.org/jira/browse/SOLR-14843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201668#comment-17201668
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14843:
--
I don’t know what Andrzej was thinking when he created this Jira, but what
thought when I saw it was something like:
The “consumer” side (our code, components, etc) could look something like:
{code:java}
int myInt = Config.getInteger(“some.configurable.thing”, default: 30);
String myStr = Config.getString(“some.configurable.string”, default: “foo”);
MyObject myStr = Config.get(“some.configurable.obj”, new SomeSortOfFactory());
{code}
Maybe even be able to support attach an onChange event, like
{code:java}
int myInt = Config.getInteger(“some.configurable.thing”, default: 30, onChange:
(v) -> { setMyInt(v); refresh()});
{code}
or something.
Then, this {{Config}} class could load the configuration from a predictable
hierarchy, something like:
{noformat}
system props > env > cluster props > node props
{noformat}
(don’t know if that’s the right order, and again, there could be more than one
hierarchy), so that a property can be set in the node configuration, but could
be overriden by collection level properties, etc.
One extra nice thing of an approach like this is that we could have an API to
show exactly the current configuration and where each config is coming from,
something like:
{code}
some.configurable.string: {
value: “bar”,
source: “collection property”
}
some.configurable.thing: {
value: 30,
source: “default”
}
{code}
Maybe even a timestamp of the change or something.
> Define strongly-typed cluster configuration API
> ---
>
> Key: SOLR-14843
> URL: https://issues.apache.org/jira/browse/SOLR-14843
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Priority: Major
> Labels: clean-api
> Fix For: master (9.0)
>
>
> Current cluster-level configuration uses a hodgepodge of traditional Solr
> config sources (solr.xml, system properties) and the new somewhat arbitrary
> config files kept in ZK ({{/clusterprops.json, /security.json,
> /packages.json, /autoscaling.json}} etc...). There's no uniform
> strongly-typed API to access and manage these configs - currently each config
> source has its own CRUD, often relying on direct access to Zookeeper. There's
> also no uniform method for monitoring changes to these config sources.
> This issue proposes a uniform config API facade with the following
> characteristics:
> * Using a single hierarchical (or at least key-based) facade for accessing
> any global config.
> * Using strongly-typed sub-system configs instead of opaque Map-s:
> components would no longer deal with JSON parsing/writing, instead they would
> use properly annotated Java objects for config CRUD. Config objects would
> include versioning information (eg. lastModified timestamp).
> * Isolating access to the underlying config persistence layer: components
> would no longer directly interact with Zookeeper or files. Most likely the
> default implementation would continue using different ZK files per-subsystem
> in order to limit the complexity of file formats and to reduce the cost of
> notifications for unmodified parts of the configs.
> * Providing uniform way to register listeners for monitoring changes in
> specific configs: components would no longer need to interact with ZK
> watches, they would instead be notified about modified configs that they are
> interested in.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14883) Add a Muse (CI) configuration file
[ https://issues.apache.org/jira/browse/SOLR-14883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Eduardo Fernandez Lobbe resolved SOLR-14883. -- Fix Version/s: master (9.0) Resolution: Done > Add a Muse (CI) configuration file > -- > > Key: SOLR-14883 > URL: https://issues.apache.org/jira/browse/SOLR-14883 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Thomas DuBuisson >Priority: Trivial > Fix For: master (9.0) > > Time Spent: 1h 50m > Remaining Estimate: 0h > > This ticket is a continuation of conversation that started > https://issues.apache.org/jira/browse/SOLR-14819?filter=-2 and was also on > the mailing list. > > The Apache infrastructure team has installed the Muse GitHub application. In > order for Lucene-Solr to benefit the application must understand how to build > the project. While it has build heuristics, it does not guess between JDK8 > or JDK11 (two JDKs most supported by several static analysis tools). Thus, > this configuration explicitly instructs use of JDK11. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-14883) Add a Muse (CI) configuration file
[ https://issues.apache.org/jira/browse/SOLR-14883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Eduardo Fernandez Lobbe reassigned SOLR-14883: Assignee: Tomas Eduardo Fernandez Lobbe > Add a Muse (CI) configuration file > -- > > Key: SOLR-14883 > URL: https://issues.apache.org/jira/browse/SOLR-14883 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Thomas DuBuisson >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Trivial > Fix For: master (9.0) > > Time Spent: 1h 50m > Remaining Estimate: 0h > > This ticket is a continuation of conversation that started > https://issues.apache.org/jira/browse/SOLR-14819?filter=-2 and was also on > the mailing list. > > The Apache infrastructure team has installed the Muse GitHub application. In > order for Lucene-Solr to benefit the application must understand how to build > the project. While it has build heuristics, it does not guess between JDK8 > or JDK11 (two JDKs most supported by several static analysis tools). Thus, > this configuration explicitly instructs use of JDK11. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Closed] (SOLR-9827) Make ConcurrentUpdateSolrClient create RemoteSolrException instead of just SolrException for remote errors
[ https://issues.apache.org/jira/browse/SOLR-9827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Eduardo Fernandez Lobbe closed SOLR-9827. --- > Make ConcurrentUpdateSolrClient create RemoteSolrException instead of just > SolrException for remote errors > -- > > Key: SOLR-9827 > URL: https://issues.apache.org/jira/browse/SOLR-9827 > Project: Solr > Issue Type: Improvement >Reporter: Tomas Eduardo Fernandez Lobbe >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Minor > Fix For: 6.4, 7.0 > > Attachments: SOLR-9827.patch > > > Also, improve the exception message to include the remote error message when > present. Specially when Solr is logging these errors (e.g. > DistributedUpdateProcessor), this should make it easier to understand that > the error was in the remote host and not in the one logging this exception. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10391) ConfigSet overwrite
[ https://issues.apache.org/jira/browse/SOLR-10391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Eduardo Fernandez Lobbe resolved SOLR-10391. -- Fix Version/s: 8.7 master (9.0) Assignee: Tomas Eduardo Fernandez Lobbe Resolution: Fixed > ConfigSet overwrite > --- > > Key: SOLR-10391 > URL: https://issues.apache.org/jira/browse/SOLR-10391 > Project: Solr > Issue Type: New Feature >Reporter: Ishan Chattopadhyaya >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Major > Fix For: master (9.0), 8.7 > > Time Spent: 3h > Remaining Estimate: 0h > > As a follow up to SOLR-6736, we need a way for a user to overwrite an > existing configset and/or delete an existing configset. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-9827) Make ConcurrentUpdateSolrClient create RemoteSolrException instead of just SolrException for remote errors
[ https://issues.apache.org/jira/browse/SOLR-9827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Eduardo Fernandez Lobbe resolved SOLR-9827. - Fix Version/s: 6.4 7.0 Resolution: Fixed > Make ConcurrentUpdateSolrClient create RemoteSolrException instead of just > SolrException for remote errors > -- > > Key: SOLR-9827 > URL: https://issues.apache.org/jira/browse/SOLR-9827 > Project: Solr > Issue Type: Improvement >Reporter: Tomas Eduardo Fernandez Lobbe >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Minor > Fix For: 7.0, 6.4 > > Attachments: SOLR-9827.patch > > > Also, improve the exception message to include the remote error message when > present. Specially when Solr is logging these errors (e.g. > DistributedUpdateProcessor), this should make it easier to understand that > the error was in the remote host and not in the one logging this exception. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14582) Expose IWC.setMaxCommitMergeWaitMillis as an expert feature in Solr's index config
[
https://issues.apache.org/jira/browse/SOLR-14582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe resolved SOLR-14582.
--
Resolution: Fixed
> Expose IWC.setMaxCommitMergeWaitMillis as an expert feature in Solr's index
> config
> --
>
> Key: SOLR-14582
> URL: https://issues.apache.org/jira/browse/SOLR-14582
> Project: Solr
> Issue Type: Improvement
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Trivial
> Fix For: master (9.0), 8.7
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> LUCENE-8962 added the ability to merge segments synchronously on commit. This
> isn't done by default and the default {{MergePolicy}} won't do it, but custom
> merge policies can take advantage of this. Solr allows plugging in custom
> merge policies, so if someone wants to make use of this feature they could,
> however, they need to set {{IndexWriterConfig.maxCommitMergeWaitSeconds}} to
> something greater than 0.
> Since this is an expert feature, I plan to document it only in javadoc and
> not the ref guide.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17198462#comment-17198462
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14151:
--
bq. The reverts are done to an accidental commit I did. not to master
I think you are confused. This is very much master:
https://github.com/apache/lucene-solr/commit/27a14fe48139019a4c09ba072751e093fc5cb5f1
https://github.com/apache/lucene-solr/commit/cbb1659640cd51be8b403eda8399c527af1c848e,
you just removed the bot comments from the Jira issue, not the actual commits.
Again, I’m not against this feature, I just want to know what you plan to do
with the Jenkins failures. You keep saying that this commit didn’t introduce
the bug, but those tests were passing before and now they aren’t, so something
needs fixing, and if it will take time, please revert your commits. If this is
something that only happens in Jenkins, you could push to a branch and have a
Jenkins job point to it? just an idea
> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: packagemanager
> Fix For: 8.7
>
> Time Spent: 12h 50m
> Remaining Estimate: 0h
>
> Example:
> {code:xml}
>
>
>
>generateNumberParts="0" catenateWords="0"
> catenateNumbers="0" catenateAll="0"/>
>
>
>
>
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed,
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197975#comment-17197975
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14151:
--
Noble, when you submit code that breaks the build you are supposed to either
fix immediately or revert until you can stabilize and then merge again. This is
not something new, it's common sense, and it's what everyone else does. This
has been failing for more than a week, accounting for close to 60% of the
failures. You keep patching and patching, reverting and reverting the reverts,
[without clear understanding of the
fix|https://github.com/apache/lucene-solr/pull/1815#issuecomment-687092388]. If
it's some other bug that this is hitting, you should still revert until that
other bug is fixed, it's that simple.
bq. There are 3 options
lets do #3 until #1 is done. I'm fine with #2 too, but that would be a
backwards incompatible change, so should be master only.
> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: packagemanager
> Fix For: 8.7
>
> Time Spent: 12h 50m
> Remaining Estimate: 0h
>
> Example:
> {code:xml}
>
>
>
>generateNumberParts="0" catenateWords="0"
> catenateNumbers="0" catenateAll="0"/>
>
>
>
>
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed,
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197184#comment-17197184
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14151:
--
Looking at the 7 days report from Hoss, the failures described here account for
the top 5 most failed tests, causing ~60% of the total failures.
> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: packagemanager
> Fix For: 8.7
>
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> Example:
> {code:xml}
>
>
>
>generateNumberParts="0" catenateWords="0"
> catenateNumbers="0" catenateAll="0"/>
>
>
>
>
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed,
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197178#comment-17197178
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14151:
--
Got it, reload is buggy, but the changes introduced by this Jira issue are
triggering those way more than before (looking at my inbox, I count at least 5
to 10 failures a day on these tests since the commits here). What do you
suggest we do?
> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: packagemanager
> Fix For: 8.7
>
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> Example:
> {code:xml}
>
>
>
>generateNumberParts="0" catenateWords="0"
> catenateNumbers="0" catenateAll="0"/>
>
>
>
>
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed,
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17196663#comment-17196663
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14151:
--
Maybe a core reload bug that the new code here is triggering? Anyways, I think
the safest is to revert until whatever bug this is hitting is resolved.
> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: packagemanager
> Fix For: 8.7
>
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> Example:
> {code:xml}
>
>
>
>generateNumberParts="0" catenateWords="0"
> catenateNumbers="0" catenateAll="0"/>
>
>
>
>
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed,
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14849) Investigate test failures in TestReRankQParserPlugin.testMinExactCount
[
https://issues.apache.org/jira/browse/SOLR-14849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe resolved SOLR-14849.
--
Fix Version/s: 8.6
master (9.0)
Resolution: Fixed
I haven't seen failures since this commit. I'll resolve the issue, we can
reopen if failures occur again
> Investigate test failures in TestReRankQParserPlugin.testMinExactCount
> --
>
> Key: SOLR-14849
> URL: https://issues.apache.org/jira/browse/SOLR-14849
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Minor
> Fix For: master (9.0), 8.6
>
>
> I've seen a couple failures in Jenkins, such as:
> {noformat}
> FAILED: org.apache.solr.search.TestReRankQParserPlugin.testMinExactCount
> Error Message:
> Exception during query
> Stack Trace:
> java.lang.RuntimeException: Exception during query
> at
> __randomizedtesting.SeedInfo.seed([D74824A60D443A78:A2C81E3EE299C40F]:0)
> at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:1016)
> at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:976)
> at
> org.apache.solr.search.TestReRankQParserPlugin.testMinExactCount(TestReRankQParserPlugin.java:675)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
>
[jira] [Assigned] (SOLR-14849) Investigate test failures in TestReRankQParserPlugin.testMinExactCount
[
https://issues.apache.org/jira/browse/SOLR-14849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe reassigned SOLR-14849:
Assignee: Tomas Eduardo Fernandez Lobbe
> Investigate test failures in TestReRankQParserPlugin.testMinExactCount
> --
>
> Key: SOLR-14849
> URL: https://issues.apache.org/jira/browse/SOLR-14849
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Minor
> Fix For: master (9.0), 8.6
>
>
> I've seen a couple failures in Jenkins, such as:
> {noformat}
> FAILED: org.apache.solr.search.TestReRankQParserPlugin.testMinExactCount
> Error Message:
> Exception during query
> Stack Trace:
> java.lang.RuntimeException: Exception during query
> at
> __randomizedtesting.SeedInfo.seed([D74824A60D443A78:A2C81E3EE299C40F]:0)
> at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:1016)
> at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:976)
> at
> org.apache.solr.search.TestReRankQParserPlugin.testMinExactCount(TestReRankQParserPlugin.java:675)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
>
[jira] [Commented] (SOLR-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17196426#comment-17196426
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14151:
--
Thanks Noble, I appreciate you keep looking into this. I'm a bit worried with
this change. Looking through the Jenkins failures, I can see lots of failures
that seem to have started after these commits:
• FAILED: org.apache.solr.pkg.TestPackages.classMethod
• FAILED:
org.apache.solr.schema.PreAnalyzedFieldManagedSchemaCloudTest.testAdd2Fields
• FAILED:
org.apache.solr.schema.ManagedSchemaRoundRobinCloudTest.testAddFieldsRoundRobin
Maybe you should consider reverting until this gets more stable?
> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: packagemanager
> Fix For: 8.7
>
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> Example:
> {code:xml}
>
>
>
>generateNumberParts="0" catenateWords="0"
> catenateNumbers="0" catenateAll="0"/>
>
>
>
>
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed,
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14723) Rremove the class atribute for the caches in the _default/example configsets
[
https://issues.apache.org/jira/browse/SOLR-14723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17195751#comment-17195751
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14723:
--
Thanks for taking this [~shshnk28]. Your changes look good, but you should
remove the "class" attribute from other caches, not only filterCache (look at
{{queryResultCache}}, {{documentCache}} and {{fieldValueCache}})
bq. But I ran ant clean test twice and one test is failing in the modified
branch. The same does not fail in base branch which is without these commits.
Some tests are flaky, so they may be related for reasons unrelated to your
change unfortunately. That said, I haven't seen this test be very flaky, could
you paste the failure log here?
bq. The suggestion was to change it in default and example configsets but I
have also changed those which are under test-files.
Thanks, I think that's a good idea
bq. PS: ant clean test takes about an hr to run which does not help with rapid
testing
Yes, our tests take a long time (there are some efforts to speed them up). Some
things you can do to speedup is to run tests only in the components you want to
test (i.e. inside {{solr/core}} or {{solr/contrib/dataimporthandler}}, etc).
Also, when a test fails it'll print the exact command with which you can re-run
the same test. It'll look something like:
{noformat}
NOTE: reproduce with: ant test -Dtestcase=IndexSizeTriggerMixedBoundsTest
-Dtests.seed=CC3BE9E659E38BB -Dtests.slow=true -Dtests.locale=ar-IQ
-Dtests.timezone=America/St_Lucia -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
{noformat}
A good start after seeing a failure is to run that line again.
> Rremove the class atribute for the caches in the _default/example configsets
>
>
> Key: SOLR-14723
> URL: https://issues.apache.org/jira/browse/SOLR-14723
> Project: Solr
> Issue Type: Improvement
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Trivial
> Labels: newdev
>
> In 8.x branch, the default and example configsets include LRUCache and
> FastLRUCache as the implementation for the various caches.
> {code:xml}
> size="512"
> initialSize="512"
> autowarmCount="0"/>
> {code}
> Those implementations are deprecated. We should remove the attribute
> completely and let the default take over (as it's in master), this should
> make upgrading configsets easier:
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-10391) ConfigSet overwrite
[ https://issues.apache.org/jira/browse/SOLR-10391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194580#comment-17194580 ] Tomas Eduardo Fernandez Lobbe commented on SOLR-10391: -- bq. Can we leverage and/or consolidate code in ZkMaintenanceUtils for any of this? One of the advantages of the ConfigSet API is that it allows users to manage configsets without needing direct access to ZooKeeper > ConfigSet overwrite > --- > > Key: SOLR-10391 > URL: https://issues.apache.org/jira/browse/SOLR-10391 > Project: Solr > Issue Type: New Feature >Reporter: Ishan Chattopadhyaya >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > As a follow up to SOLR-6736, we need a way for a user to overwrite an > existing configset and/or delete an existing configset. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-10391) ConfigSet overwrite
[ https://issues.apache.org/jira/browse/SOLR-10391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194579#comment-17194579 ] Tomas Eduardo Fernandez Lobbe commented on SOLR-10391: -- DELETE is already possible. I created a PR to allow overwrites > ConfigSet overwrite > --- > > Key: SOLR-10391 > URL: https://issues.apache.org/jira/browse/SOLR-10391 > Project: Solr > Issue Type: New Feature >Reporter: Ishan Chattopadhyaya >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > As a follow up to SOLR-6736, we need a way for a user to overwrite an > existing configset and/or delete an existing configset. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-10391) ConfigSet overwrite
[ https://issues.apache.org/jira/browse/SOLR-10391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Eduardo Fernandez Lobbe updated SOLR-10391: - Summary: ConfigSet overwrite (was: ConfigSet delete/overwrite) > ConfigSet overwrite > --- > > Key: SOLR-10391 > URL: https://issues.apache.org/jira/browse/SOLR-10391 > Project: Solr > Issue Type: New Feature >Reporter: Ishan Chattopadhyaya >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > As a follow up to SOLR-6736, we need a way for a user to overwrite an > existing configset and/or delete an existing configset. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9449) Skip non-competitive documents when sort by _doc with search after
[
https://issues.apache.org/jira/browse/LUCENE-9449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17193758#comment-17193758
]
Tomas Eduardo Fernandez Lobbe commented on LUCENE-9449:
---
I didn't look at this change in detail, but there are some failures in Jenkins
that nay be related to this commit:
{noformat}
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/27938/
Java: 64bit/jdk-11.0.6 -XX:+UseCompressedOops -XX:+UseParallelGC
1 tests failed.
FAILED:
org.apache.lucene.search.TestIndexSortSortedNumericDocValuesRangeQuery.testSameHitsAsPointRangeQuery
Error Message:
java.lang.AssertionError
Stack Trace:
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([1BAE2B7423173E7C:20AD3790C6015356]:0)
at
org.apache.lucene.search.ConjunctionDISI.doNext(ConjunctionDISI.java:195)
at
org.apache.lucene.search.ConjunctionDISI.nextDoc(ConjunctionDISI.java:240)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:254)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:211)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
at
org.apache.lucene.search.AssertingBulkScorer.score(AssertingBulkScorer.java:71)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:741)
at
org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:72)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:528)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:657)
at
org.apache.lucene.search.IndexSearcher.searchAfter(IndexSearcher.java:638)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:559)
at
org.apache.lucene.search.TestIndexSortSortedNumericDocValuesRangeQuery.assertSameHits(TestIndexSortSortedNumericDocValuesRangeQuery.java:87)
at
org.apache.lucene.search.TestIndexSortSortedNumericDocValuesRangeQuery.testSameHitsAsPointRangeQuery(TestIndexSortSortedNumericDocValuesRangeQuery.java:76)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1754)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:942)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:978)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:992)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:370)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:819)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:470)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:951)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:836)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:887)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:898)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
[jira] [Reopened] (SOLR-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe reopened SOLR-14151:
--
This test also started failing since the last commit in this Jira issue:
{{FAILED: org.apache.solr.pkg.TestPackages.classMethod}}. [Here is the first
failure|http://example.com|https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/426/]
> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: packagemanager
> Fix For: 8.7
>
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> Example:
> {code:xml}
>
>
>
>generateNumberParts="0" catenateWords="0"
> catenateNumbers="0" catenateAll="0"/>
>
>
>
>
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed,
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14404) CoreContainer level custom requesthandlers
[
https://issues.apache.org/jira/browse/SOLR-14404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17193187#comment-17193187
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14404:
--
This Jira issue is marked as closed, but from the conversations there still
seem to be some more work to do? I see this test still failing a lot in
Jenkins.
> CoreContainer level custom requesthandlers
> --
>
> Key: SOLR-14404
> URL: https://issues.apache.org/jira/browse/SOLR-14404
> Project: Solr
> Issue Type: New Feature
> Components: packages
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.6
>
> Attachments: 291.zip, 555.zip, 670.zip
>
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> caveats:
> * The class should be annotated with {{org.apache.solr.api.EndPoint}}.
> Which means only V2 APIs are supported
> * The path should have prefix {{/api/plugin}}
> add a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin",
> "class": "full.ClassName",
> "path-prefix" : "some-path-prefix"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> add a plugin from a package
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin",
> "class": "pkgName:full.ClassName" ,
> "path-prefix" : "some-path-prefix" ,
> "version: "1.0"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> remove a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "remove": "myplugin"
> }' http://localhost:8983/api/cluster/plugins
> {code}
> The configuration will be stored in the {{clusterprops.json}}
> as
> {code:java}
> {
> "plugins" : {
> "myplugin" : {"class": "full.ClassName", "path-prefix" : "some-path-prefix" }
> }
> }
> {code}
> example plugin
> {code:java}
> public class MyPlugin {
> private final CoreContainer coreContainer;
> public MyPlugin(CoreContainer coreContainer) {
> this.coreContainer = coreContainer;
> }
> @EndPoint(path = "/$path-prefix/path1",
> method = METHOD.GET,
> permission = READ)
> public void call(SolrQueryRequest req, SolrQueryResponse rsp){
> rsp.add("myplugin.version", "2.0");
> }
> }
> {code}
> This plugin will be accessible on all nodes at
> {{/api/some-path-prefix/path1}}. It's possible to add more methods at
> different paths. Ensure that all paths start with {{$path-prefix}} because
> that is the prefix in which the plugin is registered with. So
> {{/some-path-prefix/path2}} , {{/some-path-prefix/my/deeply/nested/path}} are
> all valid paths.
> It's possible that the user chooses to register the plugin with a different
> name. In that case , use a template variable as follows in paths
> {{/cluster/some/other/path}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17193179#comment-17193179
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14151:
--
There are still a bunch of failures in {{TestBulkSchemaConcurrent}}, are those
related to these changes?
> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: packagemanager
> Fix For: 8.7
>
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> Example:
> {code:xml}
>
>
>
>generateNumberParts="0" catenateWords="0"
> catenateNumbers="0" catenateAll="0"/>
>
>
>
>
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed,
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14723) Rremove the class atribute for the caches in the _default/example configsets
[
https://issues.apache.org/jira/browse/SOLR-14723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17193071#comment-17193071
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14723:
--
Yes, unfortunately branch 8x doesn't have gradle, so you need to run with
{{ant}}. jdk11 is OK
> Rremove the class atribute for the caches in the _default/example configsets
>
>
> Key: SOLR-14723
> URL: https://issues.apache.org/jira/browse/SOLR-14723
> Project: Solr
> Issue Type: Improvement
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Trivial
> Labels: newdev
>
> In 8.x branch, the default and example configsets include LRUCache and
> FastLRUCache as the implementation for the various caches.
> {code:xml}
> size="512"
> initialSize="512"
> autowarmCount="0"/>
> {code}
> Those implementations are deprecated. We should remove the attribute
> completely and let the default take over (as it's in master), this should
> make upgrading configsets easier:
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14849) Investigate test failures in TestReRankQParserPlugin.testMinExactCount
Tomas Eduardo Fernandez Lobbe created SOLR-14849:
Summary: Investigate test failures in
TestReRankQParserPlugin.testMinExactCount
Key: SOLR-14849
URL: https://issues.apache.org/jira/browse/SOLR-14849
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Tomas Eduardo Fernandez Lobbe
I've seen a couple failures in Jenkins, such as:
{noformat}
FAILED: org.apache.solr.search.TestReRankQParserPlugin.testMinExactCount
Error Message:
Exception during query
Stack Trace:
java.lang.RuntimeException: Exception during query
at
__randomizedtesting.SeedInfo.seed([D74824A60D443A78:A2C81E3EE299C40F]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:1016)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:976)
at
org.apache.solr.search.TestReRankQParserPlugin.testMinExactCount(TestReRankQParserPlugin.java:675)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
[jira] [Commented] (SOLR-14843) Define strongly-typed cluster configuration API
[
https://issues.apache.org/jira/browse/SOLR-14843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17192618#comment-17192618
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14843:
--
Thanks for starting this work Andrzej, I was thinking about this same thing the
other day. I think Solr developers and users will both benefit from having a
consistent way to get and set configuration.
bq. Using a single hierarchical (or at least key-based) facade for accessing
any global config.
You are thinking in something like "cluster configuration > node configuration
> code defaults..." or something like that? I think that makes sense. The one
tricky part is that sometimes hierarchy may need fo follow a physical path
(cluster config -> node config -> default) and sometimes a logical path
(cluster config -> collection properties -> configset). Unless you are talking
about a completely different thing.
bq. I would suggest this new system allows setting default configuration at dev
time or pre deploy time (before ZK is even started) that are reflected in
deployed clusters.
+1. I think it's important to be able to configure the cluster before starting
the cluster.
bq. Ilan Ginzburg Code/config evolution is a general issue that is not specific
to this proposal. I
I think what Ilan is talking about is similar to what I mentioned in the config
discussion in the dev list (please correct me if I'm wrong, Ilan)? If a new
version of a component that needs to be deployed requires a new set of
configurations, it's easier if those configurations can be deployed together
with the code (in the dev list discussion, this is one of my points in favor of
a node configuration)
> Define strongly-typed cluster configuration API
> ---
>
> Key: SOLR-14843
> URL: https://issues.apache.org/jira/browse/SOLR-14843
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Priority: Major
> Labels: clean-api
> Fix For: master (9.0)
>
>
> Current cluster-level configuration uses a hodgepodge of traditional Solr
> config sources (solr.xml, system properties) and the new somewhat arbitrary
> config files kept in ZK ({{/clusterprops.json, /security.json,
> /packages.json, /autoscaling.json}} etc...). There's no uniform
> strongly-typed API to access and manage these configs - currently each config
> source has its own CRUD, often relying on direct access to Zookeeper. There's
> also no uniform method for monitoring changes to these config sources.
> This issue proposes a uniform config API facade with the following
> characteristics:
> * Using a single hierarchical (or at least key-based) facade for accessing
> any global config.
> * Using strongly-typed sub-system configs instead of opaque Map-s:
> components would no longer deal with JSON parsing/writing, instead they would
> use properly annotated Java objects for config CRUD. Config objects would
> include versioning information (eg. lastModified timestamp).
> * Isolating access to the underlying config persistence layer: components
> would no longer directly interact with Zookeeper or files. Most likely the
> default implementation would continue using different ZK files per-subsystem
> in order to limit the complexity of file formats and to reduce the cost of
> notifications for unmodified parts of the configs.
> * Providing uniform way to register listeners for monitoring changes in
> specific configs: components would no longer need to interact with ZK
> watches, they would instead be notified about modified configs that they are
> interested in.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14723) Rremove the class atribute for the caches in the _default/example configsets
[
https://issues.apache.org/jira/browse/SOLR-14723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17192342#comment-17192342
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14723:
--
bq. Should I do my changes on the master branch in my forked repo and raise a
PR against the master in main repo?
While this is usually the way to go, this Jira issue in particular is about
removing the {{class}} attribute from the 8.x configsets (you won't find the
attribute in master anymore). So you should work on your fork's
{{branch_8x}}(or create a branch our of {{branch_8x}}) and then create a PR
against {{branch_8x}} of the main Apache GH repo.
> Rremove the class atribute for the caches in the _default/example configsets
>
>
> Key: SOLR-14723
> URL: https://issues.apache.org/jira/browse/SOLR-14723
> Project: Solr
> Issue Type: Improvement
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Trivial
> Labels: newdev
>
> In 8.x branch, the default and example configsets include LRUCache and
> FastLRUCache as the implementation for the various caches.
> {code:xml}
> size="512"
> initialSize="512"
> autowarmCount="0"/>
> {code}
> Those implementations are deprecated. We should remove the attribute
> completely and let the default take over (as it's in master), this should
> make upgrading configsets easier:
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17192315#comment-17192315
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14151:
--
Sorry to be late at your latest comments Noble (It was a long weekend in the US
and I was out). Regarding [the async reload of
SolrCore|https://github.com/apache/lucene-solr/pull/1815#discussion_r483241419],
I think you should just remove that method. It's just dead and untested code
now.
> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: packagemanager
> Fix For: 8.7
>
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> Example:
> {code:xml}
>
>
>
>generateNumberParts="0" catenateWords="0"
> catenateNumbers="0" catenateAll="0"/>
>
>
>
>
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed,
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17188759#comment-17188759
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14151:
--
Sorry, I'm a very lost. [PR
1815|https://github.com/apache/lucene-solr/pull/1815] looks similar but
different than [the commit to
8.x|https://github.com/apache/lucene-solr/commit/bd22f9a]? is the commit to 8.x
work in progress? About my question [in PR
1804|https://github.com/apache/lucene-solr/pull/1804], you say it's not a
problem but it's handled differently in [PR
1815|https://github.com/apache/lucene-solr/pull/1815]. Could you explain what's
going on?
> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: packagemanager
> Fix For: 8.7
>
> Time Spent: 11h 40m
> Remaining Estimate: 0h
>
> Example:
> {code:xml}
>
>
>
>generateNumberParts="0" catenateWords="0"
> catenateNumbers="0" catenateAll="0"/>
>
>
>
>
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed,
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14778) Disabling UpdateLog leads to silently lost updates
[ https://issues.apache.org/jira/browse/SOLR-14778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17188743#comment-17188743 ] Tomas Eduardo Fernandez Lobbe commented on SOLR-14778: -- Got it, I said that because it seemed from the description of the jira (I didn't look at the Slack conversation) that it was something that some commands would have issues with, but regular recovery currently would suffer it too, this means, every Solr cluster in cloud mode would be hit unless they have a single "indexing" replica (NRT or TLOG) per shard. bq. If there is no updateLog, then recovery "could" work via replication, naturally. I think this could be tricky. Thinking in a case like you described (all updates are batches + commits), a recovery could only succeed if there are no updates on the leader while the replica is recovering because there would be no buffering. I guess maybe an option could be to allow update log only for buffering? may complicate the logic a bit so we'd need to balance it against the potential benefits, right? is it the extra disk write of the tlog? bq. REJECTING: Fail updates so that the client can retry again once the operation is complete. I think something like this could work (as I said, I think recoveries would fail on updates during the recovery time), Although I don't think I'd model it as replica state, since it would be the leader that needs to start rejecting updates because one or more replicas are recovering (or doing some operation that requires tlog). I'm thinking it could be modeled as a different RecoveryStrategy where the the leader stops accepting updates when a replica wants to start recovering? something similar would have to be triggered by those commands that [~megancarey] was mentioning. > Disabling UpdateLog leads to silently lost updates > -- > > Key: SOLR-14778 > URL: https://issues.apache.org/jira/browse/SOLR-14778 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud, update >Affects Versions: 8.6.1 >Reporter: Megan Carey >Priority: Minor > > Solr currently "supports" disabling the UpdateLog, though it is "required" > for NRT replicas (per the > [docs|https://lucene.apache.org/solr/guide/8_6/updatehandlers-in-solrconfig.html#transaction-log]). > However, when the update log is disabled and a replica is in BUFFERING state > (e.g. during MigrateCmd or SplitShardCmd), updates are *lost silently*. While > most users will likely never consider disabling the updateLog, it seems > pertinent to provide a better support option. > Options as discussed in [ASF > Slack|https://the-asf.slack.com/archives/CEKUCUNE9/p1598373062262300]: > # No longer support disabling the updateLog as it is considered an integral > feature in SolrCloud. This might be undesirable for use cases where some data > loss is acceptable and the updateLog takes up too much space. > # Improve Solr documentation to explicitly outline the risks of disabling > the updateLog. > # Add logging to indicate when an update is swallowed in this state. > # _My preferred option:_ Support disabling the updateLog by providing > additional replica states besides BUFFERING, so that there is no data loss > when updateLog is disabled and replica goes offline for an operation like > split. Some ideas: > ## REJECTING: Fail updates so that the client can retry again once the > operation is complete. > ## BLOCKING: Stall update until operation is complete, and then execute > update. > Feedback is welcome; once we establish a path forward I'd be happy to pick it > up. If others are interested I can document my findings as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17188077#comment-17188077
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14151:
--
Noble, note that I asked for some clarification in your PR:
https://github.com/apache/lucene-solr/pull/1804
> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: packagemanager
> Fix For: 8.7
>
> Time Spent: 10h 40m
> Remaining Estimate: 0h
>
> Example:
> {code:xml}
>
>
>
>generateNumberParts="0" catenateWords="0"
> catenateNumbers="0" catenateAll="0"/>
>
>
>
>
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed,
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14778) Disabling UpdateLog leads to silently lost updates
[
https://issues.apache.org/jira/browse/SOLR-14778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17188032#comment-17188032
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14778:
--
I didn't know disabling the update log for SolrCloud use cases would work at
all. How does recovery work? These are the first line of the recovery code:
{code:java}
UpdateLog ulog;
ulog = core.getUpdateHandler().getUpdateLog();
if (ulog == null) {
SolrException.log(log, "No UpdateLog found - cannot recover.");
recoveryFailed(core, zkController, baseUrl, coreZkNodeName,
this.coreDescriptor);
return;
}
{code}
Or is it for the single-replica cases only?
> Disabling UpdateLog leads to silently lost updates
> --
>
> Key: SOLR-14778
> URL: https://issues.apache.org/jira/browse/SOLR-14778
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud, update
>Affects Versions: 8.6.1
>Reporter: Megan Carey
>Priority: Minor
>
> Solr currently "supports" disabling the UpdateLog, though it is "required"
> for NRT replicas (per the
> [docs|https://lucene.apache.org/solr/guide/8_6/updatehandlers-in-solrconfig.html#transaction-log]).
> However, when the update log is disabled and a replica is in BUFFERING state
> (e.g. during MigrateCmd or SplitShardCmd), updates are *lost silently*. While
> most users will likely never consider disabling the updateLog, it seems
> pertinent to provide a better support option.
> Options as discussed in [ASF
> Slack|https://the-asf.slack.com/archives/CEKUCUNE9/p1598373062262300]:
> # No longer support disabling the updateLog as it is considered an integral
> feature in SolrCloud. This might be undesirable for use cases where some data
> loss is acceptable and the updateLog takes up too much space.
> # Improve Solr documentation to explicitly outline the risks of disabling
> the updateLog.
> # Add logging to indicate when an update is swallowed in this state.
> # _My preferred option:_ Support disabling the updateLog by providing
> additional replica states besides BUFFERING, so that there is no data loss
> when updateLog is disabled and replica goes offline for an operation like
> split. Some ideas:
> ## REJECTING: Fail updates so that the client can retry again once the
> operation is complete.
> ## BLOCKING: Stall update until operation is complete, and then execute
> update.
> Feedback is welcome; once we establish a path forward I'd be happy to pick it
> up. If others are interested I can document my findings as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14774) HealthCheckHandler shouldn't be an implicit SolrCore level handler and should be configurable
[
https://issues.apache.org/jira/browse/SOLR-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17187905#comment-17187905
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14774:
--
Hi Noble,
As I mentioned in my previous comment, this was already supposed to be
configurable through {{solr.xml}} like all other top level handlers. As you can
see in the code, I didn’t change NodeConfig, it already had configuration to
set the class for this handler, it was just not being used correctly (it was in
the first commit, but broke later on).
I understand you have the idea of deprecating {{solr.xml}}, but as of now, it’s
not deprecated and it’s the right place to put top level handler configuration.
If you want to discuss more about this, there is a thread going on on the dev
list, feel free to add your inputs there.
> HealthCheckHandler shouldn't be an implicit SolrCore level handler and should
> be configurable
> -
>
> Key: SOLR-14774
> URL: https://issues.apache.org/jira/browse/SOLR-14774
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Fix For: master (9.0), 8.7
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> While trying to use the HealthCheckHandler I noticed that:
> * CoreContainer has some logic to read config from {{solr.xml}}, however,
> this is never used, and the handler is constructed explicitly inside
> {{InfoHandler}}. This means you can't plugin a different implementation.
> * Also noticed that it was added as an implicit plugin to the {{SolrCore}}.
> which means one could access the handler like
> {{//admin/health}}, however, this will never work, since
> it uses a parameterless constructor, which leaves the handler in an invalid
> state [1]. I honestly don't know why it's being added to the {{SolrCore}},
> this is supposed to be a node level handler, and for SolrCore one could use
> the {{PingRequestHandler}}
>
> [1]
> {noformat}
> 2020-08-21 21:14:06.094 ERROR (qtp599782425-18) [c:test s:shard1 r:core_node4
> x:test_shard1_replica_n2] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException: CoreContainer is either not
> initialized or shutting down
> at
> org.apache.solr.handler.admin.HealthCheckHandler.handleRequestBody(HealthCheckHandler.java:96)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2606)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:812)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:588)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
>
[jira] [Resolved] (SOLR-14774) HealthCheckHandler shouldn't be an implicit SolrCore level handler and should be configurable
[
https://issues.apache.org/jira/browse/SOLR-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe resolved SOLR-14774.
--
Fix Version/s: 8.7
master (9.0)
Resolution: Fixed
> HealthCheckHandler shouldn't be an implicit SolrCore level handler and should
> be configurable
> -
>
> Key: SOLR-14774
> URL: https://issues.apache.org/jira/browse/SOLR-14774
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Fix For: master (9.0), 8.7
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> While trying to use the HealthCheckHandler I noticed that:
> * CoreContainer has some logic to read config from {{solr.xml}}, however,
> this is never used, and the handler is constructed explicitly inside
> {{InfoHandler}}. This means you can't plugin a different implementation.
> * Also noticed that it was added as an implicit plugin to the {{SolrCore}}.
> which means one could access the handler like
> {{//admin/health}}, however, this will never work, since
> it uses a parameterless constructor, which leaves the handler in an invalid
> state [1]. I honestly don't know why it's being added to the {{SolrCore}},
> this is supposed to be a node level handler, and for SolrCore one could use
> the {{PingRequestHandler}}
>
> [1]
> {noformat}
> 2020-08-21 21:14:06.094 ERROR (qtp599782425-18) [c:test s:shard1 r:core_node4
> x:test_shard1_replica_n2] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException: CoreContainer is either not
> initialized or shutting down
> at
> org.apache.solr.handler.admin.HealthCheckHandler.handleRequestBody(HealthCheckHandler.java:96)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2606)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:812)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:588)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
>
[jira] [Updated] (SOLR-14774) HealthCheckHandler shouldn't be an implicit SolrCore level handler and should be configurable
[
https://issues.apache.org/jira/browse/SOLR-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe updated SOLR-14774:
-
Issue Type: Bug (was: Improvement)
> HealthCheckHandler shouldn't be an implicit SolrCore level handler and should
> be configurable
> -
>
> Key: SOLR-14774
> URL: https://issues.apache.org/jira/browse/SOLR-14774
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> While trying to use the HealthCheckHandler I noticed that:
> * CoreContainer has some logic to read config from {{solr.xml}}, however,
> this is never used, and the handler is constructed explicitly inside
> {{InfoHandler}}. This means you can't plugin a different implementation.
> * Also noticed that it was added as an implicit plugin to the {{SolrCore}}.
> which means one could access the handler like
> {{//admin/health}}, however, this will never work, since
> it uses a parameterless constructor, which leaves the handler in an invalid
> state [1]. I honestly don't know why it's being added to the {{SolrCore}},
> this is supposed to be a node level handler, and for SolrCore one could use
> the {{PingRequestHandler}}
>
> [1]
> {noformat}
> 2020-08-21 21:14:06.094 ERROR (qtp599782425-18) [c:test s:shard1 r:core_node4
> x:test_shard1_replica_n2] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException: CoreContainer is either not
> initialized or shutting down
> at
> org.apache.solr.handler.admin.HealthCheckHandler.handleRequestBody(HealthCheckHandler.java:96)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2606)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:812)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:588)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
>
[jira] [Assigned] (SOLR-14774) HealthCheckHandler shouldn't be an implicit SolrCore level handler and should be configurable
[
https://issues.apache.org/jira/browse/SOLR-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe reassigned SOLR-14774:
Assignee: Tomas Eduardo Fernandez Lobbe
> HealthCheckHandler shouldn't be an implicit SolrCore level handler and should
> be configurable
> -
>
> Key: SOLR-14774
> URL: https://issues.apache.org/jira/browse/SOLR-14774
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> While trying to use the HealthCheckHandler I noticed that:
> * CoreContainer has some logic to read config from {{solr.xml}}, however,
> this is never used, and the handler is constructed explicitly inside
> {{InfoHandler}}. This means you can't plugin a different implementation.
> * Also noticed that it was added as an implicit plugin to the {{SolrCore}}.
> which means one could access the handler like
> {{//admin/health}}, however, this will never work, since
> it uses a parameterless constructor, which leaves the handler in an invalid
> state [1]. I honestly don't know why it's being added to the {{SolrCore}},
> this is supposed to be a node level handler, and for SolrCore one could use
> the {{PingRequestHandler}}
>
> [1]
> {noformat}
> 2020-08-21 21:14:06.094 ERROR (qtp599782425-18) [c:test s:shard1 r:core_node4
> x:test_shard1_replica_n2] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException: CoreContainer is either not
> initialized or shutting down
> at
> org.apache.solr.handler.admin.HealthCheckHandler.handleRequestBody(HealthCheckHandler.java:96)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2606)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:812)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:588)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
>
[jira] [Commented] (SOLR-14774) HealthCheckHandler shouldn't be an implicit SolrCore level handler and should be configurable
[
https://issues.apache.org/jira/browse/SOLR-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17184740#comment-17184740
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14774:
--
Thanks Ishan, I think that would require a whole lot of other changes and
discussions to be had (none of the top level components as they are now are
dynamic, the standalone case, etc).
[~noble.paul], let me know if you still have concerns, otherwise I'll merge
tomorrow to master and 8.x
> HealthCheckHandler shouldn't be an implicit SolrCore level handler and should
> be configurable
> -
>
> Key: SOLR-14774
> URL: https://issues.apache.org/jira/browse/SOLR-14774
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> While trying to use the HealthCheckHandler I noticed that:
> * CoreContainer has some logic to read config from {{solr.xml}}, however,
> this is never used, and the handler is constructed explicitly inside
> {{InfoHandler}}. This means you can't plugin a different implementation.
> * Also noticed that it was added as an implicit plugin to the {{SolrCore}}.
> which means one could access the handler like
> {{//admin/health}}, however, this will never work, since
> it uses a parameterless constructor, which leaves the handler in an invalid
> state [1]. I honestly don't know why it's being added to the {{SolrCore}},
> this is supposed to be a node level handler, and for SolrCore one could use
> the {{PingRequestHandler}}
>
> [1]
> {noformat}
> 2020-08-21 21:14:06.094 ERROR (qtp599782425-18) [c:test s:shard1 r:core_node4
> x:test_shard1_replica_n2] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException: CoreContainer is either not
> initialized or shutting down
> at
> org.apache.solr.handler.admin.HealthCheckHandler.handleRequestBody(HealthCheckHandler.java:96)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2606)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:812)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:588)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
>
[jira] [Resolved] (SOLR-14751) Zookeeper Admin screen not working for old ZK versions
[
https://issues.apache.org/jira/browse/SOLR-14751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe resolved SOLR-14751.
--
Fix Version/s: 8.6.2
Resolution: Fixed
> Zookeeper Admin screen not working for old ZK versions
> --
>
> Key: SOLR-14751
> URL: https://issues.apache.org/jira/browse/SOLR-14751
> Project: Solr
> Issue Type: Bug
> Components: Admin UI
>Affects Versions: 8.6
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.7, 8.6.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I tried viewing the ZK admin screen for Zookeeper 3.4.9, but it fails with
> stack:
> {noformat}
> 2020-08-13 12:05:43.317 INFO (qtp489411441-25) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/zookeeper/status
> params={wt=json&_=1597320343286} status=500 QTime=2
> 2020-08-13 12:05:43.317 ERROR (qtp489411441-25) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException: Failed to get config from zookeeper
> at
> org.apache.solr.common.cloud.SolrZkClient.getConfig(SolrZkClient.java:777)
> at
> org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:83)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> at
[jira] [Comment Edited] (SOLR-14751) Zookeeper Admin screen not working for old ZK versions
[
https://issues.apache.org/jira/browse/SOLR-14751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17184685#comment-17184685
]
Tomas Eduardo Fernandez Lobbe edited comment on SOLR-14751 at 8/25/20, 7:02 PM:
This is a trivial bugfix, I'd like to backport this for 8.6.2
was (Author: tomasflobbe):
This is a trivial bugfix, I'd like to backport this for 8.6.1
> Zookeeper Admin screen not working for old ZK versions
> --
>
> Key: SOLR-14751
> URL: https://issues.apache.org/jira/browse/SOLR-14751
> Project: Solr
> Issue Type: Bug
> Components: Admin UI
>Affects Versions: 8.6
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I tried viewing the ZK admin screen for Zookeeper 3.4.9, but it fails with
> stack:
> {noformat}
> 2020-08-13 12:05:43.317 INFO (qtp489411441-25) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/zookeeper/status
> params={wt=json&_=1597320343286} status=500 QTime=2
> 2020-08-13 12:05:43.317 ERROR (qtp489411441-25) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException: Failed to get config from zookeeper
> at
> org.apache.solr.common.cloud.SolrZkClient.getConfig(SolrZkClient.java:777)
> at
> org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:83)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
>
[jira] [Reopened] (SOLR-14751) Zookeeper Admin screen not working for old ZK versions
[
https://issues.apache.org/jira/browse/SOLR-14751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe reopened SOLR-14751:
--
This is a trivial bugfix, I'd like to backport this for 8.6.1
> Zookeeper Admin screen not working for old ZK versions
> --
>
> Key: SOLR-14751
> URL: https://issues.apache.org/jira/browse/SOLR-14751
> Project: Solr
> Issue Type: Bug
> Components: Admin UI
>Affects Versions: 8.6
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I tried viewing the ZK admin screen for Zookeeper 3.4.9, but it fails with
> stack:
> {noformat}
> 2020-08-13 12:05:43.317 INFO (qtp489411441-25) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/zookeeper/status
> params={wt=json&_=1597320343286} status=500 QTime=2
> 2020-08-13 12:05:43.317 ERROR (qtp489411441-25) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException: Failed to get config from zookeeper
> at
> org.apache.solr.common.cloud.SolrZkClient.getConfig(SolrZkClient.java:777)
> at
> org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:83)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
>
[jira] [Commented] (SOLR-14688) First party package implementation design
[ https://issues.apache.org/jira/browse/SOLR-14688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17184662#comment-17184662 ] Tomas Eduardo Fernandez Lobbe commented on SOLR-14688: -- Thanks. I guess that means all first party packages will have to support back compatibility (at the code level) to all versions where we want to allow rolling upgrade from, right? > First party package implementation design > - > > Key: SOLR-14688 > URL: https://issues.apache.org/jira/browse/SOLR-14688 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Priority: Major > Labels: package, packagemanager > > Here's the design document for first party packages: > https://docs.google.com/document/d/1n7gB2JAdZhlJKFrCd4Txcw4HDkdk7hlULyAZBS-wXrE/edit?usp=sharing > Put differently, this is about package-ifying our "contribs". -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14688) First party package implementation design
[ https://issues.apache.org/jira/browse/SOLR-14688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17184635#comment-17184635 ] Tomas Eduardo Fernandez Lobbe commented on SOLR-14688: -- I'm just learning about the the package management, so this may be a dumb question, but what would be the process for a Solr rolling upgrade? > First party package implementation design > - > > Key: SOLR-14688 > URL: https://issues.apache.org/jira/browse/SOLR-14688 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Priority: Major > Labels: package, packagemanager > > Here's the design document for first party packages: > https://docs.google.com/document/d/1n7gB2JAdZhlJKFrCd4Txcw4HDkdk7hlULyAZBS-wXrE/edit?usp=sharing > Put differently, this is about package-ifying our "contribs". -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14774) HealthCheckHandler shouldn't be an implicit SolrCore level handler and should be configurable
[
https://issues.apache.org/jira/browse/SOLR-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17183441#comment-17183441
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14774:
--
This Jira addresses two bugs:
1) [The
documentation|https://lucene.apache.org/solr/guide/8_6/implicit-requesthandlers.html#admin-handlers]
claims that this can be accessed via {{solr//admin/health}}, however,
this isn't right. If you look at the code, you'll see that implicit plugins for
the SolrCore are either created with a constructor that receives the SolrCore
or with a parameterless constructor. HealthCheckHandler is supposed to be a top
level handler, so it doesn't have a constructor that receives a SolrCore, so
it'll be created (for the SolrCore) with a parameterless constructor. Now, if
you look at the first line in the {{handleRequestBody}} method, you'll see that
this will never work:
https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/admin/HealthCheckHandler.java#L95.
One alternative is to create a constructor that receives the SolrCore, and
then get the coreContainer from there, but it doesn't make sense, since every
core would be checking the exact same thing. Also, for a in-core healthcheck we
have the "ping" request handler now, which is core-specific and has a different
set of features.
2) This handler was created with the intention of being pluggable. If you see
the
[NodeConfig|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/core/NodeConfig.java#L199],
you'll see that it has a method to get the handler class from {{solr.xml}}.
And if you see
[CoreContainer|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/core/CoreContainer.java#L182],
you'll see that it has a {{healthCheckHandler}} field, that is never
initialized or used. Looks like somewhere in the commits for SOLR-11126 this
was done by mistake.
Let me know if you still have concernes
> HealthCheckHandler shouldn't be an implicit SolrCore level handler and should
> be configurable
> -
>
> Key: SOLR-14774
> URL: https://issues.apache.org/jira/browse/SOLR-14774
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> While trying to use the HealthCheckHandler I noticed that:
> * CoreContainer has some logic to read config from {{solr.xml}}, however,
> this is never used, and the handler is constructed explicitly inside
> {{InfoHandler}}. This means you can't plugin a different implementation.
> * Also noticed that it was added as an implicit plugin to the {{SolrCore}}.
> which means one could access the handler like
> {{//admin/health}}, however, this will never work, since
> it uses a parameterless constructor, which leaves the handler in an invalid
> state [1]. I honestly don't know why it's being added to the {{SolrCore}},
> this is supposed to be a node level handler, and for SolrCore one could use
> the {{PingRequestHandler}}
>
> [1]
> {noformat}
> 2020-08-21 21:14:06.094 ERROR (qtp599782425-18) [c:test s:shard1 r:core_node4
> x:test_shard1_replica_n2] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException: CoreContainer is either not
> initialized or shutting down
> at
> org.apache.solr.handler.admin.HealthCheckHandler.handleRequestBody(HealthCheckHandler.java:96)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2606)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:812)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:588)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
>
[jira] [Commented] (SOLR-14684) CloudExitableDirectoryReaderTest failing about 25% of the time
[ https://issues.apache.org/jira/browse/SOLR-14684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17182186#comment-17182186 ] Tomas Eduardo Fernandez Lobbe commented on SOLR-14684: -- Ah, I noticed Erick created SOLR-14771 for the failure > CloudExitableDirectoryReaderTest failing about 25% of the time > -- > > Key: SOLR-14684 > URL: https://issues.apache.org/jira/browse/SOLR-14684 > Project: Solr > Issue Type: Test > Components: Tests >Affects Versions: master (9.0) >Reporter: Erick Erickson >Priority: Major > Attachments: stdout > > Time Spent: 40m > Remaining Estimate: 0h > > If I beast this on my local machine, it fails (non reproducibly of course) > about 1/4 of the time. Log attached. The test itself hasn't changed in 11 > months or so. > It looks like occasionally the calls throw an error rather than return > partial results with a message: "Time allowed to handle this request > exceeded:[]". > It's been failing very intermittently for a couple of years, but the failure > rate really picked up in the last couple of weeks. IDK whether the failures > prior to the last couple of weeks are the same root cause. > I'll do some spelunking to see if I can pinpoint the commit that made this > happen, but it'll take a while. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14684) CloudExitableDirectoryReaderTest failing about 25% of the time
[
https://issues.apache.org/jira/browse/SOLR-14684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17182182#comment-17182182
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14684:
--
There are a bunch of failures in Jenkins like:
{noformat}
FAILED:
org.apache.solr.client.solrj.impl.LBSolrClientTest.testServerIteratorTimeAllowed
Error Message:
Expected exception SolrServerException but no exception was thrown
Stack Trace:
junit.framework.AssertionFailedError: Expected exception SolrServerException
but no exception was thrown
at
org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2750)
at
org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2740)
at
org.apache.solr.client.solrj.impl.LBSolrClientTest.testServerIteratorTimeAllowed(LBSolrClientTest.java:77)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:269)
at
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:394)
at
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:13)
{noformat}
Looks related to this commit, but I didn't validate
> CloudExitableDirectoryReaderTest failing about 25% of the time
> --
>
> Key: SOLR-14684
> URL: https://issues.apache.org/jira/browse/SOLR-14684
> Project: Solr
> Issue Type: Test
> Components: Tests
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Priority: Major
> Attachments: stdout
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> If I beast this on my local machine, it fails (non reproducibly of course)
> about 1/4 of the time. Log attached. The test itself hasn't changed in 11
> months or so.
> It looks like occasionally the calls throw an error rather than return
> partial results with a message: "Time allowed to handle this request
> exceeded:[]".
> It's been failing very intermittently for a couple of years, but the failure
> rate really picked up in the last couple of weeks. IDK whether the failures
> prior to the last couple of weeks are the same root cause.
> I'll do some spelunking to see if I can pinpoint the commit that made this
> happen, but it'll take a while.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
