[jira] [Commented] (SOLR-15191) Faceting on EnumFieldType does not work if allBuckets, numBuckets or missing is set
[ https://issues.apache.org/jira/browse/SOLR-15191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294307#comment-17294307 ] Thomas Wöckinger commented on SOLR-15191: - The return value for facets count is long at the master rather than int from branch 8.x. So changing: "//*[@name='facets']/int/text()=6", to "//*[@name='facets']/long/text()=6", should fix the test > Faceting on EnumFieldType does not work if allBuckets, numBuckets or missing > is set > --- > > Key: SOLR-15191 > URL: https://issues.apache.org/jira/browse/SOLR-15191 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module, FacetComponent, faceting, search, > streaming expressions >Affects Versions: 8.7, 8.8, 8.8.1 >Reporter: Thomas Wöckinger >Assignee: David Smiley >Priority: Major > Labels: easy-fix, pull-request-available > Fix For: 8.9 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Due to Solr-14514 FacetFieldProcessorByEnumTermsStream is not used if > allBuckets, numBuckets or missing parma is true. > As fallback FacetFieldProcessorByHashDV is used which > FacetRangeProcessor.getNumericCalc(sf) on the field. EnumFileType is not > handled currently, so a SolrException is thrown with BAD_REQUEST and > 'Expected numeric field type' -- 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
[GitHub] [lucene-solr] zacharymorn commented on pull request #2342: LUCENE-9406: Add IndexWriterEventListener to track events in IndexWriter
zacharymorn commented on pull request #2342: URL: https://github.com/apache/lucene-solr/pull/2342#issuecomment-789403559 No worry! Thanks for the review and merge! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on pull request #2438: SOLR-14928: add exponential backoff for distributed cluster state updates
dsmiley commented on pull request #2438: URL: https://github.com/apache/lucene-solr/pull/2438#issuecomment-789368257 It occurred to me why this raised a red flag to me -- it's because it's a PR. If you truly felt the change in question was so minor then simply commit directly to master. I certainly do this on occasion for typos, javadocs, or maybe a fix to a failing test. But the creation of the PR suggests you have an interest in a code review? Then please wait more than 7 hours for one if you want one :-) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - 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&focusedCommentId=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&page=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] [Comment Edited] (SOLR-15210) ParallelStream should execute hashing & filtering directly in ExportWriter
[
https://issues.apache.org/jira/browse/SOLR-15210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294202#comment-17294202
]
Joel Bernstein edited comment on SOLR-15210 at 3/3/21, 1:29 AM:
Let's have the best of both worlds. We can lazily build up a bitset of
documents to ignore for each worker. We can then apply this bitset before the
sorting stage.
Here is the basic idea:
1) In the writer thread hash each key and decide if the worker should send the
doc out.
2) When the writer finds a key that shouldn't be sent out, add the docId to an
ignore bitset for the specific worker.
3) After each run combine the ignore bitsets with a cached set of ignore
bitsets per worker.
4) Before performing the sort, turn off all bits for each worker that
intersects the workers ignore bitset.
Basically this lazily builds a set of documents per worker that should NOT be
sent out. This cache will warm over time making the exports faster over time.
was (Author: joel.bernstein):
Let's have the best of both worlds. We can lazily build up a bitset of
documents to ignore for each worker. We can then apply this bitset before the
sorting stage.
Here is the basic idea:
1) In the writer thread hash each key and decide if the worker should send the
doc out.
2) When the writer finds a key that shouldn't be sent out, add the docId to an
ignore bitset for the specific worker.
3) After each run combine the ignore bitsets with a cached set of ignore
bitsets per worker.
4) Before performing the sort, turn off all bits for each worker that
intersects the ignore bitset.
Basically this lazily builds a set of documents per worker that should NOT be
sent out. This cache will warm over time making the exports faster over time.
> ParallelStream should execute hashing & filtering directly in ExportWriter
> --
>
> Key: SOLR-15210
> URL: https://issues.apache.org/jira/browse/SOLR-15210
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
>
> Currently ParallelStream uses {{HashQParserPlugin}} to partition the work
> based on a hashed value of {{partitionKeys}}. Unfortunately, this filter has
> a high initial runtime cost because it has to materialize all values of
> {{partitionKeys}} on each worker in order to calculate their hash and decide
> whether a particular doc belongs to the worker's partition.
> The alternative approach would be for the worker to collect and sort all
> documents and only then filter out the ones that belong to the current
> partition just before they are written out by {{ExportWriter}} - at this
> point we have to materialize the fields anyway but also we can benefit from a
> (minimal) BytesRef caching that the FieldWriters use. On the other hand we
> pay the price of sorting all documents, and we also lose the query filter
> caching that the {{HashQParserPlugin}} uses.
> This tradeoff is not obvious but should be investigated to see if it offers
> better performance.
--
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
[GitHub] [lucene-solr-operator] madrob commented on pull request #226: Add terminationGracePeriod option, and use it when killing Solr.
madrob commented on pull request #226: URL: https://github.com/apache/lucene-solr-operator/pull/226#issuecomment-789355147 Please add a `since 0.3.0` somewhere in the docs for this. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-15210) ParallelStream should execute hashing & filtering directly in ExportWriter
[
https://issues.apache.org/jira/browse/SOLR-15210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294202#comment-17294202
]
Joel Bernstein edited comment on SOLR-15210 at 3/3/21, 1:28 AM:
Let's have the best of both worlds. We can lazily build up a bitset of
documents to ignore for each worker. We can then apply this bitset before the
sorting stage.
Here is the basic idea:
1) In the writer thread hash each key and decide if the worker should send the
doc out.
2) When the writer finds a key that shouldn't be sent out, add the docId to an
ignore bitset for the specific worker.
3) After each run combine the ignore bitsets with a cached set of ignore
bitsets per worker.
4) Before performing the sort, turn off all bits for each worker that
intersects the ignore bitset.
Basically this lazily builds a set of documents per worker that should NOT be
sent out. This cache will warm over time making the exports faster over time.
was (Author: joel.bernstein):
Let's have the best of both worlds. We can lazily build up a bitset of
documents to ignore for each worker. We can then apply this bitset before the
sorting stage.
Here is the basic idea:
1) In the writer thread hash each key and decide if the worker should send it
out.
2) When a worker thread finds a key that shouldn't be sent out add the docId to
an ignore bitset for the specific worker.
3) After each run combine the ignore bitsets with a cached set of ignore
bitsets per worker.
4) Before performing the sort, turn off all bits for each worker that
intersects the ignore bitset.
Basically this lazily builds a set of documents per worker that should NOT be
sent out. This cache will warm over time making the exports faster over time.
> ParallelStream should execute hashing & filtering directly in ExportWriter
> --
>
> Key: SOLR-15210
> URL: https://issues.apache.org/jira/browse/SOLR-15210
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
>
> Currently ParallelStream uses {{HashQParserPlugin}} to partition the work
> based on a hashed value of {{partitionKeys}}. Unfortunately, this filter has
> a high initial runtime cost because it has to materialize all values of
> {{partitionKeys}} on each worker in order to calculate their hash and decide
> whether a particular doc belongs to the worker's partition.
> The alternative approach would be for the worker to collect and sort all
> documents and only then filter out the ones that belong to the current
> partition just before they are written out by {{ExportWriter}} - at this
> point we have to materialize the fields anyway but also we can benefit from a
> (minimal) BytesRef caching that the FieldWriters use. On the other hand we
> pay the price of sorting all documents, and we also lose the query filter
> caching that the {{HashQParserPlugin}} uses.
> This tradeoff is not obvious but should be investigated to see if it offers
> better performance.
--
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&focusedCommentId=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] [Comment Edited] (SOLR-15210) ParallelStream should execute hashing & filtering directly in ExportWriter
[
https://issues.apache.org/jira/browse/SOLR-15210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294202#comment-17294202
]
Joel Bernstein edited comment on SOLR-15210 at 3/3/21, 1:23 AM:
Let's have the best of both worlds. We can lazily build up a bitset of
documents to ignore for each worker. We can then apply this bitset before the
sorting stage.
Here is the basic idea:
1) In the writer thread hash each key and decide if the worker should send it
out.
2) When a worker thread finds a key that shouldn't be sent out add the docId to
an ignore bitset for the specific worker.
3) After each run combine the ignore bitsets with a cached set of ignore
bitsets per worker.
4) Before performing the sort, turn off all bits for each worker that
intersects the ignore bitset.
Basically this lazily builds a set of documents per worker that should NOT be
sent out. This cache will warm over time making the exports faster over time.
was (Author: joel.bernstein):
Let's have the best of both worlds. We can lazily build up a bitset of
documents to ignore for each worker. We can then apply this bitset before the
sorting stage.
Here is the basic idea:
1) In the writer thread hash each key and decide if the worker should send it
out.
2) When a worker thread finds a key that shouldn't be sent out add the docId to
an ignore bitset for the specific worker.
3) After each run combine the ignore bitsets with a cached set of ignore
bitsets per worker.
4) Before performing the sort, turn off all bits for each worker that
intersects the ignore bitset.
Basically this lazily builds a set of documents per worker that should NOT be
sent out. This cache will warm over time making the exports faster over time.
> ParallelStream should execute hashing & filtering directly in ExportWriter
> --
>
> Key: SOLR-15210
> URL: https://issues.apache.org/jira/browse/SOLR-15210
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
>
> Currently ParallelStream uses {{HashQParserPlugin}} to partition the work
> based on a hashed value of {{partitionKeys}}. Unfortunately, this filter has
> a high initial runtime cost because it has to materialize all values of
> {{partitionKeys}} on each worker in order to calculate their hash and decide
> whether a particular doc belongs to the worker's partition.
> The alternative approach would be for the worker to collect and sort all
> documents and only then filter out the ones that belong to the current
> partition just before they are written out by {{ExportWriter}} - at this
> point we have to materialize the fields anyway but also we can benefit from a
> (minimal) BytesRef caching that the FieldWriters use. On the other hand we
> pay the price of sorting all documents, and we also lose the query filter
> caching that the {{HashQParserPlugin}} uses.
> This tradeoff is not obvious but should be investigated to see if it offers
> better performance.
--
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
[GitHub] [lucene-solr-operator] madrob opened a new pull request #232: Add note about versions supporting log4j.xml
madrob opened a new pull request #232: URL: https://github.com/apache/lucene-solr-operator/pull/232 Would be good to add this to more of the features, but I don't know have enough context to label everything correctly. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] tflobbe opened a new pull request #2445: SOLR-15154: Let Http2SolrClient pass Basic Auth credentials to all requests
tflobbe opened a new pull request #2445: URL: https://github.com/apache/lucene-solr/pull/2445 Credentials can now be set explicitly at the client level, or can be read from System properties like in the previous version of the client when using `PreemptiveBasicAuthClientBuilderFactory`. Other implementations of `HttpClientBuilderFactory` can now also be used. This test also adds a small refactor to `PreemptiveBasicAuthClientBuilderFactory` for better testing. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15210) ParallelStream should execute hashing & filtering directly in ExportWriter
[
https://issues.apache.org/jira/browse/SOLR-15210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294202#comment-17294202
]
Joel Bernstein commented on SOLR-15210:
---
Let's have have the best of both worlds. We can lazily build up a bitset of
documents to ignore for each worker. We can then apply this bitset before the
sorting stage.
Here is the basic idea:
1) In the writer thread hash each key and decide if the worker should send it
out.
2) When a worker thread finds a key that shouldn't be sent out add the docId to
an ignore bitset for the specific worker.
3) After each run combine the ignore bitsets with a cached set of ignore
bitsets per worker.
4) Before performing the sort, turn off all bits for each worker that
intersects the ignore bitset.
Basically this lazily builds a set of documents per worker that should NOT be
sent out. This cache will warm over time making the exports faster over time.
> ParallelStream should execute hashing & filtering directly in ExportWriter
> --
>
> Key: SOLR-15210
> URL: https://issues.apache.org/jira/browse/SOLR-15210
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
>
> Currently ParallelStream uses {{HashQParserPlugin}} to partition the work
> based on a hashed value of {{partitionKeys}}. Unfortunately, this filter has
> a high initial runtime cost because it has to materialize all values of
> {{partitionKeys}} on each worker in order to calculate their hash and decide
> whether a particular doc belongs to the worker's partition.
> The alternative approach would be for the worker to collect and sort all
> documents and only then filter out the ones that belong to the current
> partition just before they are written out by {{ExportWriter}} - at this
> point we have to materialize the fields anyway but also we can benefit from a
> (minimal) BytesRef caching that the FieldWriters use. On the other hand we
> pay the price of sorting all documents, and we also lose the query filter
> caching that the {{HashQParserPlugin}} uses.
> This tradeoff is not obvious but should be investigated to see if it offers
> better performance.
--
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-15210) ParallelStream should execute hashing & filtering directly in ExportWriter
[
https://issues.apache.org/jira/browse/SOLR-15210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294202#comment-17294202
]
Joel Bernstein edited comment on SOLR-15210 at 3/3/21, 1:19 AM:
Let's have the best of both worlds. We can lazily build up a bitset of
documents to ignore for each worker. We can then apply this bitset before the
sorting stage.
Here is the basic idea:
1) In the writer thread hash each key and decide if the worker should send it
out.
2) When a worker thread finds a key that shouldn't be sent out add the docId to
an ignore bitset for the specific worker.
3) After each run combine the ignore bitsets with a cached set of ignore
bitsets per worker.
4) Before performing the sort, turn off all bits for each worker that
intersects the ignore bitset.
Basically this lazily builds a set of documents per worker that should NOT be
sent out. This cache will warm over time making the exports faster over time.
was (Author: joel.bernstein):
Let's have have the best of both worlds. We can lazily build up a bitset of
documents to ignore for each worker. We can then apply this bitset before the
sorting stage.
Here is the basic idea:
1) In the writer thread hash each key and decide if the worker should send it
out.
2) When a worker thread finds a key that shouldn't be sent out add the docId to
an ignore bitset for the specific worker.
3) After each run combine the ignore bitsets with a cached set of ignore
bitsets per worker.
4) Before performing the sort, turn off all bits for each worker that
intersects the ignore bitset.
Basically this lazily builds a set of documents per worker that should NOT be
sent out. This cache will warm over time making the exports faster over time.
> ParallelStream should execute hashing & filtering directly in ExportWriter
> --
>
> Key: SOLR-15210
> URL: https://issues.apache.org/jira/browse/SOLR-15210
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
>
> Currently ParallelStream uses {{HashQParserPlugin}} to partition the work
> based on a hashed value of {{partitionKeys}}. Unfortunately, this filter has
> a high initial runtime cost because it has to materialize all values of
> {{partitionKeys}} on each worker in order to calculate their hash and decide
> whether a particular doc belongs to the worker's partition.
> The alternative approach would be for the worker to collect and sort all
> documents and only then filter out the ones that belong to the current
> partition just before they are written out by {{ExportWriter}} - at this
> point we have to materialize the fields anyway but also we can benefit from a
> (minimal) BytesRef caching that the FieldWriters use. On the other hand we
> pay the price of sorting all documents, and we also lose the query filter
> caching that the {{HashQParserPlugin}} uses.
> This tradeoff is not obvious but should be investigated to see if it offers
> better performance.
--
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-15190) Create a release repo for Solr
[ https://issues.apache.org/jira/browse/SOLR-15190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294015#comment-17294015 ] Anshum Gupta commented on SOLR-15190: - Yes, looks like we'll need some bootstrapping as part of the first operator release. Shouldn't require someone but we certainly need to document what's needed. > Create a release repo for Solr > -- > > Key: SOLR-15190 > URL: https://issues.apache.org/jira/browse/SOLR-15190 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Priority: Major > > I think this will be created as we do the first release, i.e. nothing > explicit to do here until then? -- 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-15167) Move lucene-solr-operator repo
[ https://issues.apache.org/jira/browse/SOLR-15167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294014#comment-17294014 ] Jan Høydahl commented on SOLR-15167: Thanks. I created a separate Jira SOLR-15211 for fixing the subproject things, and assigned you. > Move lucene-solr-operator repo > -- > > Key: SOLR-15167 > URL: https://issues.apache.org/jira/browse/SOLR-15167 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Houston Putman >Priority: Major > > The lucene-solr-operator repo will be (once again) moved, now to > "solr-operator". This must be ordered thorugh an INFRA ticker. > As this will once again break the URL for helm, that also needs an update in > relevant places. -- 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-15211) Set up solr-operator as a sub project
Jan Høydahl created SOLR-15211: -- Summary: Set up solr-operator as a sub project Key: SOLR-15211 URL: https://issues.apache.org/jira/browse/SOLR-15211 Project: Solr Issue Type: Sub-task Reporter: Jan Høydahl Assignee: Houston Putman * Create DOAP file for it * Find a way to highlight the sub project on Solr webpage (with a link to GitHub) -- 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-15190) Create a release repo for Solr
[ https://issues.apache.org/jira/browse/SOLR-15190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294010#comment-17294010 ] Jan Høydahl commented on SOLR-15190: I believe this is controlled by Subversion, so when you push the release files (e.g. .tgz, .asc and .sha512 files) to subversion [https://dist.apache.org/repos/dist/release/solr] then that location will be created. Guess we'll need to write up the release procedure for Operator first... Check out [https://github.com/apache/lucene-solr/blob/master/dev-tools/scripts/releaseWizard.yaml#L748:L765] for importing a local release RC folder into the staging SVN. And after the VOTE succeeds, you move the artifacts from /dist/dev/ to /dist/release/ tree: [https://github.com/apache/lucene-solr/blob/master/dev-tools/scripts/releaseWizard.yaml#L952:L975] > Create a release repo for Solr > -- > > Key: SOLR-15190 > URL: https://issues.apache.org/jira/browse/SOLR-15190 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Priority: Major > > I think this will be created as we do the first release, i.e. nothing > explicit to do here until then? -- 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-14499) New Solr TLP site
[ https://issues.apache.org/jira/browse/SOLR-14499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294006#comment-17294006 ] Jan Høydahl commented on SOLR-14499: I updated the Code of Conduct section and added Email etiquette section. Javadoc and Refguide htaccess rules shuould now be ok, as well as redirects from Lucene. I plan on publishing both web sites tomorrow Wednesday. > New Solr TLP site > - > > Key: SOLR-14499 > URL: https://issues.apache.org/jira/browse/SOLR-14499 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Attachments: Paletton-color-palette.html, code-hilite-after.png, > code-hilite-before.png, only-yellow.png, solr-has-moved-modal.png, > solr-new-site-screenshot.png, solr-security-and-news.png, > solr-site-green.png, solr-site-green.png, solr-site-yellow.png, > solr-site-yellow.png, stacked.png > > > # Get setup solr-site repo (start from lucene-site repo) > # Setup a temporary "work in progress" page on solr.apache.org > # Remove all lucene TLP, lucene-core and pylucene content, including > templates and css etc > # Move Solr index.html as main index file > # Simplify folder structure for Pelican > # Publish the new site -- 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
[GitHub] [lucene-site] janhoy commented on pull request #48: SOLR-15171 Add redirects from old Solr site to new
janhoy commented on pull request #48: URL: https://github.com/apache/lucene-site/pull/48#issuecomment-789237544 > Alternatively we should add a redirect on Solr's side. This is indeed a special case, because there's nothing on Solr's side that handles this. I just committed what I believe was needed, before your comment here: https://github.com/apache/lucene-site/commit/35fedb17f244b44e6197defc2e92c4fe2e9c9b4b This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-site] uschindler commented on pull request #48: SOLR-15171 Add redirects from old Solr site to new
uschindler commented on pull request #48: URL: https://github.com/apache/lucene-site/pull/48#issuecomment-789233604 Refguide is fine, as this does not need the version number patterns. Also the "/api" ones are fine. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-site] uschindler commented on pull request #48: SOLR-15171 Add redirects from old Solr site to new
uschindler commented on pull request #48: URL: https://github.com/apache/lucene-site/pull/48#issuecomment-789232174 Hi, I think we still need one redirect on the old page using match: `RedirectMatch permanent ^/solr/(\d+_\d+_\d+\b.*)$ https://solr.apache.org/docs/$1` Alternatively we should add a redirect on Solr's side. This is indeed a special case, because there's nothing on Solr's side that handles this. This redirect should be placed before the generic one. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15171) Add redirects from old Solr site to new
[
https://issues.apache.org/jira/browse/SOLR-15171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293989#comment-17293989
]
Jan Høydahl commented on SOLR-15171:
Merged the PR. Meaning it can be tested on
[https://lucene-new.staged.apache.org/] e.g.
[https://lucene-new.staged.apache.org/solr/guide]
> Add redirects from old Solr site to new
> ---
>
> Key: SOLR-15171
> URL: https://issues.apache.org/jira/browse/SOLR-15171
> Project: Solr
> Issue Type: Sub-task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> The lucene.apache.org website needs to have updated {{.htaccess}} rules to
> redirect any and all {{lucene.apache.org/solr/\*}} paths to
> {{solr.apache.org/\*}}.
> Also the ATOM/RSS feed URLs should be redirected, so those that monitor
> security news and releases will not have an interruption.
--
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-15171) Add redirects from old Solr site to new
[
https://issues.apache.org/jira/browse/SOLR-15171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl resolved SOLR-15171.
Resolution: Fixed
> Add redirects from old Solr site to new
> ---
>
> Key: SOLR-15171
> URL: https://issues.apache.org/jira/browse/SOLR-15171
> Project: Solr
> Issue Type: Sub-task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> The lucene.apache.org website needs to have updated {{.htaccess}} rules to
> redirect any and all {{lucene.apache.org/solr/\*}} paths to
> {{solr.apache.org/\*}}.
> Also the ATOM/RSS feed URLs should be redirected, so those that monitor
> security news and releases will not have an interruption.
--
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
[GitHub] [lucene-site] janhoy merged pull request #48: SOLR-15171 Add redirects from old Solr site to new
janhoy merged pull request #48: URL: https://github.com/apache/lucene-site/pull/48 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-site] uschindler commented on a change in pull request #48: SOLR-15171 Add redirects from old Solr site to new
uschindler commented on a change in pull request #48: URL: https://github.com/apache/lucene-site/pull/48#discussion_r585914200 ## File path: themes/lucene/templates/htaccess.template ## @@ -126,19 +91,15 @@ RedirectMatch Permanent ^/nutch/(.*)$ https://nutch.apache.org/$1 # Lucy has moved, site strcuture has changed, do don't use $1 in redirect... RedirectMatch Permanent ^/lucy/(.*)$ https://lucy.apache.org/ -# promote Solr to TLP -# TODO: This links to the staging site for new Solr - change the redirect to TLP page -#RedirectMatch Permanent ^/solr/(.*)$ https://solr.apache.org/$1 -RedirectMatch Permanent ^/solr/(.*)$ https://lucene-solrtlp.staged.apache.org/$1 - +# Solr moved to TLP Feb 2021 Review comment: Did not know about that feeds URL. +1 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-site] uschindler commented on a change in pull request #48: SOLR-15171 Add redirects from old Solr site to new
uschindler commented on a change in pull request #48: URL: https://github.com/apache/lucene-site/pull/48#discussion_r585913649 ## File path: themes/lucene/templates/htaccess.template ## @@ -126,19 +91,15 @@ RedirectMatch Permanent ^/nutch/(.*)$ https://nutch.apache.org/$1 # Lucy has moved, site strcuture has changed, do don't use $1 in redirect... RedirectMatch Permanent ^/lucy/(.*)$ https://lucy.apache.org/ -# promote Solr to TLP -# TODO: This links to the staging site for new Solr - change the redirect to TLP page -#RedirectMatch Permanent ^/solr/(.*)$ https://solr.apache.org/$1 -RedirectMatch Permanent ^/solr/(.*)$ https://lucene-solrtlp.staged.apache.org/$1 - +# Solr moved to TLP Feb 2021 Review comment: This also simplifies the maintenance. Lucene webserver maintainer should not need to maintain those rules. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-site] janhoy commented on a change in pull request #48: SOLR-15171 Add redirects from old Solr site to new
janhoy commented on a change in pull request #48: URL: https://github.com/apache/lucene-site/pull/48#discussion_r585911004 ## File path: themes/lucene/templates/htaccess.template ## @@ -126,19 +91,15 @@ RedirectMatch Permanent ^/nutch/(.*)$ https://nutch.apache.org/$1 # Lucy has moved, site strcuture has changed, do don't use $1 in redirect... RedirectMatch Permanent ^/lucy/(.*)$ https://lucy.apache.org/ -# promote Solr to TLP -# TODO: This links to the staging site for new Solr - change the redirect to TLP page -#RedirectMatch Permanent ^/solr/(.*)$ https://solr.apache.org/$1 -RedirectMatch Permanent ^/solr/(.*)$ https://lucene-solrtlp.staged.apache.org/$1 - +# Solr moved to TLP Feb 2021 Review comment: Simplified as two rules - needs separate rule for the ATOM feed This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr-operator] chaicesan opened a new pull request #231: Add conditional dependency for zk-operator helm chart
chaicesan opened a new pull request #231: URL: https://github.com/apache/lucene-solr-operator/pull/231 This PR is the first of two phases that will allow us to make use of up-to-date versions of the zk-operator as well as being able to install it using a conditional helm chart dependency. The aim of this PR is just to add the ability to install the latest version of the zk-operator via a helm chard dependency. Later work will involve making use of the new latest zk crd. There were some pain points when it came to updating the dependencies, mainly due to compatibility involving `k8s.io/client-go`. I'm still pretty new to go and go modules so let me know if I am doing anything suspect. This is my first PR to this project so please let me know if I have missed anything. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-site] uschindler commented on a change in pull request #48: SOLR-15171 Add redirects from old Solr site to new
uschindler commented on a change in pull request #48: URL: https://github.com/apache/lucene-site/pull/48#discussion_r585906424 ## File path: themes/lucene/templates/htaccess.template ## @@ -126,19 +91,24 @@ RedirectMatch Permanent ^/nutch/(.*)$ https://nutch.apache.org/$1 # Lucy has moved, site strcuture has changed, do don't use $1 in redirect... RedirectMatch Permanent ^/lucy/(.*)$ https://lucy.apache.org/ -# promote Solr to TLP -# TODO: This links to the staging site for new Solr - change the redirect to TLP page -#RedirectMatch Permanent ^/solr/(.*)$ https://solr.apache.org/$1 -RedirectMatch Permanent ^/solr/(.*)$ https://lucene-solrtlp.staged.apache.org/$1 +# Solr moved to TLP Feb 2021 +# Redirect old location of Solr release doc and javadoc to new, changed location in solr.apache.org/docs +RedirectMatch temp ^/solr/api$ https://solr.apache.org/api/ +RedirectMatch Permanent ^/solr/(\d+_\d+_\d+)$ https://solr.apache.org/docs/$1 +# These will be further rewritten to SOLR_LATEST_RELEASE on the solr side +RedirectMatch temp ^/solr/api/org/(.*) https://solr.apache.org/api/org/$1 +RedirectMatch temp ^/solr/api/(.*) https://solr.apache.org/api/$1 +RedirectMatch Permanent ^/solr/4_0_0-(ALPHA|BETA)(.*) https://solr.apache.org/docs/4_0_0/$2 +RedirectMatch Permanent ^/solr/api-(.*) https://solr.apache.org/docs/$1 +# Fallback redirect for anythin not caught above +RedirectMatch Permanent ^/solr/(.*)$ https://solr.apache.org/$1 Review comment: This is all much too complicated! Why do we need the specializations at all? In addition they still contain duplicates (caused by the "__root"-aapend-slash-handling added on the solr side, which is all noops here). We only need exactly one redirect; it should just replace prefix - `RedirectMatch` is not needed at all (please note the missing traiöling slashes no slashes at end to also match people not using the final slash on directory): ``` Redirect permanent /solr https://solr.apache.org ``` Everything else is handled by Solr's side. Browsers are perfectly happy with 2 or three redircets. Also the main purpose here is to tell lucene.apache.org/solr visitors that the main "permanent" target is solr.apache.org. Later redirects should be done from there, as it's on Solr's responsibility. We we also need no wildcard redirect (regex not needed). The above plain standard prefix redirect is enough. Also order of "standard prefix" redirects is important. Longest prefixes should be listed first. https://httpd.apache.org/docs/2.4/mod/mod_alias.html#redirect: "Then any request beginning with URL-path will return a redirect request to the client at the location of the target URL. Additional path information beyond the matched URL-path will be appended to the target URL." You can test all this on the Lucene staging site. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-site] janhoy commented on a change in pull request #48: SOLR-15171 Add redirects from old Solr site to new
janhoy commented on a change in pull request #48: URL: https://github.com/apache/lucene-site/pull/48#discussion_r585908560 ## File path: themes/lucene/templates/htaccess.template ## @@ -126,19 +91,24 @@ RedirectMatch Permanent ^/nutch/(.*)$ https://nutch.apache.org/$1 # Lucy has moved, site strcuture has changed, do don't use $1 in redirect... RedirectMatch Permanent ^/lucy/(.*)$ https://lucy.apache.org/ -# promote Solr to TLP -# TODO: This links to the staging site for new Solr - change the redirect to TLP page -#RedirectMatch Permanent ^/solr/(.*)$ https://solr.apache.org/$1 -RedirectMatch Permanent ^/solr/(.*)$ https://lucene-solrtlp.staged.apache.org/$1 +# Solr moved to TLP Feb 2021 +# Redirect old location of Solr release doc and javadoc to new, changed location in solr.apache.org/docs +RedirectMatch temp ^/solr/api$ https://solr.apache.org/api/ +RedirectMatch Permanent ^/solr/(\d+_\d+_\d+)$ https://solr.apache.org/docs/$1 +# These will be further rewritten to SOLR_LATEST_RELEASE on the solr side +RedirectMatch temp ^/solr/api/org/(.*) https://solr.apache.org/api/org/$1 +RedirectMatch temp ^/solr/api/(.*) https://solr.apache.org/api/$1 +RedirectMatch Permanent ^/solr/4_0_0-(ALPHA|BETA)(.*) https://solr.apache.org/docs/4_0_0/$2 +RedirectMatch Permanent ^/solr/api-(.*) https://solr.apache.org/docs/$1 +# Fallback redirect for anythin not caught above +RedirectMatch Permanent ^/solr/(.*)$ https://solr.apache.org/$1 Review comment: Ok, nice to know. Will make another attempt... This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-site] uschindler commented on a change in pull request #48: SOLR-15171 Add redirects from old Solr site to new
uschindler commented on a change in pull request #48: URL: https://github.com/apache/lucene-site/pull/48#discussion_r585906424 ## File path: themes/lucene/templates/htaccess.template ## @@ -126,19 +91,24 @@ RedirectMatch Permanent ^/nutch/(.*)$ https://nutch.apache.org/$1 # Lucy has moved, site strcuture has changed, do don't use $1 in redirect... RedirectMatch Permanent ^/lucy/(.*)$ https://lucy.apache.org/ -# promote Solr to TLP -# TODO: This links to the staging site for new Solr - change the redirect to TLP page -#RedirectMatch Permanent ^/solr/(.*)$ https://solr.apache.org/$1 -RedirectMatch Permanent ^/solr/(.*)$ https://lucene-solrtlp.staged.apache.org/$1 +# Solr moved to TLP Feb 2021 +# Redirect old location of Solr release doc and javadoc to new, changed location in solr.apache.org/docs +RedirectMatch temp ^/solr/api$ https://solr.apache.org/api/ +RedirectMatch Permanent ^/solr/(\d+_\d+_\d+)$ https://solr.apache.org/docs/$1 +# These will be further rewritten to SOLR_LATEST_RELEASE on the solr side +RedirectMatch temp ^/solr/api/org/(.*) https://solr.apache.org/api/org/$1 +RedirectMatch temp ^/solr/api/(.*) https://solr.apache.org/api/$1 +RedirectMatch Permanent ^/solr/4_0_0-(ALPHA|BETA)(.*) https://solr.apache.org/docs/4_0_0/$2 +RedirectMatch Permanent ^/solr/api-(.*) https://solr.apache.org/docs/$1 +# Fallback redirect for anythin not caught above +RedirectMatch Permanent ^/solr/(.*)$ https://solr.apache.org/$1 Review comment: This is all much too complicated! Why do we need the specializations at all? In addition they still contain duplicates (caused by the "__root"-aapend-slash-handling added on the solr side, which is all noops here). We only need exactly one redirect; it should just replace prefix - `RedirectMatch` is not needed at all (please note the missing traiöling slashes no slashes at end to also match people not using the final slash on directory): ``` Redirect permanent /solr https://solr.apache.org ``` Everything else is handled by Solr's side. Browsers are perfectly happy with 2 or three redircets. Also the main purpose here is to tell lucene.apache.org/solr visitors that the main "permanent" target is solr.apache.org. Later redirects should be done from there, as it's on Solr's responsibility. We we also need no wildcard redirect (regex not needed). The above plain standard prefix redirect is enough. Also order of "standard prefix" redirects in apache is by length. Longest prefixes first. https://httpd.apache.org/docs/2.4/mod/mod_alias.html#redirect: "Then any request beginning with URL-path will return a redirect request to the client at the location of the target URL. Additional path information beyond the matched URL-path will be appended to the target URL." You can test all this on the Lucene staging site. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-site] uschindler commented on a change in pull request #48: SOLR-15171 Add redirects from old Solr site to new
uschindler commented on a change in pull request #48: URL: https://github.com/apache/lucene-site/pull/48#discussion_r585906424 ## File path: themes/lucene/templates/htaccess.template ## @@ -126,19 +91,24 @@ RedirectMatch Permanent ^/nutch/(.*)$ https://nutch.apache.org/$1 # Lucy has moved, site strcuture has changed, do don't use $1 in redirect... RedirectMatch Permanent ^/lucy/(.*)$ https://lucy.apache.org/ -# promote Solr to TLP -# TODO: This links to the staging site for new Solr - change the redirect to TLP page -#RedirectMatch Permanent ^/solr/(.*)$ https://solr.apache.org/$1 -RedirectMatch Permanent ^/solr/(.*)$ https://lucene-solrtlp.staged.apache.org/$1 +# Solr moved to TLP Feb 2021 +# Redirect old location of Solr release doc and javadoc to new, changed location in solr.apache.org/docs +RedirectMatch temp ^/solr/api$ https://solr.apache.org/api/ +RedirectMatch Permanent ^/solr/(\d+_\d+_\d+)$ https://solr.apache.org/docs/$1 +# These will be further rewritten to SOLR_LATEST_RELEASE on the solr side +RedirectMatch temp ^/solr/api/org/(.*) https://solr.apache.org/api/org/$1 +RedirectMatch temp ^/solr/api/(.*) https://solr.apache.org/api/$1 +RedirectMatch Permanent ^/solr/4_0_0-(ALPHA|BETA)(.*) https://solr.apache.org/docs/4_0_0/$2 +RedirectMatch Permanent ^/solr/api-(.*) https://solr.apache.org/docs/$1 +# Fallback redirect for anythin not caught above +RedirectMatch Permanent ^/solr/(.*)$ https://solr.apache.org/$1 Review comment: This is all much too complicated! Why do we need the specializations at all? In addition they still contain duplicates (caused by the "__root"-aapend-slash-handling added on the solr side, which is all noops here). We only need exactly one redirect; it should just replace prefix - `RedirectMatch` is not needed at all: ``` Redirect permanent /solr https://solr.apache.org ``` Everything else is handled by Solr's side. Browsers are perfectly happy with 2 or three redircets. Also the main purpose here is to tell lucene.apache.org/solr visitors that the main "permanent" target is solr.apache.org. Later redirects should be done from there, as it's on Solr's responsibility. We we also need no wildcard redirect (regex not needed). The above plain standard prefix redirect is enough. Also order of "standard prefix" redirects in apache is by length. Longest prefixes first. https://httpd.apache.org/docs/2.4/mod/mod_alias.html#redirect: "Then any request beginning with URL-path will return a redirect request to the client at the location of the target URL. Additional path information beyond the matched URL-path will be appended to the target URL." You can test all this on the Lucene staging site. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-site] uschindler commented on a change in pull request #48: SOLR-15171 Add redirects from old Solr site to new
uschindler commented on a change in pull request #48: URL: https://github.com/apache/lucene-site/pull/48#discussion_r585906424 ## File path: themes/lucene/templates/htaccess.template ## @@ -126,19 +91,24 @@ RedirectMatch Permanent ^/nutch/(.*)$ https://nutch.apache.org/$1 # Lucy has moved, site strcuture has changed, do don't use $1 in redirect... RedirectMatch Permanent ^/lucy/(.*)$ https://lucy.apache.org/ -# promote Solr to TLP -# TODO: This links to the staging site for new Solr - change the redirect to TLP page -#RedirectMatch Permanent ^/solr/(.*)$ https://solr.apache.org/$1 -RedirectMatch Permanent ^/solr/(.*)$ https://lucene-solrtlp.staged.apache.org/$1 +# Solr moved to TLP Feb 2021 +# Redirect old location of Solr release doc and javadoc to new, changed location in solr.apache.org/docs +RedirectMatch temp ^/solr/api$ https://solr.apache.org/api/ +RedirectMatch Permanent ^/solr/(\d+_\d+_\d+)$ https://solr.apache.org/docs/$1 +# These will be further rewritten to SOLR_LATEST_RELEASE on the solr side +RedirectMatch temp ^/solr/api/org/(.*) https://solr.apache.org/api/org/$1 +RedirectMatch temp ^/solr/api/(.*) https://solr.apache.org/api/$1 +RedirectMatch Permanent ^/solr/4_0_0-(ALPHA|BETA)(.*) https://solr.apache.org/docs/4_0_0/$2 +RedirectMatch Permanent ^/solr/api-(.*) https://solr.apache.org/docs/$1 +# Fallback redirect for anythin not caught above +RedirectMatch Permanent ^/solr/(.*)$ https://solr.apache.org/$1 Review comment: This is all much too complicated! Why do we need the specializations at all. In addition they still contain duplicates (caused by the "__root"-aapend-slash-handling added on the solr side. We only need exactly one redirect; it should just replace prefix: ``` Redirect permanent /solr https://solr.apache.org ``` Everything else is handled by Solr's side. Browsers are perfectly happy with 2 or three redircets. Also the main purpose here is to tell lucene.apache.org/solr visitors that the main "permanent" target is solr.apache.org. Later redirects should be done from there, as it's on Solr's responsibility. We we also need no wildcard redirect (regex not needed). The above plain standard prefix redirect is enough. Also order of "standard prefix" redirects in apache is by length. Longest prefixes first. https://httpd.apache.org/docs/2.4/mod/mod_alias.html#redirect: "Then any request beginning with URL-path will return a redirect request to the client at the location of the target URL. Additional path information beyond the matched URL-path will be appended to the target URL." You can test all this on the Lucene staging site. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ctargett commented on pull request #2437: SOLR-15204: Document bin solr zk and zkcli
ctargett commented on pull request #2437: URL: https://github.com/apache/lucene-solr/pull/2437#issuecomment-789203451 > if I roll back the changes to command-line-utilities.adoc, then does the other edits make sense to you? Yes, +1 to those. I agree ultimately on zkcli.sh and would also like to actually get rid of the page, but I don't (yet) know if the current capabilities of `bin/solr zk` can accomplish all of the same things. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-15171) Add redirects from old Solr site to new
[
https://issues.apache.org/jira/browse/SOLR-15171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-15171:
---
Description:
The lucene.apache.org website needs to have updated {{.htaccess}} rules to
redirect any and all {{lucene.apache.org/solr/\*}} paths to
{{solr.apache.org/\*}}.
Also the ATOM/RSS feed URLs should be redirected, so those that monitor
security news and releases will not have an interruption.
was:
The lucene.apache.org website needs to have updated {{.htaccess}} rules to
redirect any and all {{lucene.apache.org/solr/*}} paths to
{{solr.apache.org/*}}.
Also the ATOM/RSS feed URLs should be redirected, so those that monitor
security news and releases will not have an interruption.
> Add redirects from old Solr site to new
> ---
>
> Key: SOLR-15171
> URL: https://issues.apache.org/jira/browse/SOLR-15171
> Project: Solr
> Issue Type: Sub-task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> The lucene.apache.org website needs to have updated {{.htaccess}} rules to
> redirect any and all {{lucene.apache.org/solr/\*}} paths to
> {{solr.apache.org/\*}}.
> Also the ATOM/RSS feed URLs should be redirected, so those that monitor
> security news and releases will not have an interruption.
--
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
[GitHub] [lucene-site] janhoy commented on a change in pull request #48: SOLR-15171 Add redirects from old Solr site to new
janhoy commented on a change in pull request #48: URL: https://github.com/apache/lucene-site/pull/48#discussion_r585891181 ## File path: themes/lucene/templates/htaccess.template ## @@ -126,19 +91,24 @@ RedirectMatch Permanent ^/nutch/(.*)$ https://nutch.apache.org/$1 # Lucy has moved, site strcuture has changed, do don't use $1 in redirect... RedirectMatch Permanent ^/lucy/(.*)$ https://lucy.apache.org/ -# promote Solr to TLP -# TODO: This links to the staging site for new Solr - change the redirect to TLP page -#RedirectMatch Permanent ^/solr/(.*)$ https://solr.apache.org/$1 -RedirectMatch Permanent ^/solr/(.*)$ https://lucene-solrtlp.staged.apache.org/$1 +# Solr moved to TLP Feb 2021 +# Redirect old location of Solr release doc and javadoc to new, changed location in solr.apache.org/docs +RedirectMatch temp ^/solr/api$ https://solr.apache.org/api/ +RedirectMatch Permanent ^/solr/(\d+_\d+_\d+)$ https://solr.apache.org/docs/$1 +# These will be further rewritten to SOLR_LATEST_RELEASE on the solr side +RedirectMatch temp ^/solr/api/org/(.*) https://solr.apache.org/api/org/$1 +RedirectMatch temp ^/solr/api/(.*) https://solr.apache.org/api/$1 +RedirectMatch Permanent ^/solr/4_0_0-(ALPHA|BETA)(.*) https://solr.apache.org/docs/4_0_0/$2 +RedirectMatch Permanent ^/solr/api-(.*) https://solr.apache.org/docs/$1 +# Fallback redirect for anythin not caught above +RedirectMatch Permanent ^/solr/(.*)$ https://solr.apache.org/$1 Review comment: I deleted all solr related redirects from this file and added the needed ones in one single block here. The strategy is to first catch specialized patterns that need custom handling, and then fallback to the generic `/solr/.*` wildcard redirect, which may then trigger further rules on the Solr-side. * First we tackle some javadoc locations and send to the new solr.apache.org/docs/ location * The ref guide URLs `/solr/guide/.*` as well as `/solr/doap.rdf` will be covered by the last fallback rule This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15171) Add redirects from old Solr site to new
[
https://issues.apache.org/jira/browse/SOLR-15171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293969#comment-17293969
]
Jan Høydahl commented on SOLR-15171:
PR: [https://github.com/apache/lucene-site/pull/48]
> Add redirects from old Solr site to new
> ---
>
> Key: SOLR-15171
> URL: https://issues.apache.org/jira/browse/SOLR-15171
> Project: Solr
> Issue Type: Sub-task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> The lucene.apache.org website needs to have updated {{.htaccess}} rules to
> redirect any and all {{lucene.apache.org/solr/*}} paths to
> {{solr.apache.org/*}}.
> Also the ATOM/RSS feed URLs should be redirected, so those that monitor
> security news and releases will not have an interruption.
--
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
[GitHub] [lucene-site] janhoy opened a new pull request #48: SOLR-15171 Add redirects from old Solr site to new
janhoy opened a new pull request #48: URL: https://github.com/apache/lucene-site/pull/48 https://issues.apache.org/jira/browse/SOLR-15171 These are the Lucene-side redirects to new Solr site This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr-operator] HoustonPutman opened a new pull request #230: Update the owner reference of owned resources, if the reference is not correct
HoustonPutman opened a new pull request #230: URL: https://github.com/apache/lucene-solr-operator/pull/230 Relates to #222 This change is necessary if in-place updates from Bloomberg resources to Apache resources are to succeed. With this change, resources created for Bloomberg SolrClouds can be claimed and re-controlled by Apache SolrClouds. This does make new resource management code more complex, but it is a good feature to have, probably. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - 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&focusedCommentId=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&page=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
[GitHub] [lucene-solr] jtibshirani commented on a change in pull request #2444: LUCENE-9705: Create Lucene90StoredFieldsFormat
jtibshirani commented on a change in pull request #2444:
URL: https://github.com/apache/lucene-solr/pull/2444#discussion_r585829585
##
File path:
lucene/core/src/java/org/apache/lucene/codecs/compressing/Lucene90CompressingStoredFieldsFormat.java
##
@@ -40,7 +40,7 @@
*
* @lucene.experimental
*/
-public class CompressingStoredFieldsFormat extends StoredFieldsFormat {
+public class Lucene90CompressingStoredFieldsFormat extends StoredFieldsFormat {
Review comment:
I think these should be moved to the package `lucene90.compressing`.
##
File path:
lucene/backward-codecs/src/java/org/apache/lucene/backward_codecs/lucene87/Lucene87Codec.java
##
@@ -101,14 +102,22 @@ public DocValuesFormat getDocValuesFormatForField(String
field) {
/** Instantiates a new codec. */
public Lucene87Codec() {
+this(Mode.BEST_COMPRESSION);
Review comment:
Maybe we could avoid adding a default constructor here? I think it's
only used in `Lucene87RWCodec`.
##
File path:
lucene/backward-codecs/src/test/org/apache/lucene/backward_codecs/lucene87/Lucene87RWCodec.java
##
@@ -37,6 +38,17 @@ public PostingsFormat getPostingsFormatForField(String
field) {
return defaultPF;
}
};
+ private final Mode mode;
+
+ public Lucene87RWCodec() {
+super();
+this.mode = Mode.BEST_COMPRESSION;
Review comment:
I think we should default to `BEST_SPEED` instead of `BEST_COMPRESSION`,
otherwise `BEST_SPEED` won't be exercised in unit tests. We could factor this
like the other `Lucene86RWCodec` classes and just create a default
`Lucene87StoredFieldsFormat` here?
##
File path:
lucene/core/src/java/org/apache/lucene/codecs/compressing/LZ4WithPresetDictCompressionMode.java
##
@@ -14,12 +14,9 @@
* See the License for the specific language governing permissions and
* limitations under the License.
*/
-package org.apache.lucene.codecs.lucene87;
+package org.apache.lucene.codecs.compressing;
Review comment:
It seems like these classes should also be duplicated into 87 and 90
versions, with the 90 versions living in the `lucene90.compressing` package. In
other places we decided not to share encoder/ decoder helper classes, for
example we duplicated `ForUtil` instead of sharing it across postings formats.
##
File path:
lucene/backward-codecs/src/java/org/apache/lucene/backward_codecs/lucene50/compressing/Lucene50CompressingStoredFieldsFormat.java
##
@@ -0,0 +1,162 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.backward_codecs.lucene50.compressing;
+
+import java.io.IOException;
+import org.apache.lucene.codecs.CodecUtil;
+import org.apache.lucene.codecs.StoredFieldsFormat;
+import org.apache.lucene.codecs.StoredFieldsReader;
+import org.apache.lucene.codecs.StoredFieldsWriter;
+import org.apache.lucene.codecs.compressing.CompressionMode;
+import org.apache.lucene.index.FieldInfos;
+import org.apache.lucene.index.MergePolicy;
+import org.apache.lucene.index.SegmentInfo;
+import org.apache.lucene.store.Directory;
+import org.apache.lucene.store.IOContext;
+import org.apache.lucene.util.packed.DirectMonotonicWriter;
+
+/**
+ * A {@link StoredFieldsFormat} that compresses documents in chunks in order
to improve the
+ * compression ratio.
+ *
+ * For a chunk size of chunkSize bytes, this {@link
StoredFieldsFormat} does not
+ * support documents larger than (231 - chunkSize)
bytes.
+ *
+ * For optimal performance, you should use a {@link MergePolicy} that
returns segments that have
+ * the biggest byte size first.
+ *
+ * @lucene.experimental
+ */
+public class Lucene50CompressingStoredFieldsFormat extends StoredFieldsFormat {
+
+ /** format name */
+ protected final String formatName;
Review comment:
No strong opinion, but instead of making these protected we could
hardcode certain values in `Lucene50RWCompressingStoredFieldsFormat`. This is
what we do in `Lucene50RWPostingsFormat`.
##
File path:
lucene/backward-codecs/src/java/org/apache/lucene/backward_codecs/lucene50/compressing/Lucene50CompressingStoredFieldsReader.java
##
@@ -654,15 +669,7 @@ public void readBy
[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&focusedCommentId=17293955#comment-17293955 ] David Smiley commented on SOLR-14663: - The test in TestConfigsApi has been failing ~7% of the time since it was touched October 1st: http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.handler.TestContainerPlugin.testApi This issue can't be reopened but can someone please open a new issue to deal with this test failure? (and link here) > 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] [Reopened] (SOLR-15191) Faceting on EnumFieldType does not work if allBuckets, numBuckets or missing is set
[ https://issues.apache.org/jira/browse/SOLR-15191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley reopened SOLR-15191: - Test failure: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/9730/testReport/junit/org.apache.solr.schema/EnumFieldTest/testFacetEnumSearch/ Can you please look [~thomas.woeckinger]? > Faceting on EnumFieldType does not work if allBuckets, numBuckets or missing > is set > --- > > Key: SOLR-15191 > URL: https://issues.apache.org/jira/browse/SOLR-15191 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module, FacetComponent, faceting, search, > streaming expressions >Affects Versions: 8.7, 8.8, 8.8.1 >Reporter: Thomas Wöckinger >Assignee: David Smiley >Priority: Major > Labels: easy-fix, pull-request-available > Fix For: 8.9 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Due to Solr-14514 FacetFieldProcessorByEnumTermsStream is not used if > allBuckets, numBuckets or missing parma is true. > As fallback FacetFieldProcessorByHashDV is used which > FacetRangeProcessor.getNumericCalc(sf) on the field. EnumFileType is not > handled currently, so a SolrException is thrown with BAD_REQUEST and > 'Expected numeric field type' -- 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-15210) ParallelStream should execute hashing & filtering directly in ExportWriter
Andrzej Bialecki created SOLR-15210:
---
Summary: ParallelStream should execute hashing & filtering
directly in ExportWriter
Key: SOLR-15210
URL: https://issues.apache.org/jira/browse/SOLR-15210
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Andrzej Bialecki
Assignee: Andrzej Bialecki
Currently ParallelStream uses {{HashQParserPlugin}} to partition the work based
on a hashed value of {{partitionKeys}}. Unfortunately, this filter has a high
initial runtime cost because it has to materialize all values of
{{partitionKeys}} on each worker in order to calculate their hash and decide
whether a particular doc belongs to the worker's partition.
The alternative approach would be for the worker to collect and sort all
documents and only then filter out the ones that belong to the current
partition just before they are written out by {{ExportWriter}} - at this point
we have to materialize the fields anyway but also we can benefit from a
(minimal) BytesRef caching that the FieldWriters use. On the other hand we pay
the price of sorting all documents, and we also lose the query filter caching
that the {{HashQParserPlugin}} uses.
This tradeoff is not obvious but should be investigated to see if it offers
better performance.
--
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-11207) Add OWASP dependency checker to detect security vulnerabilities in third party libraries
[ https://issues.apache.org/jira/browse/SOLR-11207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293942#comment-17293942 ] David Smiley commented on SOLR-11207: - Similarly to how the PMC gets a weekly email of security JIRA issues; maybe there should be regular emails on our transitive vulnerabilities from this tool somehow? The former is a JIRA feature but this here would obviously be something different... maybe a dedicated CI job? > Add OWASP dependency checker to detect security vulnerabilities in third > party libraries > > > Key: SOLR-11207 > URL: https://issues.apache.org/jira/browse/SOLR-11207 > Project: Solr > Issue Type: Improvement > Components: Build >Affects Versions: 6.0 >Reporter: Hrishikesh Gadre >Assignee: Jan Høydahl >Priority: Major > Fix For: master (9.0) > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Lucene/Solr project depends on number of third party libraries. Some of those > libraries contain security vulnerabilities. Upgrading to versions of those > libraries that have fixes for those vulnerabilities is a simple, critical > step we can take to improve the security of the system. But for that we need > a tool which can scan the Lucene/Solr dependencies and look up the security > database for known vulnerabilities. > I found that [OWASP > dependency-checker|https://jeremylong.github.io/DependencyCheck/dependency-check-ant/] > can be used for this purpose. It provides a ant task which we can include in > the Lucene/Solr build. We also need to figure out how (and when) to invoke > this dependency-checker. But this can be figured out once we complete the > first step of integrating this tool with the Lucene/Solr build system. -- 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-15177) Handle RefGuide and JavaDoc on solr.apache.org site
[ https://issues.apache.org/jira/browse/SOLR-15177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl reassigned SOLR-15177: -- Assignee: Jan Høydahl > Handle RefGuide and JavaDoc on solr.apache.org site > --- > > Key: SOLR-15177 > URL: https://issues.apache.org/jira/browse/SOLR-15177 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Make sure we have a working solution for referencing both old and new (9.x) > ref-guides and javadoc. > * Shall we move solr-related content in svn and point everything to the new > site? > * Make sure .htaccess rules work for this -- 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-15171) Add redirects from old Solr site to new
[
https://issues.apache.org/jira/browse/SOLR-15171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl reassigned SOLR-15171:
--
Assignee: Jan Høydahl
> Add redirects from old Solr site to new
> ---
>
> Key: SOLR-15171
> URL: https://issues.apache.org/jira/browse/SOLR-15171
> Project: Solr
> Issue Type: Sub-task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> The lucene.apache.org website needs to have updated {{.htaccess}} rules to
> redirect any and all {{lucene.apache.org/solr/*}} paths to
> {{solr.apache.org/*}}.
> Also the ATOM/RSS feed URLs should be redirected, so those that monitor
> security news and releases will not have an interruption.
--
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-15177) Handle RefGuide and JavaDoc on solr.apache.org site
[ https://issues.apache.org/jira/browse/SOLR-15177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-15177. Resolution: Fixed > Handle RefGuide and JavaDoc on solr.apache.org site > --- > > Key: SOLR-15177 > URL: https://issues.apache.org/jira/browse/SOLR-15177 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Make sure we have a working solution for referencing both old and new (9.x) > ref-guides and javadoc. > * Shall we move solr-related content in svn and point everything to the new > site? > * Make sure .htaccess rules work for this -- 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-15177) Handle RefGuide and JavaDoc on solr.apache.org site
[ https://issues.apache.org/jira/browse/SOLR-15177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293941#comment-17293941 ] Jan Høydahl commented on SOLR-15177: I merged the PR, thanks Uwe for the review. Hopefully this is sorted out then. Will proceed with Lucene side rewrite rules > Handle RefGuide and JavaDoc on solr.apache.org site > --- > > Key: SOLR-15177 > URL: https://issues.apache.org/jira/browse/SOLR-15177 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Priority: Major > > Make sure we have a working solution for referencing both old and new (9.x) > ref-guides and javadoc. > * Shall we move solr-related content in svn and point everything to the new > site? > * Make sure .htaccess rules work for this -- 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
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #2442: SOLR-15205: don't mention (deprecated) CloudSolrClient.setIdField in javadocs
dsmiley commented on a change in pull request #2442:
URL: https://github.com/apache/lucene-solr/pull/2442#discussion_r585842516
##
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/impl/CloudHttp2SolrClient.java
##
@@ -32,10 +32,6 @@
* Solr endpoints for SolrCloud collections, and then use the
* {@link LBHttp2SolrClient} to issue requests.
*
- * This class assumes the id field for your documents is called
- * 'id' - if this is not the case, you must set the right name
Review comment:
What is coming from ZooKeeper? Maybe the "route field" which is in the
collection state (DocCollection) but not the uniqueKey field which is in the
schema and AFAIK it not resolved by CloudSolrClient.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-site] janhoy merged pull request #47: SOLR-15177: Attempt to link to javadoc and refguide in htaccess
janhoy merged pull request #47: URL: https://github.com/apache/lucene-site/pull/47 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-site] janhoy commented on a change in pull request #47: SOLR-15177: Attempt to link to javadoc and refguide in htaccess
janhoy commented on a change in pull request #47:
URL: https://github.com/apache/lucene-site/pull/47#discussion_r585840767
##
File path: themes/solr/templates/htaccess.template
##
@@ -46,33 +46,32 @@ RedirectMatch Permanent ^mirrors-solr-3x-redir
downloads.html
RedirectMatch Permanent ^mirrors-solr-redir.html downloads.html
# Simple redirect to "directory", so later rules match
-RedirectMatch temp ^/(core|solr)/api$ $0/
-RedirectMatch Permanent ^/(core|solr)/\d+_\d+_\d+$ $0/
-RedirectMatch Permanent ^/solr/guide/\d+_\d+$ $0/
+RedirectMatch temp ^/api$ $0/
+RedirectMatch Permanent ^/docs/\d+_\d+_\d+$ $0/
+RedirectMatch Permanent ^/guide/\d+_\d+$ $0/
# Other pages can always be redirected to the "most current" released javadocs
# using "temp" instead of permanent so crawlers know that they
# might change again in the future
-RedirectMatch temp ^/core/api/(.*) /core/{{ SOLR_LATEST_RELEASE | replace(".",
"_") }}/$1
-RedirectMatch temp ^/solr/api/org/(.*) /solr/{{ SOLR_LATEST_RELEASE |
replace(".", "_") }}/solr-core/org/$1
-RedirectMatch temp ^/solr/api/(.*) /solr/{{ SOLR_LATEST_RELEASE | replace(".",
"_") }}/$1
-RedirectMatch temp ^/solr/guide/(?!index.html)([a-z].*) /solr/guide/{{
SOLR_LATEST_RELEASE.rsplit(".", 1) | first | replace(".", "_") }}/$1
+RedirectMatch temp ^/api/org/(.*) /docs/{{ SOLR_LATEST_RELEASE | replace(".",
"_") }}/solr-core/org/$1
+RedirectMatch temp ^/api/(.*) /docs/{{ SOLR_LATEST_RELEASE | replace(".", "_")
}}/$1
+RedirectMatch temp ^/guide/(?!index.html)([a-z].*) /guide/{{
SOLR_LATEST_RELEASE.rsplit(".", 1) | first | replace(".", "_") }}/$1
# Solr Tutorial is now in the Solr Ref Guide
# should redirect automatically to latest version
-RedirectMatch Permanent ^/quickstart.html /solr/guide/solr-tutorial.html
+RedirectMatch Permanent ^/quickstart.html /guide/solr-tutorial.html
# redirect older point versions to latest (to keep number of javadocs small):
-RedirectMatch Permanent ^/solr/4_0_0-(ALPHA|BETA)(.*) /solr/4_0_0$2
-RedirectMatch Permanent ^/solr/api-(.*) /solr/$1
+RedirectMatch Permanent ^/docs/4_0_0-(ALPHA|BETA)(.*) /docs/4_0_0$2
Review comment:
Yes, on the Lucene side of things I think we can do like this, except
the /solr/X_Y_Z which must be rewritten to /docs/X_Y_Z. So putting those rules
first and fallback to the generic rule shold do the trick.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-site] janhoy commented on a change in pull request #47: SOLR-15177: Attempt to link to javadoc and refguide in htaccess
janhoy commented on a change in pull request #47:
URL: https://github.com/apache/lucene-site/pull/47#discussion_r585838432
##
File path: themes/solr/templates/htaccess.template
##
@@ -46,33 +46,32 @@ RedirectMatch Permanent ^mirrors-solr-3x-redir
downloads.html
RedirectMatch Permanent ^mirrors-solr-redir.html downloads.html
# Simple redirect to "directory", so later rules match
-RedirectMatch temp ^/(core|solr)/api$ $0/
-RedirectMatch Permanent ^/(core|solr)/\d+_\d+_\d+$ $0/
-RedirectMatch Permanent ^/solr/guide/\d+_\d+$ $0/
+RedirectMatch temp ^/api$ $0/
+RedirectMatch Permanent ^/docs/\d+_\d+_\d+$ $0/
+RedirectMatch Permanent ^/guide/\d+_\d+$ $0/
# Other pages can always be redirected to the "most current" released javadocs
# using "temp" instead of permanent so crawlers know that they
# might change again in the future
-RedirectMatch temp ^/core/api/(.*) /core/{{ SOLR_LATEST_RELEASE | replace(".",
"_") }}/$1
-RedirectMatch temp ^/solr/api/org/(.*) /solr/{{ SOLR_LATEST_RELEASE |
replace(".", "_") }}/solr-core/org/$1
-RedirectMatch temp ^/solr/api/(.*) /solr/{{ SOLR_LATEST_RELEASE | replace(".",
"_") }}/$1
-RedirectMatch temp ^/solr/guide/(?!index.html)([a-z].*) /solr/guide/{{
SOLR_LATEST_RELEASE.rsplit(".", 1) | first | replace(".", "_") }}/$1
+RedirectMatch temp ^/api/org/(.*) /docs/{{ SOLR_LATEST_RELEASE | replace(".",
"_") }}/solr-core/org/$1
+RedirectMatch temp ^/api/(.*) /docs/{{ SOLR_LATEST_RELEASE | replace(".", "_")
}}/$1
+RedirectMatch temp ^/guide/(?!index.html)([a-z].*) /guide/{{
SOLR_LATEST_RELEASE.rsplit(".", 1) | first | replace(".", "_") }}/$1
# Solr Tutorial is now in the Solr Ref Guide
# should redirect automatically to latest version
-RedirectMatch Permanent ^/quickstart.html /solr/guide/solr-tutorial.html
+RedirectMatch Permanent ^/quickstart.html /guide/solr-tutorial.html
# redirect older point versions to latest (to keep number of javadocs small):
-RedirectMatch Permanent ^/solr/4_0_0-(ALPHA|BETA)(.*) /solr/4_0_0$2
-RedirectMatch Permanent ^/solr/api-(.*) /solr/$1
+RedirectMatch Permanent ^/docs/4_0_0-(ALPHA|BETA)(.*) /docs/4_0_0$2
+RedirectMatch Permanent ^/docs/api-(.*) /docs/$1
### Javadocs & Solr Refguide
# Hack: Append slash, if folder name does not end with slash - everything
containing a "." is treated as file and excluded from redirect:
-RewriteRule ^(core|solr)/\d+_\d+_\d+/(?!.+\.\w+$|.+/$).+$ $0/ [R=301,L]
-RewriteRule ^solr/guide/\d+_\d+/(?!.+\.\w+$|.+/$).+$$0/ [R=301,L]
+RewriteRule ^docs/\d+_\d+_\d+/(?!.+\.\w+$|.+/$).+$ $0/ [R=301,L]
+RewriteRule ^guide/\d+_\d+/(?!.+\.\w+$|.+/$).+$ $0/ [R=301,L]
# __root/docs.lucene.apache.org/content/ is a special alias added by
INFRA-19439, so we can refer to stuff in other places like SVN:
-RewriteRule ^(core|solr)/\d+_\d+_\d+/.*$
__root/docs.lucene.apache.org/content/$0 [PT]
-RewriteRule ^solr/guide/\d+_\d+/.*$
__root/docs.lucene.apache.org/content/$0 [PT]
+RewriteRule ^docs/(\d+_\d+_\d+/.*)$
__root/docs.lucene.apache.org/content/solr/$1 [PT]
Review comment:
Yes, looks like it is supported:
https://httpd.apache.org/docs/2.4/rewrite/intro.html#InternalBackRefs
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-site] uschindler commented on a change in pull request #47: SOLR-15177: Attempt to link to javadoc and refguide in htaccess
uschindler commented on a change in pull request #47:
URL: https://github.com/apache/lucene-site/pull/47#discussion_r585832210
##
File path: themes/solr/templates/htaccess.template
##
@@ -46,33 +46,32 @@ RedirectMatch Permanent ^mirrors-solr-3x-redir
downloads.html
RedirectMatch Permanent ^mirrors-solr-redir.html downloads.html
# Simple redirect to "directory", so later rules match
-RedirectMatch temp ^/(core|solr)/api$ $0/
-RedirectMatch Permanent ^/(core|solr)/\d+_\d+_\d+$ $0/
-RedirectMatch Permanent ^/solr/guide/\d+_\d+$ $0/
+RedirectMatch temp ^/api$ $0/
+RedirectMatch Permanent ^/docs/\d+_\d+_\d+$ $0/
+RedirectMatch Permanent ^/guide/\d+_\d+$ $0/
# Other pages can always be redirected to the "most current" released javadocs
# using "temp" instead of permanent so crawlers know that they
# might change again in the future
-RedirectMatch temp ^/core/api/(.*) /core/{{ SOLR_LATEST_RELEASE | replace(".",
"_") }}/$1
-RedirectMatch temp ^/solr/api/org/(.*) /solr/{{ SOLR_LATEST_RELEASE |
replace(".", "_") }}/solr-core/org/$1
-RedirectMatch temp ^/solr/api/(.*) /solr/{{ SOLR_LATEST_RELEASE | replace(".",
"_") }}/$1
-RedirectMatch temp ^/solr/guide/(?!index.html)([a-z].*) /solr/guide/{{
SOLR_LATEST_RELEASE.rsplit(".", 1) | first | replace(".", "_") }}/$1
+RedirectMatch temp ^/api/org/(.*) /docs/{{ SOLR_LATEST_RELEASE | replace(".",
"_") }}/solr-core/org/$1
+RedirectMatch temp ^/api/(.*) /docs/{{ SOLR_LATEST_RELEASE | replace(".", "_")
}}/$1
+RedirectMatch temp ^/guide/(?!index.html)([a-z].*) /guide/{{
SOLR_LATEST_RELEASE.rsplit(".", 1) | first | replace(".", "_") }}/$1
# Solr Tutorial is now in the Solr Ref Guide
# should redirect automatically to latest version
-RedirectMatch Permanent ^/quickstart.html /solr/guide/solr-tutorial.html
+RedirectMatch Permanent ^/quickstart.html /guide/solr-tutorial.html
# redirect older point versions to latest (to keep number of javadocs small):
-RedirectMatch Permanent ^/solr/4_0_0-(ALPHA|BETA)(.*) /solr/4_0_0$2
-RedirectMatch Permanent ^/solr/api-(.*) /solr/$1
+RedirectMatch Permanent ^/docs/4_0_0-(ALPHA|BETA)(.*) /docs/4_0_0$2
Review comment:
I am not sure if we need those, as the solr.apache.org site is new, so
the "old" redirects should not be there anyways. It depends on the redirects on
Lucene side: If we have a general perm (301) redirect from
lucene.apache.org/solr/ -> solr.apache.org/, we should keep them here.
##
File path: themes/solr/templates/htaccess.template
##
@@ -46,33 +46,32 @@ RedirectMatch Permanent ^mirrors-solr-3x-redir
downloads.html
RedirectMatch Permanent ^mirrors-solr-redir.html downloads.html
# Simple redirect to "directory", so later rules match
-RedirectMatch temp ^/(core|solr)/api$ $0/
-RedirectMatch Permanent ^/(core|solr)/\d+_\d+_\d+$ $0/
-RedirectMatch Permanent ^/solr/guide/\d+_\d+$ $0/
+RedirectMatch temp ^/api$ $0/
+RedirectMatch Permanent ^/docs/\d+_\d+_\d+$ $0/
+RedirectMatch Permanent ^/guide/\d+_\d+$ $0/
# Other pages can always be redirected to the "most current" released javadocs
# using "temp" instead of permanent so crawlers know that they
# might change again in the future
-RedirectMatch temp ^/core/api/(.*) /core/{{ SOLR_LATEST_RELEASE | replace(".",
"_") }}/$1
-RedirectMatch temp ^/solr/api/org/(.*) /solr/{{ SOLR_LATEST_RELEASE |
replace(".", "_") }}/solr-core/org/$1
-RedirectMatch temp ^/solr/api/(.*) /solr/{{ SOLR_LATEST_RELEASE | replace(".",
"_") }}/$1
-RedirectMatch temp ^/solr/guide/(?!index.html)([a-z].*) /solr/guide/{{
SOLR_LATEST_RELEASE.rsplit(".", 1) | first | replace(".", "_") }}/$1
+RedirectMatch temp ^/api/org/(.*) /docs/{{ SOLR_LATEST_RELEASE | replace(".",
"_") }}/solr-core/org/$1
+RedirectMatch temp ^/api/(.*) /docs/{{ SOLR_LATEST_RELEASE | replace(".", "_")
}}/$1
+RedirectMatch temp ^/guide/(?!index.html)([a-z].*) /guide/{{
SOLR_LATEST_RELEASE.rsplit(".", 1) | first | replace(".", "_") }}/$1
# Solr Tutorial is now in the Solr Ref Guide
# should redirect automatically to latest version
-RedirectMatch Permanent ^/quickstart.html /solr/guide/solr-tutorial.html
+RedirectMatch Permanent ^/quickstart.html /guide/solr-tutorial.html
# redirect older point versions to latest (to keep number of javadocs small):
-RedirectMatch Permanent ^/solr/4_0_0-(ALPHA|BETA)(.*) /solr/4_0_0$2
-RedirectMatch Permanent ^/solr/api-(.*) /solr/$1
+RedirectMatch Permanent ^/docs/4_0_0-(ALPHA|BETA)(.*) /docs/4_0_0$2
+RedirectMatch Permanent ^/docs/api-(.*) /docs/$1
### Javadocs & Solr Refguide
# Hack: Append slash, if folder name does not end with slash - everything
containing a "." is treated as file and excluded from redirect:
-RewriteRule ^(core|solr)/\d+_\d+_\d+/(?!.+\.\w+$|.+/$).+$ $0/ [R=301,L]
-RewriteRule ^solr/guide/\d+_\d+/(?!.+\.\w+$|.+/$).+$$0/ [R=301,L]
+RewriteRule ^docs/\d+_\d+_\d+/(?!.+\.\w+$|.+/$).+$ $0/ [R=301,L]
+RewriteRule ^guide/\d+_\d+/(?!.+\.\w+$|.+/$).+$ $0/ [R=301,L]
# __root/docs.l
[jira] [Commented] (SOLR-15177) Handle RefGuide and JavaDoc on solr.apache.org site
[ https://issues.apache.org/jira/browse/SOLR-15177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293932#comment-17293932 ] Jan Høydahl commented on SOLR-15177: Ah, I just confirmed that the __root hack works for Solr as well: [https://solr.apache.org/__root/docs.lucene.apache.org/content/solr/] Which means that after [PR#47|https://github.com/apache/lucene-site/pull/47], it should all "just work"... > Handle RefGuide and JavaDoc on solr.apache.org site > --- > > Key: SOLR-15177 > URL: https://issues.apache.org/jira/browse/SOLR-15177 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Priority: Major > > Make sure we have a working solution for referencing both old and new (9.x) > ref-guides and javadoc. > * Shall we move solr-related content in svn and point everything to the new > site? > * Make sure .htaccess rules work for this -- 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
[GitHub] [lucene-solr] sigram commented on pull request #1524: SOLR-15185: Rewrite Hash query
sigram commented on pull request #1524: URL: https://github.com/apache/lucene-solr/pull/1524#issuecomment-789110063 @dsmiley the improvements Joel and I are considering are totally independent of this cleanup - please proceed with this PR. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13265) TLOG replica, updateHandler errors in metrics, no logs
[ https://issues.apache.org/jira/browse/SOLR-13265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293834#comment-17293834 ] Nick Vladiceanu commented on SOLR-13265: hello folks, we're having the same issue on 8.7.0 version. Switched from NRT to TLOG (removed replicas and added them back as TLOG), the errors are appearing on the TLOG followers, but not on the TLOG leader. Do you have any updates on this issue? It's weird because there is nothing in the logs. thank you > TLOG replica, updateHandler errors in metrics, no logs > -- > > Key: SOLR-13265 > URL: https://issues.apache.org/jira/browse/SOLR-13265 > Project: Solr > Issue Type: Bug >Affects Versions: 7.5, 7.7 >Reporter: Markus Jelsma >Priority: Major > > When indexing, we see UPDATE.updateHandler.errors increment for each document > being indexed, there is nothing in the logs. > This happens only to TLOG replica's, the NRT is unaffected. 7.5 and 7.7 both > have the problem. > Nothing bad is happening, but this is messing up our Grafana graphs that we > use to check the health. -- 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-15209) Make the AffinityPlacementFactory the default placement plugin
[
https://issues.apache.org/jira/browse/SOLR-15209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilan Ginzburg reassigned SOLR-15209:
Assignee: Ilan Ginzburg
> Make the AffinityPlacementFactory the default placement plugin
> --
>
> Key: SOLR-15209
> URL: https://issues.apache.org/jira/browse/SOLR-15209
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Assignee: Ilan Ginzburg
>Priority: Major
>
> Currently there's a lot of code in {{Assign}} dealing with the fact that we
> still support the old "legacy" replica assignment as well as the new
> plugin-based placement strategies.
> Furthermore, the "legacy" assignment is now the default even though it's
> neither robust nor optimal, except in the very simple and small clusters.
> Also, providing another plugin-based placement as the default impl. runs into
> a small complication - in the absence of any plugin config the code reverts
> to the "legacy".
> In order to promote the adoption of the new plugin-based placements we should
> make the {{AffinityPlacementFactory}} the new default placement strategy,
> selected when the explicit configuration is missing (and then create it as a
> default configuration in {{PlacementPluginFactoryLoader}}).
> I propose to re-package the "legacy" strategy as a {{PlacementPluginFactory}}
> so that it can be configured in the same way as other placement plugins.
--
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
[GitHub] [lucene-solr-operator] HoustonPutman commented on a change in pull request #226: Add terminationGracePeriod option, and use it when killing Solr.
HoustonPutman commented on a change in pull request #226: URL: https://github.com/apache/lucene-solr-operator/pull/226#discussion_r585699930 ## File path: docs/solr-cloud/solr-cloud-crd.md ## @@ -810,3 +812,22 @@ Also, changing the password for this user in the K8s secret will not update Solr If you enable basic auth for your SolrCloud cluster, then you need to point the Prometheus exporter at the basic auth secret; refer to [Prometheus Exporter with Basic Auth](../solr-prometheus-exporter/README.md#prometheus-exporter-with-basic-auth) for more details. + +## Various Runtime Parameters + +There are various runtime parameters that allow you to customize the running of your Solr Cloud via the Solr Operator. + +### Time to wait for Solr to be killed gracefully + +The Solr Operator manages the Solr StatefulSet in a way that when a Solr pod needs to be stopped, or deleted, Kubernetes and Solr are on the same page for how long to wait for the process to die gracefully. + +The default time given is 60 seconds, before Solr or Kubernetes tries to forcefully stop the Solr process. +You can override this default with the field: + +```yaml +spec: + ... + customSolrKubeOptions: +podOptions: + terminationGracePeriodSeconds: 120 Review comment: That command is kind of similar to kill -9. I'm not sure there is a way to protect against that. Is there a way to figure out what grace period is given when your pod is trying to be deleted? `Pod.spec` is static, so the `Pod.spec.terminationGracePeriodSeconds`, provided when the pod is created, will never change. If a user runs `k delete --grace-period=5s`, it will stay at `60` and not change to `5`. Most of the time, Pods are going to be deleted by Kubernetes (the statefulset controller) or the solrcloud controller, during managed upgrades. Neither of those use a different grace period, so the usage here is safe. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr-operator] HoustonPutman commented on a change in pull request #226: Add terminationGracePeriod option, and use it when killing Solr.
HoustonPutman commented on a change in pull request #226: URL: https://github.com/apache/lucene-solr-operator/pull/226#discussion_r585699930 ## File path: docs/solr-cloud/solr-cloud-crd.md ## @@ -810,3 +812,22 @@ Also, changing the password for this user in the K8s secret will not update Solr If you enable basic auth for your SolrCloud cluster, then you need to point the Prometheus exporter at the basic auth secret; refer to [Prometheus Exporter with Basic Auth](../solr-prometheus-exporter/README.md#prometheus-exporter-with-basic-auth) for more details. + +## Various Runtime Parameters + +There are various runtime parameters that allow you to customize the running of your Solr Cloud via the Solr Operator. + +### Time to wait for Solr to be killed gracefully + +The Solr Operator manages the Solr StatefulSet in a way that when a Solr pod needs to be stopped, or deleted, Kubernetes and Solr are on the same page for how long to wait for the process to die gracefully. + +The default time given is 60 seconds, before Solr or Kubernetes tries to forcefully stop the Solr process. +You can override this default with the field: + +```yaml +spec: + ... + customSolrKubeOptions: +podOptions: + terminationGracePeriodSeconds: 120 Review comment: That command is kind of similar to kill -9. I'm not sure there is a way to protect against that. Is there a way to figure out what grace period is given when your pod is trying to be deleted? Most of the time, Pods are going to be deleted by Kubernetes (the statefulset controller) or the solrcloud controller, during managed upgrades. Neither of those use a different grace period, so the usage here is safe. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-15209) Make the AffinityPlacementFactory the default placement plugin
Andrzej Bialecki created SOLR-15209:
---
Summary: Make the AffinityPlacementFactory the default placement
plugin
Key: SOLR-15209
URL: https://issues.apache.org/jira/browse/SOLR-15209
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Andrzej Bialecki
Currently there's a lot of code in {{Assign}} dealing with the fact that we
still support the old "legacy" replica assignment as well as the new
plugin-based placement strategies.
Furthermore, the "legacy" assignment is now the default even though it's
neither robust nor optimal, except in the very simple and small clusters. Also,
providing another plugin-based placement as the default impl. runs into a small
complication - in the absence of any plugin config the code reverts to the
"legacy".
In order to promote the adoption of the new plugin-based placements we should
make the {{AffinityPlacementFactory}} the new default placement strategy,
selected when the explicit configuration is missing (and then create it as a
default configuration in {{PlacementPluginFactoryLoader}}).
I propose to re-package the "legacy" strategy as a {{PlacementPluginFactory}}
so that it can be configured in the same way as other placement plugins.
--
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-15167) Move lucene-solr-operator repo
[ https://issues.apache.org/jira/browse/SOLR-15167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293789#comment-17293789 ] Houston Putman commented on SOLR-15167: --- I think it'll be good to announce after the repo has a permanent location. I can handle doing the website and ANNOUNCE emails. It shouldn't take long anyways. I'm ready to move once we have the solr site up and running, that I can host the helm charts at. I think it should be listed as a subproject, but I'm not exactly sure what that entails. Actually I do think we will need a separate sub-project, since we will need a separate DOAP file, right? > Move lucene-solr-operator repo > -- > > Key: SOLR-15167 > URL: https://issues.apache.org/jira/browse/SOLR-15167 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Houston Putman >Priority: Major > > The lucene-solr-operator repo will be (once again) moved, now to > "solr-operator". This must be ordered thorugh an INFRA ticker. > As this will once again break the URL for helm, that also needs an update in > relevant places. -- 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-15190) Create a release repo for Solr
[ https://issues.apache.org/jira/browse/SOLR-15190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293787#comment-17293787 ] Houston Putman commented on SOLR-15190: --- We will need to have this if the solr-operator needs a release, correct? If so I imagine the Solr Operator v0.3.0 will be cut much sooner than Solr 9.0 > Create a release repo for Solr > -- > > Key: SOLR-15190 > URL: https://issues.apache.org/jira/browse/SOLR-15190 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Priority: Major > > I think this will be created as we do the first release, i.e. nothing > explicit to do here until then? -- 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-15130) Allow per-collection replica placement node sets
[
https://issues.apache.org/jira/browse/SOLR-15130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki resolved SOLR-15130.
-
Fix Version/s: master (9.0)
Resolution: Fixed
> Allow per-collection replica placement node sets
>
>
> Key: SOLR-15130
> URL: https://issues.apache.org/jira/browse/SOLR-15130
> Project: Solr
> Issue Type: Improvement
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> This is an extension of the existing {{replica_type}} concept in the
> {{AffinityPlacementPlugin}}.
> Currently this concept allows users to distribute the placement of new
> replicas by type (NRT, TLOG, PULL) if the target nodes specify the list of
> allowed replica types that they accept. This can be easily extended to
> support any other system property value that the node reports, and pair it
> with any other collection property instead of replica type.
> The motivation for this is the use case where a cluster is logically divided
> into nodes with different types of work load (eg. searching, indexing and
> analytics). Currently it's not possible to configure the placement plugin in
> a way that automatically puts some collections on specific node sets -
> instead users would have to always specify the appropriate node set in every
> CREATE / ADD / MOVE replica request.
--
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-15208) Add the unique aggregation to the stats, facet and timeseries Streaming Expressions
[ https://issues.apache.org/jira/browse/SOLR-15208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-15208: -- Description: The *unique* function in the JSON facet API is currently not supported in the Streaming Expression pushdown analytics functions. This ticket will add support for *unique* aggregations in the stats, facet and timeseries Streaming Expressions. (was: The *unique* function in the JSON facet API is currently not supported in the Streaming Expression pushdown analytics functions. This ticket will add support for *unique* aggregations in stats, facet and timeseries aggregations. ) > Add the unique aggregation to the stats, facet and timeseries Streaming > Expressions > --- > > Key: SOLR-15208 > URL: https://issues.apache.org/jira/browse/SOLR-15208 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: streaming expressions >Reporter: Joel Bernstein >Priority: Major > > The *unique* function in the JSON facet API is currently not supported in the > Streaming Expression pushdown analytics functions. This ticket will add > support for *unique* aggregations in the stats, facet and timeseries > Streaming Expressions. -- 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-15208) Add the unique aggregation to the stats, facet and timeseries Streaming Expressions
[ https://issues.apache.org/jira/browse/SOLR-15208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-15208: -- Summary: Add the unique aggregation to the stats, facet and timeseries Streaming Expressions (was: Add the unique aggregation to the stats, facet and timeseries aggregation) > Add the unique aggregation to the stats, facet and timeseries Streaming > Expressions > --- > > Key: SOLR-15208 > URL: https://issues.apache.org/jira/browse/SOLR-15208 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: streaming expressions >Reporter: Joel Bernstein >Priority: Major > > The *unique* function in the JSON facet API is currently not supported in the > Streaming Expression pushdown analytics functions. This ticket will add > support for *unique* aggregations in stats, facet and timeseries > aggregations. -- 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-15208) Add the unique aggregation to the stats, facet and timeseries aggregation
Joel Bernstein created SOLR-15208: - Summary: Add the unique aggregation to the stats, facet and timeseries aggregation Key: SOLR-15208 URL: https://issues.apache.org/jira/browse/SOLR-15208 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: streaming expressions Reporter: Joel Bernstein The *unique* function in the JSON facet API is currently not supported in the Streaming Expression pushdown analytics functions. This ticket will add support for *unique* aggregations in stats, facet and timeseries aggregations. -- 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
[GitHub] [lucene-solr] mayya-sharipova edited a comment on pull request #2186: LUCENE-9334 Consistency of field data structures
mayya-sharipova edited a comment on pull request #2186: URL: https://github.com/apache/lucene-solr/pull/2186#issuecomment-783604414 @jpountz Adrien, I also wanted to ask your opinion about the behaviour of `writer.updateDocValues(Term term, fieldX)`, as I am not sure what to do in this case: 1. What should happen if `fieldX` doesn't exist in the segment (but exists globally)? 2. What should happen if `fieldX` doesn't have docValues enabled? Before in both of these cases `updateDocValues` worked well creating a new `FieldInfo` in the current segment if it doesn't exist or enabling doc values. But with current PR as the field schema is fixed, we can: 1. Thrown an error? Or allow only in a case where the global `fieldX` is only a docValues field? 2. Throw an error, as field schema is fixed now and docValues can't be enabled. WDYT? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9817) pathological test fixes
[ https://issues.apache.org/jira/browse/LUCENE-9817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293749#comment-17293749 ] Robert Muir commented on LUCENE-9817: - note to self: need to remove the AwaitsFix now that [~sokolov] has fixed LUCENE-9819 > pathological test fixes > --- > > Key: LUCENE-9817 > URL: https://issues.apache.org/jira/browse/LUCENE-9817 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Robert Muir >Priority: Major > Attachments: LUCENE-9817.patch, LUCENE-9817.patch > > > There are now 13,000+ tests in lucene, and if you don't have dozens of cores > the situation is slow (around 7 minutes here, with everything tuned as fast > as i can get it, running on tmpfs). > It is tricky to keep the situation sustainable: so many tests that usually > just take a few seconds but they all add up. To put it in perspective, > imagine if all 13000 tests only took 1s each, that's 3.5 hours of cpu time. > From my inspection, there are a few cases of inefficiency: > * tests with bad random parameters: they might normally be semi-well-behaved, > but "rarely" take 30 seconds. That's maybe like a 1% chance but keep in mind > 1% equates to 130 wild-west tests every run. > * tests spinning up too many threads and indexing too many docs > unnecessarily: there might literally be thousands of these, so that's a hard > problem to fix... and developers love to use lots of threads and docs in > tests. > * tests just being inefficient: stuff like creating indexes in setup/teardown > when they have many methods that may not even use them (hey, why did > testEqualsHashcode take 30 seconds, what is it doing?) > I only worked on the first case here, if i fixed anything involving the other > two, it was just because I noticed them while I was there. I temporarily > overrode methods like LuceneTestCase.rarely(), atLeast(), and so on to > present more pathological/worst-case conditions and tried to address them all. > So here's a patch to give ~ 80 seconds of cpu-time in tests back. YMMV, maybe > it helps you more if you are actually using hard disks and stuff! > Fixing the other issues here will require some more creativity/work, I will > followup. -- 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-9819) Look into TestKnnGraph random failures
[ https://issues.apache.org/jira/browse/LUCENE-9819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293752#comment-17293752 ] Robert Muir commented on LUCENE-9819: - Thanks [~sokolov] for taking care of this! > Look into TestKnnGraph random failures > -- > > Key: LUCENE-9819 > URL: https://issues.apache.org/jira/browse/LUCENE-9819 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Robert Muir >Priority: Major > > If you apply enough pressure to this test it will provoke failures. Let's > beast it from some specific git hash and figure out what is happening. -- 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] (LUCENE-9819) Look into TestKnnGraph random failures
[ https://issues.apache.org/jira/browse/LUCENE-9819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Sokolov resolved LUCENE-9819. - Resolution: Fixed I think this can be resolved now; I was easily able to reproduce before the fix, and beasted several 1000 runs after with no failures. However, please re-open if we see random fails here again. > Look into TestKnnGraph random failures > -- > > Key: LUCENE-9819 > URL: https://issues.apache.org/jira/browse/LUCENE-9819 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Robert Muir >Priority: Major > > If you apply enough pressure to this test it will provoke failures. Let's > beast it from some specific git hash and figure out what is happening. -- 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-15206) improve CoreContainer constructor javadocs
[ https://issues.apache.org/jira/browse/SOLR-15206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293732#comment-17293732 ] ASF subversion and git services commented on SOLR-15206: Commit 4fa0d5da6ebb66844701409b103e3507038b1a03 in lucene-solr's branch refs/heads/branch_8x from Christine Poerschke [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4fa0d5d ] SOLR-15206: improve CoreContainer constructor javadocs (#2443) > improve CoreContainer constructor javadocs > -- > > Key: SOLR-15206 > URL: https://issues.apache.org/jira/browse/SOLR-15206 > Project: Solr > Issue Type: Task >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > The actual signature and the signature mentioned in the javadocs has gotten > out of sync for at least one of the constructor variants. -- 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
[GitHub] [lucene-solr] cpoerschke commented on a change in pull request #2442: SOLR-15205: don't mention (deprecated) CloudSolrClient.setIdField in javadocs
cpoerschke commented on a change in pull request #2442:
URL: https://github.com/apache/lucene-solr/pull/2442#discussion_r585586764
##
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/impl/CloudHttp2SolrClient.java
##
@@ -32,10 +32,6 @@
* Solr endpoints for SolrCloud collections, and then use the
* {@link LBHttp2SolrClient} to issue requests.
*
- * This class assumes the id field for your documents is called
- * 'id' - if this is not the case, you must set the right name
Review comment:
Hmm, tricky. So the
https://github.com/apache/lucene-solr/commit/f9410e14614d1f9ebb88226c287f38cd4d0b3d1f
commit removes the `idField = ID` and replaces it with `routeFieldDeprecated =
null` i.e. no more use of "id" there but ...
When it comes to `routeFieldDeprecated` usage at
https://github.com/apache/lucene-solr/blob/releases/lucene-solr%2F8.7.0/solr/solrj/src/java/org/apache/solr/client/solrj/impl/BaseCloudSolrClient.java#L526-L527
we have
```
...
String routeField = (routeFieldDeprecated != null) ? routeFieldDeprecated :
(col.getRouter().getRouteField(col) == null) ? ID :
col.getRouter().getRouteField(col);
...
```
i.e. yes in conjunction with the "the field is automatically determined from
Zookeeper" comment at
https://github.com/apache/lucene-solr/blob/releases/lucene-solr%2F8.7.0/solr/solrj/src/java/org/apache/solr/client/solrj/impl/BaseCloudSolrClient.java#L311
there is an "id" assumption of sorts, though in most use cases the field would
be automatically determined from ZooKeeper I guess?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-15171) Add redirects from old Solr site to new
[
https://issues.apache.org/jira/browse/SOLR-15171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-15171:
---
Description:
The lucene.apache.org website needs to have updated {{.htaccess}} rules to
redirect any and all {{lucene.apache.org/solr/*}} paths to
{{solr.apache.org/*}}.
Also the ATOM/RSS feed URLs should be redirected, so those that monitor
security news and releases will not have an interruption.
was:The lucene.apache.org website needs to have updated {{.htaccess}} rules
to redirect any and all {{lucene.apache.org/solr/\*}} paths to
{{solr.apache.org/\*}}.
> Add redirects from old Solr site to new
> ---
>
> Key: SOLR-15171
> URL: https://issues.apache.org/jira/browse/SOLR-15171
> Project: Solr
> Issue Type: Sub-task
>Reporter: Jan Høydahl
>Priority: Major
>
> The lucene.apache.org website needs to have updated {{.htaccess}} rules to
> redirect any and all {{lucene.apache.org/solr/*}} paths to
> {{solr.apache.org/*}}.
> Also the ATOM/RSS feed URLs should be redirected, so those that monitor
> security news and releases will not have an interruption.
--
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-15206) improve CoreContainer constructor javadocs
[ https://issues.apache.org/jira/browse/SOLR-15206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293720#comment-17293720 ] ASF subversion and git services commented on SOLR-15206: Commit d822a38a48b8cc1844baad2e1e20088e90603847 in lucene-solr's branch refs/heads/master from Christine Poerschke [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d822a38 ] SOLR-15206: improve CoreContainer constructor javadocs (#2443) > improve CoreContainer constructor javadocs > -- > > Key: SOLR-15206 > URL: https://issues.apache.org/jira/browse/SOLR-15206 > Project: Solr > Issue Type: Task >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > The actual signature and the signature mentioned in the javadocs has gotten > out of sync for at least one of the constructor variants. -- 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
[GitHub] [lucene-solr] cpoerschke merged pull request #2443: SOLR-15206: improve CoreContainer constructor javadocs
cpoerschke merged pull request #2443: URL: https://github.com/apache/lucene-solr/pull/2443 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15167) Move lucene-solr-operator repo
[ https://issues.apache.org/jira/browse/SOLR-15167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293715#comment-17293715 ] Jan Høydahl commented on SOLR-15167: Houston - Once this is moved and a new release done, perhaps it is time for a proper [ANNOUNCE] email to our lists as well as the global [annou...@apache.org|mailto:annou...@apache.org] list? We could already now announce the Software Grant as a NEWS post on Solr's (new) website. Question: Having a separate codebase and different release cadence, should the Solr Operator be listed as a subproject of Solr? See [https://projects.apache.org/committee.html?solr] > Move lucene-solr-operator repo > -- > > Key: SOLR-15167 > URL: https://issues.apache.org/jira/browse/SOLR-15167 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Houston Putman >Priority: Major > > The lucene-solr-operator repo will be (once again) moved, now to > "solr-operator". This must be ordered thorugh an INFRA ticker. > As this will once again break the URL for helm, that also needs an update in > relevant places. -- 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-15177) Handle RefGuide and JavaDoc on solr.apache.org site
[ https://issues.apache.org/jira/browse/SOLR-15177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293696#comment-17293696 ] Jan Høydahl commented on SOLR-15177: I made an attempt to adapt the rewrite rules for Solr in [https://github.com/apache/lucene-site/pull/47] assuming we can reuse the __root hack. > Handle RefGuide and JavaDoc on solr.apache.org site > --- > > Key: SOLR-15177 > URL: https://issues.apache.org/jira/browse/SOLR-15177 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Priority: Major > > Make sure we have a working solution for referencing both old and new (9.x) > ref-guides and javadoc. > * Shall we move solr-related content in svn and point everything to the new > site? > * Make sure .htaccess rules work for this -- 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
[GitHub] [lucene-site] janhoy opened a new pull request #47: SOLR-15177: Attempt to link to javadoc and refguide in htaccess
janhoy opened a new pull request #47: URL: https://github.com/apache/lucene-site/pull/47 Non-tested rewrite rule magic to link in refguide at https://solr.apache.org/guide/X_Y and javadoc at https://solr.apache.org/docs/X_Y_Z/ on the new Solr site https://issues.apache.org/jira/browse/SOLR-15177 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15177) Handle RefGuide and JavaDoc on solr.apache.org site
[ https://issues.apache.org/jira/browse/SOLR-15177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293690#comment-17293690 ] Jan Høydahl commented on SOLR-15177: Another question - what URLs would we like for the RefGuide and JavaDoc, now that we do not have the /solr/ prefix anymore? RefGuide: [https://solr.apache.org/guide/X_Y] ReleaseDoc: [https://solr.apache.org/docs/X_Y_Z/] (feels better than [https://solr.apache.org/8_8_1/|https://solr.apache.org/X_Y_Z/]) > Handle RefGuide and JavaDoc on solr.apache.org site > --- > > Key: SOLR-15177 > URL: https://issues.apache.org/jira/browse/SOLR-15177 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Priority: Major > > Make sure we have a working solution for referencing both old and new (9.x) > ref-guides and javadoc. > * Shall we move solr-related content in svn and point everything to the new > site? > * Make sure .htaccess rules work for this -- 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
[GitHub] [lucene-solr] epugh commented on pull request #2437: SOLR-15204: Document bin solr zk and zkcli
epugh commented on pull request #2437: URL: https://github.com/apache/lucene-solr/pull/2437#issuecomment-73428 I agree about `command-line-utilities.adoc` having the wrong name, so excited about that new name. I also agree that we'd like to eventually get rid of the ZK specific cli as well!Heck, I'd rather take the good parts of our `zkcli.sh` and migrate them to the main Zookeeper projects `zkcli.sh` if that made sense! So @ctargett if I roll back the changes to `command-line-utilities.adoc`, then does the other edits make sense to you? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-10189) Add a solr zk clusterprop command
[
https://issues.apache.org/jira/browse/SOLR-10189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Eric Pugh reassigned SOLR-10189:
--
Assignee: David Eric Pugh
> Add a solr zk clusterprop command
> -
>
> Key: SOLR-10189
> URL: https://issues.apache.org/jira/browse/SOLR-10189
> Project: Solr
> Issue Type: New Feature
> Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: David Eric Pugh
>Priority: Major
>
> The bin/solr script should support setting clusterprop. Proposal
> {code}
> solr zk clusterprop # lists all props
> solr zk clusterprop urlscheme # shows a single prop
> solr zk clusterprop urlscheme=https # sets a prop
> solr zk clusterprop urlscheme= # deletes a prop
> {code}
--
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
[GitHub] [lucene-solr] pawel-bugalski-dynatrace commented on a change in pull request #2429: LUCENE-9791 Allow calling BytesRefHash#find concurrently
pawel-bugalski-dynatrace commented on a change in pull request #2429:
URL: https://github.com/apache/lucene-solr/pull/2429#discussion_r585459927
##
File path: lucene/core/src/test/org/apache/lucene/util/TestBytesRefHash.java
##
@@ -267,6 +271,71 @@ public void testFind() throws Exception {
}
}
+ @Test
+ public void testConcurrentAccessToUnmodifiableBytesRefHash() throws
Exception {
+int num = atLeast(2);
+for (int j = 0; j < num; j++) {
+ int numStrings = 797;
+ List strings = new ArrayList<>(numStrings);
+ for (int i = 0; i < numStrings; i++) {
+final String str = TestUtil.randomRealisticUnicodeString(random(), 1,
1000);
+hash.add(new BytesRef(str));
+assertTrue(strings.add(str));
+ }
+ int hashSize = hash.size();
+
+ UnmodifiableBytesRefHash unmodifiableHash = new
UnmodifiableBytesRefHash(hash);
+
+ AtomicInteger notFound = new AtomicInteger();
+ AtomicInteger notEquals = new AtomicInteger();
+ AtomicInteger wrongSize = new AtomicInteger();
+ int numThreads = 10;
Review comment:
```suggestion
int numThreads = atLeast(3);
```
Sure. I've copy&pasted it from another test. I think atLeast(3) should be
fine. It's fast on smaller number of CPUs and grows to larger number of threads
when nightly tests are enabled. What you think?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14762) Fork the git repo into two new 'lucene' and 'solr'
[
https://issues.apache.org/jira/browse/SOLR-14762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293641#comment-17293641
]
Dawid Weiss commented on SOLR-14762:
{quote} We may need INFRA help to make the old master branch READ-ONLY though.
{quote}
Or we may just delete the contents and leave a README.txt file pointing at the
new locations. PRs shouldn't merge and if somebody really wants and commits
something there... well, we can just revert.
We'll see what works better.
> Fork the git repo into two new 'lucene' and 'solr'
> --
>
> Key: SOLR-14762
> URL: https://issues.apache.org/jira/browse/SOLR-14762
> Project: Solr
> Issue Type: Sub-task
>Reporter: Jan Høydahl
>Assignee: Dawid Weiss
>Priority: Major
>
> Existing git repo (and GitHub project) will be frozen and two new repos used
> # Announce on all lists a date when the lucene-solr git repo will be frozen
> This date should be e.g. 14 days in the future to allow in-flight commits
> and PRs to be pushed
> # At the freeze date, make a last commit adding a big announcement to
> README.md about the location of the new repositories, then make both asf-git
> and github R/O
> # Clone 'lucene-solr' into new 'lucene' and 'solr' git repos
> Then continue with separate LUCENE and SOLR jiras to prepare the new repos,
> builds etc
> 1. https://gitbox.apache.org/repos/asf/lucene.git
> 2. https://gitbox.apache.org/repos/asf/solr.git
--
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-14762) Fork the git repo into two new 'lucene' and 'solr'
[ https://issues.apache.org/jira/browse/SOLR-14762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293646#comment-17293646 ] Jan Høydahl commented on SOLR-14762: +1 PS: This is perhaps a case where we announce the change after-the-fact. If we give a heads-up we risk a bunch of half-baked PRs being merged prematurely to avoid the extra hoops of porting... Alternatively give a few days notice and urge committers to not rush things? > Fork the git repo into two new 'lucene' and 'solr' > -- > > Key: SOLR-14762 > URL: https://issues.apache.org/jira/browse/SOLR-14762 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Dawid Weiss >Priority: Major > > Existing git repo (and GitHub project) will be frozen and two new repos used > # Announce on all lists a date when the lucene-solr git repo will be frozen > This date should be e.g. 14 days in the future to allow in-flight commits > and PRs to be pushed > # At the freeze date, make a last commit adding a big announcement to > README.md about the location of the new repositories, then make both asf-git > and github R/O > # Clone 'lucene-solr' into new 'lucene' and 'solr' git repos > Then continue with separate LUCENE and SOLR jiras to prepare the new repos, > builds etc > 1. https://gitbox.apache.org/repos/asf/lucene.git > 2. https://gitbox.apache.org/repos/asf/solr.git -- 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-15207) Change Solr JIRA notifications to issues@solr
[ https://issues.apache.org/jira/browse/SOLR-15207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293602#comment-17293602 ] Jan Høydahl commented on SOLR-15207: INFRA-21494 > Change Solr JIRA notifications to issues@solr > - > > Key: SOLR-15207 > URL: https://issues.apache.org/jira/browse/SOLR-15207 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Solr uses the Lucene notification scheme at > [https://issues.apache.org/jira/plugins/servlet/project-config/SOLR/notifications] > - contact INFRA to change it to iss...@solr.apache.org -- 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
[GitHub] [lucene-solr] iverase opened a new pull request #2444: LUCENE-9705: Create Lucene90StoredFieldsFormat
iverase opened a new pull request #2444: URL: https://github.com/apache/lucene-solr/pull/2444 For now this is just a copy of Lucene90StoredFieldsFormat. The existing Lucene50StoredFieldsFormat is moved to backwards-codecs, along with its utility classes. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15177) Handle RefGuide and JavaDoc on solr.apache.org site
[
https://issues.apache.org/jira/browse/SOLR-15177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293642#comment-17293642
]
Jan Høydahl commented on SOLR-15177:
[~uschindler] is it so that the new Solr site can use the same RewriteRules in
order to display javadoc and RefGuide from
{{__root/docs.lucene.apache.org/content}} and that we do not need to {{svn mv}}
the content to some other location? I.e.:
{code:java}
# __root/docs.lucene.apache.org/content/ is a special alias added by
INFRA-19439, so we can refer to stuff in other places like SVN:
RewriteRule ^(core|solr)/\d+_\d+_\d+/.*$
__root/docs.lucene.apache.org/content/$0 [PT]
RewriteRule ^solr/guide/\d+_\d+/.*$
__root/docs.lucene.apache.org/content/$0 [PT]
{code}
Or would you prefer to move Solr guides and Javadoc to a
{{__root/docs.solr.apache.org/content}} area for consistency?
Perhaps start with the existing rules for the step 1 migration and then later
move content to a dedicated solr location and update RewriteRules - if not
SOLR-15186 proves a better way by then?
> Handle RefGuide and JavaDoc on solr.apache.org site
> ---
>
> Key: SOLR-15177
> URL: https://issues.apache.org/jira/browse/SOLR-15177
> Project: Solr
> Issue Type: Sub-task
>Reporter: Jan Høydahl
>Priority: Major
>
> Make sure we have a working solution for referencing both old and new (9.x)
> ref-guides and javadoc.
> * Shall we move solr-related content in svn and point everything to the new
> site?
> * Make sure .htaccess rules work for this
--
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-15190) Create a release repo for Solr
[ https://issues.apache.org/jira/browse/SOLR-15190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-15190: --- Description: I think this will be created as we do the first release, i.e. nothing explicit to do here until then? > Create a release repo for Solr > -- > > Key: SOLR-15190 > URL: https://issues.apache.org/jira/browse/SOLR-15190 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Priority: Major > > I think this will be created as we do the first release, i.e. nothing > explicit to do here until then? -- 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-14762) Fork the git repo into two new 'lucene' and 'solr'
[ https://issues.apache.org/jira/browse/SOLR-14762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293635#comment-17293635 ] Jan Høydahl commented on SOLR-14762: Exactly what I thought. As the two new repos are empty I believe you have the power to push the entrire tree there (since no force-push is needed). We may need INFRA help to make the old master branch READ-ONLY though. > Fork the git repo into two new 'lucene' and 'solr' > -- > > Key: SOLR-14762 > URL: https://issues.apache.org/jira/browse/SOLR-14762 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Dawid Weiss >Priority: Major > > Existing git repo (and GitHub project) will be frozen and two new repos used > # Announce on all lists a date when the lucene-solr git repo will be frozen > This date should be e.g. 14 days in the future to allow in-flight commits > and PRs to be pushed > # At the freeze date, make a last commit adding a big announcement to > README.md about the location of the new repositories, then make both asf-git > and github R/O > # Clone 'lucene-solr' into new 'lucene' and 'solr' git repos > Then continue with separate LUCENE and SOLR jiras to prepare the new repos, > builds etc > 1. https://gitbox.apache.org/repos/asf/lucene.git > 2. https://gitbox.apache.org/repos/asf/solr.git -- 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-15207) Change Solr JIRA notifications to issues@solr
Jan Høydahl created SOLR-15207: -- Summary: Change Solr JIRA notifications to issues@solr Key: SOLR-15207 URL: https://issues.apache.org/jira/browse/SOLR-15207 Project: Solr Issue Type: Sub-task Reporter: Jan Høydahl Assignee: Jan Høydahl Solr uses the Lucene notification scheme at [https://issues.apache.org/jira/plugins/servlet/project-config/SOLR/notifications] - contact INFRA to change it to iss...@solr.apache.org -- 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
[GitHub] [lucene-solr] dweiss commented on pull request #2342: LUCENE-9406: Add IndexWriterEventListener to track events in IndexWriter
dweiss commented on pull request #2342: URL: https://github.com/apache/lucene-solr/pull/2342#issuecomment-788739399 Looks good to me. I've merged this in, sorry for the delay. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14762) Fork the git repo into two new 'lucene' and 'solr'
[ https://issues.apache.org/jira/browse/SOLR-14762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated SOLR-14762: --- Description: Existing git repo (and GitHub project) will be frozen and two new repos used # Announce on all lists a date when the lucene-solr git repo will be frozen This date should be e.g. 14 days in the future to allow in-flight commits and PRs to be pushed # At the freeze date, make a last commit adding a big announcement to README.md about the location of the new repositories, then make both asf-git and github R/O # Clone 'lucene-solr' into new 'lucene' and 'solr' git repos Then continue with separate LUCENE and SOLR jiras to prepare the new repos, builds etc 1. https://gitbox.apache.org/repos/asf/lucene.git 2. https://gitbox.apache.org/repos/asf/solr.git was: Existing git repo (and GitHub project) will be frozen and two new repos used # Announce on all lists a date when the lucene-solr git repo will be frozen This date should be e.g. 14 days in the future to allow in-flight commits and PRs to be pushed # At the freeze date, make a last commit adding a big announcement to README.md about the location of the new repositories, then make both asf-git and github R/O # Clone 'lucene-solr' into new 'lucene' and 'solr' git repos Then continue with separate LUCENE and SOLR jiras to prepare the new repos, builds etc > Fork the git repo into two new 'lucene' and 'solr' > -- > > Key: SOLR-14762 > URL: https://issues.apache.org/jira/browse/SOLR-14762 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Dawid Weiss >Priority: Major > > Existing git repo (and GitHub project) will be frozen and two new repos used > # Announce on all lists a date when the lucene-solr git repo will be frozen > This date should be e.g. 14 days in the future to allow in-flight commits > and PRs to be pushed > # At the freeze date, make a last commit adding a big announcement to > README.md about the location of the new repositories, then make both asf-git > and github R/O > # Clone 'lucene-solr' into new 'lucene' and 'solr' git repos > Then continue with separate LUCENE and SOLR jiras to prepare the new repos, > builds etc > 1. https://gitbox.apache.org/repos/asf/lucene.git > 2. https://gitbox.apache.org/repos/asf/solr.git -- 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-14762) Fork the git repo into two new 'lucene' and 'solr'
[ https://issues.apache.org/jira/browse/SOLR-14762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293533#comment-17293533 ] Dawid Weiss commented on SOLR-14762: Hi Jan. I'm back, sorry for the delay. I'll try to clean up the master branch so that splitting into lucene/main and solr/main branches can proceed smoothly. solr/main will use the Lucene snapshot dependency from apache maven repositories. We can then push a mirror of the lucene-solr repository state to corresponding lucene and solr git repositories (don't know if we'll need infra assistance for this). Branch_8x development stays on lucene-solr, at least for the time being, correct? > Fork the git repo into two new 'lucene' and 'solr' > -- > > Key: SOLR-14762 > URL: https://issues.apache.org/jira/browse/SOLR-14762 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Dawid Weiss >Priority: Major > > Existing git repo (and GitHub project) will be frozen and two new repos used > # Announce on all lists a date when the lucene-solr git repo will be frozen > This date should be e.g. 14 days in the future to allow in-flight commits and > PRs to be pushed > # At the freeze date, make a last commit adding a big announcement to > README.md about the location of the new repositories, then make both asf-git > and github R/O > # Clone 'lucene-solr' into new 'lucene' and 'solr' git repos > Then continue with separate LUCENE and SOLR jiras to prepare the new repos, > builds etc -- 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
[GitHub] [lucene-solr] dweiss merged pull request #2342: LUCENE-9406: Add IndexWriterEventListener to track events in IndexWriter
dweiss merged pull request #2342: URL: https://github.com/apache/lucene-solr/pull/2342 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-14762) Fork the git repo into two new 'lucene' and 'solr'
[ https://issues.apache.org/jira/browse/SOLR-14762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss reassigned SOLR-14762: -- Assignee: Dawid Weiss > Fork the git repo into two new 'lucene' and 'solr' > -- > > Key: SOLR-14762 > URL: https://issues.apache.org/jira/browse/SOLR-14762 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Dawid Weiss >Priority: Major > > Existing git repo (and GitHub project) will be frozen and two new repos used > # Announce on all lists a date when the lucene-solr git repo will be frozen > This date should be e.g. 14 days in the future to allow in-flight commits and > PRs to be pushed > # At the freeze date, make a last commit adding a big announcement to > README.md about the location of the new repositories, then make both asf-git > and github R/O > # Clone 'lucene-solr' into new 'lucene' and 'solr' git repos > Then continue with separate LUCENE and SOLR jiras to prepare the new repos, > builds etc -- 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-9406) Make it simpler to track IndexWriter's events
[
https://issues.apache.org/jira/browse/LUCENE-9406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293515#comment-17293515
]
ASF subversion and git services commented on LUCENE-9406:
-
Commit 6ba9fe5be35dea3ff66d89f63bc876286f186ea4 in lucene-solr's branch
refs/heads/master from zacharymorn
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6ba9fe5b ]
LUCENE-9406: Add IndexWriterEventListener to track events in IndexWriter (#2342)
> Make it simpler to track IndexWriter's events
> -
>
> Key: LUCENE-9406
> URL: https://issues.apache.org/jira/browse/LUCENE-9406
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/index
>Reporter: Michael McCandless
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> This is the second spinoff from a [controversial PR to add a new index-time
> feature to Lucene to merge small segments during
> commit|https://github.com/apache/lucene-solr/pull/1552]. That change can
> substantially reduce the number of small index segments to search.
> In that PR, there was a new proposed interface, {{IndexWriterEvents}}, giving
> the application a chance to track when {{IndexWriter}} kicked off merges
> during commit, how many, how long it waited, how often it gave up waiting,
> etc.
> Such telemetry from production usage is really helpful when tuning settings
> like which merges (e.g. a size threshold) to attempt on commit, and how long
> to wait during commit, etc.
> I am splitting out this issue to explore possible approaches to do this.
> E.g. [~simonw] proposed using a statistics class instead, but if I understood
> that correctly, I think that would put the role of aggregation inside
> {{IndexWriter}}, which is not ideal.
> Many interesting events, e.g. how many merges are being requested, how large
> are they, how long did they take to complete or fail, etc., can be gleaned by
> wrapping expert Lucene classes like {{MergePolicy}} and {{MergeScheduler}}.
> But for those events that cannot (e.g. {{IndexWriter}} stopped waiting for
> merges during commit), it would be very helpful to have some simple way to
> track so applications can better tune.
> It is also possible to subclass {{IndexWriter}} and override key methods, but
> I think that is inherently risky as {{IndexWriter}}'s protected methods are
> not considered to be a stable API, and the synchronization used by
> {{IndexWriter}} is confusing.
--
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] (LUCENE-9406) Make it simpler to track IndexWriter's events
[
https://issues.apache.org/jira/browse/LUCENE-9406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss resolved LUCENE-9406.
-
Fix Version/s: master (9.0)
Resolution: Fixed
> Make it simpler to track IndexWriter's events
> -
>
> Key: LUCENE-9406
> URL: https://issues.apache.org/jira/browse/LUCENE-9406
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/index
>Reporter: Michael McCandless
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> This is the second spinoff from a [controversial PR to add a new index-time
> feature to Lucene to merge small segments during
> commit|https://github.com/apache/lucene-solr/pull/1552]. That change can
> substantially reduce the number of small index segments to search.
> In that PR, there was a new proposed interface, {{IndexWriterEvents}}, giving
> the application a chance to track when {{IndexWriter}} kicked off merges
> during commit, how many, how long it waited, how often it gave up waiting,
> etc.
> Such telemetry from production usage is really helpful when tuning settings
> like which merges (e.g. a size threshold) to attempt on commit, and how long
> to wait during commit, etc.
> I am splitting out this issue to explore possible approaches to do this.
> E.g. [~simonw] proposed using a statistics class instead, but if I understood
> that correctly, I think that would put the role of aggregation inside
> {{IndexWriter}}, which is not ideal.
> Many interesting events, e.g. how many merges are being requested, how large
> are they, how long did they take to complete or fail, etc., can be gleaned by
> wrapping expert Lucene classes like {{MergePolicy}} and {{MergeScheduler}}.
> But for those events that cannot (e.g. {{IndexWriter}} stopped waiting for
> merges during commit), it would be very helpful to have some simple way to
> track so applications can better tune.
> It is also possible to subclass {{IndexWriter}} and override key methods, but
> I think that is inherently risky as {{IndexWriter}}'s protected methods are
> not considered to be a stable API, and the synchronization used by
> {{IndexWriter}} is confusing.
--
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
[GitHub] [lucene-solr] janhoy commented on pull request #2437: SOLR-15204: Document bin solr zk and zkcli
janhoy commented on pull request #2437: URL: https://github.com/apache/lucene-solr/pull/2437#issuecomment-788732156 > Does this suggest that maybe having a `bin/solr zk clusterprop` would be good? Yes, that is the main missing command I believe. Feel free to hack away at https://issues.apache.org/jira/browse/SOLR-10189 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14499) New Solr TLP site
[ https://issues.apache.org/jira/browse/SOLR-14499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293498#comment-17293498 ] Jan Høydahl commented on SOLR-14499: I have updated the community page [https://lucene-solrtlp.staged.apache.org/community.html] to link to mail archives at lucene as well as making it clear that the codebase is currently at lucene but going to transition See commit [https://github.com/apache/lucene-site/commit/f4fcbafd98ed2f6db980299d35837fa8e481e0d0] > New Solr TLP site > - > > Key: SOLR-14499 > URL: https://issues.apache.org/jira/browse/SOLR-14499 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Attachments: Paletton-color-palette.html, code-hilite-after.png, > code-hilite-before.png, only-yellow.png, solr-has-moved-modal.png, > solr-new-site-screenshot.png, solr-security-and-news.png, > solr-site-green.png, solr-site-green.png, solr-site-yellow.png, > solr-site-yellow.png, stacked.png > > > # Get setup solr-site repo (start from lucene-site repo) > # Setup a temporary "work in progress" page on solr.apache.org > # Remove all lucene TLP, lucene-core and pylucene content, including > templates and css etc > # Move Solr index.html as main index file > # Simplify folder structure for Pelican > # Publish the new site -- 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
