[jira] [Commented] (LUCENE-9568) FuzzyTermEnums sets negative boost for fuzzy search & highlight
[
https://issues.apache.org/jira/browse/LUCENE-9568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17212887#comment-17212887
]
Adrien Grand commented on LUCENE-9568:
--
FWIW comments in TopTermsRewrite suggests that we used to allow negative
boosts:
https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.6.3/lucene/core/src/java/org/apache/lucene/search/TopTermsRewrite.java#L163-L165.
> FuzzyTermEnums sets negative boost for fuzzy search & highlight
> ---
>
> Key: LUCENE-9568
> URL: https://issues.apache.org/jira/browse/LUCENE-9568
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/highlighter
>Affects Versions: 8.5.1
>Reporter: Juraj Jurčo
>Priority: Minor
> Labels: highlighting, newbie
> Attachments: FindSqlHighlightTest.java
>
>
> *Description*
> When user indexes a word with an apostrophe and constructs a fuzzy query for
> highlighter, it throws an exception with set negative boost for a query.
> *Repro Steps*
> # Index a text with apostrophe. E.g. doesn't
> # Parse a fuzzy query e.g.: se~, se~2, se~3
> # Try to highlight a text with apostrophe
> # The exception is thrown (for details see attached test test with repro
> steps)
> *Actual Result*
> {{java.lang.IllegalArgumentException: boost must be a positive float, got
> -1.0}}
> *Expected Result*
> * No exception.
> * Highlighting marks are inserted into a text.
> *Workaround*
> - not known.
--
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-14926) Modernize and clean up document clustering contrib
Dawid Weiss created SOLR-14926: -- Summary: Modernize and clean up document clustering contrib Key: SOLR-14926 URL: https://issues.apache.org/jira/browse/SOLR-14926 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Dawid Weiss The clustering contrib was written a long time ago and it shows its age. We have two separate interfaces (for clustering search results and for clustering documents). The second one never received any attention and no implementation exists for it. I plan to do the following: - *remove* the document clustering interface entirely, leave only the post-search results clustering extension, - upgrade the implementation to Carrot2 4.x (this gets rid of those long-standing odd dependencies), - clean up the code where appropriate. My plan is to apply this to master, initially, but also backport to 8x if there are no objections. I don't think it'll hurt anybody. -- 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-13360) StringIndexOutOfBoundsException: String index out of range: -3
[
https://issues.apache.org/jira/browse/SOLR-13360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213003#comment-17213003
]
Deniz Coskun commented on SOLR-13360:
-
I also have the same issue. Solr Version 7.1 with index replication.
Query:
{code:java}
/suggest?q=dn110&spellcheck.q=dn110
{code}
Error-Response:
{code:java}
{
"responseHeader": {
"status": 500,
"QTime": 2
},
"error": {
"msg": "String index out of range: -3",
"trace": "java.lang.StringIndexOutOfBoundsException: String index out of
range: -3\n\tat
java.lang.AbstractStringBuilder.replace(AbstractStringBuilder.java:851)\n\tat
java.lang.StringBuilder.replace(StringBuilder.java:262)\n\tat
org.apache.solr.spelling.SpellCheckCollator.getCollation(SpellCheckCollator.java:252)\n\tat
org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:94)\n\tat
org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:297)\n\tat
org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:209)\n\tat
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)\n\tat
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)\n\tat
org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)\n\tat
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:720)\n\tat
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:526)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)\n\tat
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\n\tat
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
org.eclipse.jetty.server.Server.handle(Server.java:534)\n\tat
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)\n\tat
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)\n\tat
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)\n\tat
org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)\n\tat
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)\n\tat
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)\n\tat
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)\n\tat
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)\n\tat
java.lang.Thread.run(Thread.java:836)\n",
"code": 500
}
}{code}
solrconfig.xml:
{code:java}
text_spell
default
org.apache.solr.spelling.suggest.Suggester
org.apache.solr.spelling.suggest.tst.TSTLookup
autosuggest_de
true
true
0.35
...
true
default
true
5
true
suggest
{code}
There is a ManagedSynonymGraphFilterFactory for the field in schema.xml and it
replaces the term "dm110" with "dn 110". I didn't notice any errors in the
Analysis steps for this field (using Solr Dashboard).
> StringIndexOutOfBoundsException: String index out of range: -3
> --
>
> Key: SOLR-13360
> URL: https://issues.apache.org/jira/browse/SOLR-13360
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.2.1
> Environment: Solr 7.2.1 - SAP Hy
[jira] [Comment Edited] (SOLR-13360) StringIndexOutOfBoundsException: String index out of range: -3
[
https://issues.apache.org/jira/browse/SOLR-13360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213003#comment-17213003
]
Deniz Coskun edited comment on SOLR-13360 at 10/13/20, 9:35 AM:
I also have the same issue. Solr Version 7.1 with index replication.
Query:
{code:java}
/suggest?q=dn110&spellcheck.q=dn110
{code}
Error-Response:
{code:java}
{
"responseHeader": {
"status": 500,
"QTime": 2
},
"error": {
"msg": "String index out of range: -3",
"trace": "java.lang.StringIndexOutOfBoundsException: String index out of
range: -3\n\tat
java.lang.AbstractStringBuilder.replace(AbstractStringBuilder.java:851)\n\tat
java.lang.StringBuilder.replace(StringBuilder.java:262)\n\tat
org.apache.solr.spelling.SpellCheckCollator.getCollation(SpellCheckCollator.java:252)\n\tat
org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:94)\n\tat
org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:297)\n\tat
org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:209)\n\tat
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)\n\tat
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)\n\tat
org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)\n\tat
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:720)\n\tat
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:526)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)\n\tat
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\n\tat
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
org.eclipse.jetty.server.Server.handle(Server.java:534)\n\tat
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)\n\tat
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)\n\tat
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)\n\tat
org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)\n\tat
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)\n\tat
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)\n\tat
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)\n\tat
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)\n\tat
java.lang.Thread.run(Thread.java:836)\n",
"code": 500
}
}{code}
solrconfig.xml:
{code:java}
text_spell
default
org.apache.solr.spelling.suggest.Suggester
org.apache.solr.spelling.suggest.tst.TSTLookup
autosuggest_de
true
true
0.35
...
true
default
true
5
true
suggest
{code}
There is a ManagedSynonymGraphFilterFactory for the field in schema.xml and it
replaces the term "dm110" with "dn 110". I didn't notice any errors in the
Analysis steps for this field (using Solr Dashboard).
was (Author: deniz.coskun):
I also have the same issue. Solr Version 7.1 with index replication.
Query:
{code:java}
/suggest?q=dn110&spellcheck.q=dn110
{code}
Error-Response:
{code:java}
{
"responseHeader": {
"status": 500,
"QTime": 2
},
"error": {
"msg": "String index out of range: -3",
"
[jira] [Commented] (SOLR-14776) Precompute the fingerprint during PeerSync
[ https://issues.apache.org/jira/browse/SOLR-14776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213011#comment-17213011 ] ASF subversion and git services commented on SOLR-14776: Commit f0a9588e6402c81ae4c2e38e85ee8aedcc7848cb in lucene-solr's branch refs/heads/jira/SOLR-14776 from Shalin Shekhar Mangar [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f0a9588 ] SOLR-14776: Adding comment on how/why leader candidate's fingerprint is computed in parallel with other replicas > Precompute the fingerprint during PeerSync > -- > > Key: SOLR-14776 > URL: https://issues.apache.org/jira/browse/SOLR-14776 > Project: Solr > Issue Type: Improvement >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Computing fingerprint can very costly and take time. But the current > implementation will send requests for getting fingerprint for multiple > replicas, then on the first response it will then compute its own fingerprint > for comparison. A very simple but effective improvement here is compute its > own fingerprint right after send requests to other replicas. -- 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] cbuescher commented on pull request #1976: LUCENE-9578: TermRangeQuery empty string lower bound edge case
cbuescher commented on pull request #1976: URL: https://github.com/apache/lucene-solr/pull/1976#issuecomment-707624612 @jpountz thanks for the review, I added a commit that rejects the empty string when "includeMin == false" and added tests for that edge case as well. 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-14776) Precompute the fingerprint during PeerSync
[ https://issues.apache.org/jira/browse/SOLR-14776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-14776: Assignee: Shalin Shekhar Mangar (was: Cao Manh Dat) > Precompute the fingerprint during PeerSync > -- > > Key: SOLR-14776 > URL: https://issues.apache.org/jira/browse/SOLR-14776 > Project: Solr > Issue Type: Improvement >Reporter: Cao Manh Dat >Assignee: Shalin Shekhar Mangar >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Computing fingerprint can very costly and take time. But the current > implementation will send requests for getting fingerprint for multiple > replicas, then on the first response it will then compute its own fingerprint > for comparison. A very simple but effective improvement here is compute its > own fingerprint right after send requests to other replicas. -- 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-14776) Precompute the fingerprint during PeerSync
[ https://issues.apache.org/jira/browse/SOLR-14776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213015#comment-17213015 ] Shalin Shekhar Mangar commented on SOLR-14776: -- I have added a comment as Mike suggested. I'll commit this once tests pass locally. > Precompute the fingerprint during PeerSync > -- > > Key: SOLR-14776 > URL: https://issues.apache.org/jira/browse/SOLR-14776 > Project: Solr > Issue Type: Improvement >Reporter: Cao Manh Dat >Assignee: Shalin Shekhar Mangar >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Computing fingerprint can very costly and take time. But the current > implementation will send requests for getting fingerprint for multiple > replicas, then on the first response it will then compute its own fingerprint > for comparison. A very simple but effective improvement here is compute its > own fingerprint right after send requests to other replicas. -- 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-14776) Precompute the fingerprint during PeerSync
[ https://issues.apache.org/jira/browse/SOLR-14776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-14776: - Fix Version/s: 8.7 master (9.0) > Precompute the fingerprint during PeerSync > -- > > Key: SOLR-14776 > URL: https://issues.apache.org/jira/browse/SOLR-14776 > Project: Solr > Issue Type: Improvement >Reporter: Cao Manh Dat >Assignee: Shalin Shekhar Mangar >Priority: Major > Fix For: master (9.0), 8.7 > > Time Spent: 10m > Remaining Estimate: 0h > > Computing fingerprint can very costly and take time. But the current > implementation will send requests for getting fingerprint for multiple > replicas, then on the first response it will then compute its own fingerprint > for comparison. A very simple but effective improvement here is compute its > own fingerprint right after send requests to other replicas. -- 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-14927) Remove Overseer
Ilan Ginzburg created SOLR-14927: Summary: Remove Overseer Key: SOLR-14927 URL: https://issues.apache.org/jira/browse/SOLR-14927 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: SolrCloud Reporter: Ilan Ginzburg Assignee: Ilan Ginzburg This Jira is intended to capture sub jiras on the path to remove the Overseer component from SolrCloud and move to all nodes being able to do the work currently done by Overseer. See detailed description in [this doc|https://docs.google.com/document/d/1u4QHsIHuIxlglIW6hekYlXGNOP0HjLGVX5N6inkj6Ok/]. Copying (edited) from the above doc: The motivation for removing Overseer include: * Mono threaded state change is slow and doesn’t scale, * Communication between cluster nodes and the Overseer use Zookeeper as a queueing mechanism, this is not a good idea, * Nodes talking to Overseer (then Overseer talking to itself) via Zookeeper is inefficient and adds latency, * Collection API scalability is poor, because not only a single node processes commands for all Collections, but it also depends on the mono threaded state change queue consumption, * The code supporting Overseer in SolrCloud is complex (election, queue management, recovery etc). The general idea is that there’s already a central point in the SolrCloud cluster and it’s Zookeeper. It might not be necessary to have a second central point (Overseer) because nodes can interact directly with Zookeeper and synchronize more efficiently by optimistic locking using “conditional updates” (a.k.a compare and swap or CAS). -- 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-14928) Remove Overseer ClusterStateUpdater
Ilan Ginzburg created SOLR-14928:
Summary: Remove Overseer ClusterStateUpdater
Key: SOLR-14928
URL: https://issues.apache.org/jira/browse/SOLR-14928
Project: Solr
Issue Type: Sub-task
Security Level: Public (Default Security Level. Issues are Public)
Components: SolrCloud
Reporter: Ilan Ginzburg
Assignee: Ilan Ginzburg
Remove the Overseer {{ClusterStateUpdater}} thread and associated Zookeeper
queue at {{<_chroot_>/overseer/queue}}.
Change cluster state updates so that each (Collection API) command execution
does the update directly in Zookeeper using optimistic locking (Compare and
Swap on the {{state.json}} Zookeeper files).
Following this change cluster state updates would still be happening only from
the Overseer node (that's where Collection API commands are executing), but the
code will be ready for distribution once such commands can be executed by any
node (other work done in the context of parent task SOLR-14927).
See the [Cluster State
Updater|https://docs.google.com/document/d/1u4QHsIHuIxlglIW6hekYlXGNOP0HjLGVX5N6inkj6Ok/edit#heading=h.ymtfm3p518c]
section in the Removing Overseer doc.
--
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-14776) Precompute the fingerprint during PeerSync
[ https://issues.apache.org/jira/browse/SOLR-14776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213051#comment-17213051 ] ASF subversion and git services commented on SOLR-14776: Commit 8c554379aca6ab6c811eddd9e4428d598c2e7336 in lucene-solr's branch refs/heads/jira/SOLR-14776 from Shalin Shekhar Mangar [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8c55437 ] SOLR-14776: Adding entry to CHANGES.txt > Precompute the fingerprint during PeerSync > -- > > Key: SOLR-14776 > URL: https://issues.apache.org/jira/browse/SOLR-14776 > Project: Solr > Issue Type: Improvement >Reporter: Cao Manh Dat >Assignee: Shalin Shekhar Mangar >Priority: Major > Fix For: master (9.0), 8.7 > > Time Spent: 10m > Remaining Estimate: 0h > > Computing fingerprint can very costly and take time. But the current > implementation will send requests for getting fingerprint for multiple > replicas, then on the first response it will then compute its own fingerprint > for comparison. A very simple but effective improvement here is compute its > own fingerprint right after send requests to other replicas. -- 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-14917) Move DOMUtil and PropertiesUtil to SolrJ, o.a.s.common/util
[ https://issues.apache.org/jira/browse/SOLR-14917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213054#comment-17213054 ] ASF subversion and git services commented on SOLR-14917: Commit ab83b3b7c3786ce39718edc585c70dc12462add9 in lucene-solr's branch refs/heads/jira/SOLR-14776 from David Smiley [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ab83b3b ] SOLR-14917: Move DOMUtil and PropertiesUtil to SolrJ (#1953) > Move DOMUtil and PropertiesUtil to SolrJ, o.a.s.common/util > --- > > Key: SOLR-14917 > URL: https://issues.apache.org/jira/browse/SOLR-14917 > Project: Solr > Issue Type: Sub-task >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: master (9.0) > > Time Spent: 1h > Remaining Estimate: 0h > > DOMUtil has some XML DOM utilities, and PropertiesUtil has property > substitution utilities. They are fairly isolated and can easily move from > o.a.s.util in solr-core to o.a.s.common.util package in SolrJ. > The Moving of such things should be 9.x, but I suppose in 8.x a deprecated > subclass could be added in both of the former locations? -- 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-6831) Review LinkedList usage
[
https://issues.apache.org/jira/browse/LUCENE-6831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213055#comment-17213055
]
ASF subversion and git services commented on LUCENE-6831:
-
Commit 7362c4ce603d81f276a83070e51bda52c3528bd7 in lucene-solr's branch
refs/heads/jira/SOLR-14776 from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7362c4c ]
LUCENE-6831: start removing LinkedList in favor of ArrayList or De/Queues
(#1969)
I'm committing it in, seems like a trivial thing.
> Review LinkedList usage
> ---
>
> Key: LUCENE-6831
> URL: https://issues.apache.org/jira/browse/LUCENE-6831
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Dawid Weiss
>Priority: Trivial
> Fix For: 6.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I quickly scanned the code (out of curiosity) and most of the use cases of
> LinkedList are as a Queue, in which case indeed an ArrayDeque would be a
> better choice, especially if the maximum size is known in advance.
> There are also some invalid/ incorrect uses like calling size() on a linked
> list in {{MultiPhraseQueryNodeBuilder}}, which should be fixed.
--
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-14776) Precompute the fingerprint during PeerSync
[ https://issues.apache.org/jira/browse/SOLR-14776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213059#comment-17213059 ] ASF subversion and git services commented on SOLR-14776: Commit 33d1a6edcefd4bb1511fe79db6b114b996a55e8f in lucene-solr's branch refs/heads/jira/SOLR-14776 from Shalin Shekhar Mangar [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=33d1a6e ] Merge branch 'master' into jira/SOLR-14776 > Precompute the fingerprint during PeerSync > -- > > Key: SOLR-14776 > URL: https://issues.apache.org/jira/browse/SOLR-14776 > Project: Solr > Issue Type: Improvement >Reporter: Cao Manh Dat >Assignee: Shalin Shekhar Mangar >Priority: Major > Fix For: master (9.0), 8.7 > > Time Spent: 10m > Remaining Estimate: 0h > > Computing fingerprint can very costly and take time. But the current > implementation will send requests for getting fingerprint for multiple > replicas, then on the first response it will then compute its own fingerprint > for comparison. A very simple but effective improvement here is compute its > own fingerprint right after send requests to other replicas. -- 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-14922) Include solr-ref-guide tasks in sourceSets for IntelliJ
[ https://issues.apache.org/jira/browse/SOLR-14922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213057#comment-17213057 ] ASF subversion and git services commented on SOLR-14922: Commit e444df1435f3e24e6f09db47d9d369b3d4e85f12 in lucene-solr's branch refs/heads/jira/SOLR-14776 from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e444df1 ] SOLR-14922: Include solr-ref-guide tasks in sourceSets for IntelliJ (#1973) > Include solr-ref-guide tasks in sourceSets for IntelliJ > --- > > Key: SOLR-14922 > URL: https://issues.apache.org/jira/browse/SOLR-14922 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: master (9.0) > > Time Spent: 20m > Remaining Estimate: 0h > -- 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-14870) gradle build does not validate ref-guide -> javadoc links
[
https://issues.apache.org/jira/browse/SOLR-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213058#comment-17213058
]
ASF subversion and git services commented on SOLR-14870:
Commit b4f044219319fc0a0a94b92e2d90a6b25dae9de0 in lucene-solr's branch
refs/heads/jira/SOLR-14776 from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b4f0442 ]
SOLR-14870: refactor ref-guide build.gradle logic to re-enable guide->javadoc
link checking
fix 'broken' javadoc links in ref-guide to match new documentation path
structures for 9.x
> gradle build does not validate ref-guide -> javadoc links
> -
>
> Key: SOLR-14870
> URL: https://issues.apache.org/jira/browse/SOLR-14870
> Project: Solr
> Issue Type: Task
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-14870.patch, SOLR-14870.patch
>
>
> the ant build had (has on 8x) a feature that ensured we didn't have any
> broken links between the ref guide and the javadocs...
> {code}
> depends="javadocs,changes-to-html,process-webpages">
> inheritall="false">
>
>
>
>
> {code}
> ...by default {{cd solr/solr-ref-guide && ant bare-bones-html-validation}}
> just did interanal validation of the strucure of the guide, but this hook
> ment that {{cd solr && ant documentation}} (or {{ant precommit}}) would first
> build the javadocs; then build the ref-guide; then validate _all_ links i
> nthe ref-guide, even those to (local) javadocs
> While the "local.javadocs" property logic _inside_ the
> solr-ref-guide/build.xml was ported to build.gradle, the logic to leverage
> this functionality from the "solr" project doesn't seem to have been
> preserved -- so currently, {{gradle check}} doesn't know/care if someone adds
> a nonsense javadoc link to the ref-guide (or removes a class/method whose
> javadoc is already currently to from the ref guide)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9434) Update release step to remove creating a wiki page for every Solr release
[ https://issues.apache.org/jira/browse/LUCENE-9434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213053#comment-17213053 ] ASF subversion and git services commented on LUCENE-9434: - Commit 80df6a3d62cfacf6144f17a04447cf7707de6de1 in lucene-solr's branch refs/heads/jira/SOLR-14776 from Jason Gerlowski [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=80df6a3 ] LUCENE-9434: Remove wiki-update step from release > Update release step to remove creating a wiki page for every Solr release > - > > Key: LUCENE-9434 > URL: https://issues.apache.org/jira/browse/LUCENE-9434 > Project: Lucene - Core > Issue Type: Improvement > Components: general/website >Reporter: Cassandra Targett >Assignee: Jason Gerlowski >Priority: Major > Fix For: master (9.0), 8.7 > > Attachments: LUCENE-9434.patch > > > The release TODO asks RMs to create a Wiki page in Confluence for each Solr > release > (https://cwiki.apache.org/confluence/display/LUCENE/ReleaseTodo#ReleaseTodo-UpdateWIKI). > This page is often simply the date the release went out, and a link to the > release announcement (like this: > https://cwiki.apache.org/confluence/display/SOLR/Solr8.6) and an empty Errata > section I would guess never gets filled out. > Many more details for a release are provided in the Release Notes page that's > created and also in the Solr Ref Guide's upgrade notes page. While I'm sure > this other page served a purpose at one time, it seems pointless today to > keep creating it. > I propose we remove it from the wiki's ReleaseTODO and also from the Release > Wizard. I'll take a stab at making a patch to remove it from the wizard. -- 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-9562) Unify 'analysis' package with produced artifact names
[
https://issues.apache.org/jira/browse/LUCENE-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213056#comment-17213056
]
ASF subversion and git services commented on LUCENE-9562:
-
Commit c5cf13259e36582270042c46c9106138aadcb1d0 in lucene-solr's branch
refs/heads/jira/SOLR-14776 from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c5cf132 ]
LUCENE-9562: All binary analysis packages (and corresponding Maven artifacts)
with names containing '-analyzers-' have been renamed to '-analysis-'. (#1968)
> Unify 'analysis' package with produced artifact names
> -
>
> Key: LUCENE-9562
> URL: https://issues.apache.org/jira/browse/LUCENE-9562
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: master (9.0)
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Lucene has 'analysis' module but its sub-modules produce 'lucene-analyzers-*'
> artifacts. This inconsistency is currently handled by setting artifact names
> manually:
> {code}
> configure(subprojects.findAll { it.path.contains(':lucene:analysis:') }) {
> project.archivesBaseName = project.archivesBaseName.replace("-analysis-",
> "-analyzers-")
> }
> {code}
> but I keep wondering if we should just make it one or the other - either
> rename 'analysis' to 'analyzers' or produce 'lucene-analysis-' artifacts.
> My personal opinion is to produce 'lucene-analysis-' packages because this
> keeps repository structure the same (backports will be easier) and we're
> targeting a major release anyway so people can adjust dependency names when
> upgrading. This change would be also consistent with package naming inside
> those modules.
--
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-14776) Precompute the fingerprint during PeerSync
[ https://issues.apache.org/jira/browse/SOLR-14776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213060#comment-17213060 ] ASF subversion and git services commented on SOLR-14776: Commit 9594ab3ac01c3449fde8163d44c9c27261585c9f in lucene-solr's branch refs/heads/master from Cao Manh Dat [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9594ab3 ] SOLR-14776: Precompute the fingerprint during PeerSync (#1814) After heavy indexing, the call to compute fingerprint takes awhile and slows the leader election. This commit computes the fingerprint in parallel with fetching the fingerprint from the other replicas. Co-authored-by: Shalin Shekhar Mangar > Precompute the fingerprint during PeerSync > -- > > Key: SOLR-14776 > URL: https://issues.apache.org/jira/browse/SOLR-14776 > Project: Solr > Issue Type: Improvement >Reporter: Cao Manh Dat >Assignee: Shalin Shekhar Mangar >Priority: Major > Fix For: master (9.0), 8.7 > > Time Spent: 10m > Remaining Estimate: 0h > > Computing fingerprint can very costly and take time. But the current > implementation will send requests for getting fingerprint for multiple > replicas, then on the first response it will then compute its own fingerprint > for comparison. A very simple but effective improvement here is compute its > own fingerprint right after send requests to other replicas. -- 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] shalinmangar merged pull request #1814: SOLR-14776: Precompute the fingerprint during PeerSync
shalinmangar merged pull request #1814: URL: https://github.com/apache/lucene-solr/pull/1814 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] jpountz commented on pull request #1912: LUCENE-9535: Try to do larger flushes.
jpountz commented on pull request #1912: URL: https://github.com/apache/lucene-solr/pull/1912#issuecomment-707678374 I ran the benchmark I mentioned above: - wikimediumall - no body field, only `title` indexed as a keyword and doc-value fields to make the indexing chain cheaper - 18 indexing threads - 3 merge threads | Branch | Indexing time (s) | Number of flushes | | - | - | -- | | master | 134 | 48 | | master | 125 | 48 | | master | 154 | 47 | | master | 139 | 47 | | patch | 139 | 36 | | patch | 123 | 39 | | patch | 141 | 38 | | patch | 142 | 36 | Indexing times are a bit noisy so it's tricky to say whether it makes things faster or slower, but the total number of flushes is consistently smaller. 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-14924) Some ReplicationHandler metrics are reported using incorrect types
[
https://issues.apache.org/jira/browse/SOLR-14924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213071#comment-17213071
]
Andrzej Bialecki commented on SOLR-14924:
-
It turns out that there were also other properties in the {{fetcher}} section
that were misrepresented in the metrics output or skipped due to a type
mismatch. The attached patch unifies the outputs of
{{/replication?command=details}} and {{REPLICATION}} metrics, with the metrics
result now looking like this:
{code}
"REPLICATION./replication.fetcher": {
"leaderUrl":
"http://localhost:8983/solr/gettingstarted_shard1_replica_n2/";,
"isPollingDisabled": false,
"isReplicating": false,
"indexReplicatedAt": "Tue Oct 13 11:24:39 UTC 2020",
"indexReplicatedAtList": [
"Tue Oct 13 11:24:39 UTC 2020"
],
"timesIndexReplicated": 1,
"lastCycleBytesDownloaded": 18373,
"previousCycleTimeInSeconds": 0
},
{code}
(Previously the numeric values in this section were represented as strings, and
list values were missing).
> Some ReplicationHandler metrics are reported using incorrect types
> --
>
> Key: SOLR-14924
> URL: https://issues.apache.org/jira/browse/SOLR-14924
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
>Affects Versions: 8.7, 8.6.3
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
>
> Some metrics reported from {{ReplicationHandler}} use incorrect types - they
> are reported as String values instead of the numerics.
> This is caused by using {{ReplicationHandler.addVal}} utility method with the
> type {{Integer.class}}, which the method doesn't support and it returns the
> value as a string.
--
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-14924) Some ReplicationHandler metrics are reported using incorrect types
[
https://issues.apache.org/jira/browse/SOLR-14924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki updated SOLR-14924:
Attachment: SOLR-14924.patch
> Some ReplicationHandler metrics are reported using incorrect types
> --
>
> Key: SOLR-14924
> URL: https://issues.apache.org/jira/browse/SOLR-14924
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
>Affects Versions: 8.7, 8.6.3
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: SOLR-14924.patch
>
>
> Some metrics reported from {{ReplicationHandler}} use incorrect types - they
> are reported as String values instead of the numerics.
> This is caused by using {{ReplicationHandler.addVal}} utility method with the
> type {{Integer.class}}, which the method doesn't support and it returns the
> value as a string.
--
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-14924) Some ReplicationHandler metrics are reported using incorrect types
[
https://issues.apache.org/jira/browse/SOLR-14924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki updated SOLR-14924:
Fix Version/s: 8.7
> Some ReplicationHandler metrics are reported using incorrect types
> --
>
> Key: SOLR-14924
> URL: https://issues.apache.org/jira/browse/SOLR-14924
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
>Affects Versions: 8.7, 8.6.3
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.7
>
> Attachments: SOLR-14924.patch
>
>
> Some metrics reported from {{ReplicationHandler}} use incorrect types - they
> are reported as String values instead of the numerics.
> This is caused by using {{ReplicationHandler.addVal}} utility method with the
> type {{Integer.class}}, which the method doesn't support and it returns the
> value as a string.
--
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-14776) Precompute the fingerprint during PeerSync
[ https://issues.apache.org/jira/browse/SOLR-14776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213082#comment-17213082 ] ASF subversion and git services commented on SOLR-14776: Commit 0f2e389c1346edaed76987cf73c53218110863bc in lucene-solr's branch refs/heads/branch_8x from Cao Manh Dat [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0f2e389 ] SOLR-14776: Precompute the fingerprint during PeerSync (#1814) After heavy indexing, the call to compute fingerprint takes awhile and slows the leader election. This commit computes the fingerprint in parallel with fetching the fingerprint from the other replicas. Co-authored-by: Shalin Shekhar Mangar (cherry picked from commit 9594ab3ac01c3449fde8163d44c9c27261585c9f) > Precompute the fingerprint during PeerSync > -- > > Key: SOLR-14776 > URL: https://issues.apache.org/jira/browse/SOLR-14776 > Project: Solr > Issue Type: Improvement >Reporter: Cao Manh Dat >Assignee: Shalin Shekhar Mangar >Priority: Major > Fix For: master (9.0), 8.7 > > Time Spent: 20m > Remaining Estimate: 0h > > Computing fingerprint can very costly and take time. But the current > implementation will send requests for getting fingerprint for multiple > replicas, then on the first response it will then compute its own fingerprint > for comparison. A very simple but effective improvement here is compute its > own fingerprint right after send requests to other replicas. -- 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-14776) Precompute the fingerprint during PeerSync
[ https://issues.apache.org/jira/browse/SOLR-14776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-14776. -- Resolution: Fixed Thanks Dat for the fix and Mike for the reviews! > Precompute the fingerprint during PeerSync > -- > > Key: SOLR-14776 > URL: https://issues.apache.org/jira/browse/SOLR-14776 > Project: Solr > Issue Type: Improvement >Reporter: Cao Manh Dat >Assignee: Shalin Shekhar Mangar >Priority: Major > Fix For: master (9.0), 8.7 > > Time Spent: 20m > Remaining Estimate: 0h > > Computing fingerprint can very costly and take time. But the current > implementation will send requests for getting fingerprint for multiple > replicas, then on the first response it will then compute its own fingerprint > for comparison. A very simple but effective improvement here is compute its > own fingerprint right after send requests to other replicas. -- 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-14282) /get handler doesn't return copied fields
[
https://issues.apache.org/jira/browse/SOLR-14282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213087#comment-17213087
]
Erick Erickson commented on SOLR-14282:
---
[~ami...@intellective.com] If you use IntelliJ, just pull the source with git
and "open or import" from IntelliJ to the place you cloned the repo.
>From there, you should be able to just find the test file named, creatively,
>"TestRealTimeGet" and just execute it from within IntelliJ via the context
>menu. That'll get you started. From there I'd add a test in TestRealTimeGet
>that illustrated the error and go from there.
Eclipse has equivalent functionality, but I'm not as familiar with that.
There are a bunch of other tricks for various scenarios, but one step at a time
;)
There's some additional help here:
https://cwiki.apache.org/confluence/display/solr/HowToContribute
> /get handler doesn't return copied fields
> -
>
> Key: SOLR-14282
> URL: https://issues.apache.org/jira/browse/SOLR-14282
> Project: Solr
> Issue Type: Bug
> Components: search, SolrJ
>Affects Versions: 8.4
> Environment: SOLR 8.4.0, SOLRJ, Oracle Java 8
>Reporter: Andrei Minin
>Priority: Major
> Attachments: copied_fields_test.zip, managed-schema.xml
>
>
> We are using /get handler to retrieve documents by id in our Java application
> (SolrJ)
> I found that copied fields are missing in documents returned by /get handler
> but same documents returned by query contain copied (by schema) fields.
> Attached documents:
> # Integration test project archive
> # Managed schema file for SOLR
> SOLR schema details:
> # Unique field name "d_ida_s"
> # Lowecase text type definition:
> {code:java}
> positionIncrementGap="100">
>
>
>
>
> {code}
> 3. Copy field instruction sample:
> {code:java}
> stored="true" multiValued="false"/>
> />
> {code}
> ConcurrenceUserNamea_s is string type field and ConcurrenceUserNameu_lca_s is
> lower case text type field.
> Integration test uploads document to SOLR server and makes 2 requests: one
> using /get rest point to fetch document by id and one using query field name>:.
> Document returned by /get rest, doesn't have copied fields while document
> returned by query, contains copied fields.
--
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-14923) Indexing performance is unacceptable when child documents are involved
[ https://issues.apache.org/jira/browse/SOLR-14923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213093#comment-17213093 ] David Smiley commented on SOLR-14923: - I am responsible for this bug, along with [~moshebla], the contributor of SOLR-12638. Perhaps the single most bit of code I've regretted committing on behalf of another are the few lines of code you have found Thomas. I expressed my reservations at the time: https://issues.apache.org/jira/browse/SOLR-12638?focusedCommentId=16872898&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16872898 bq. What gnaws at me is that this "UpdateLog.openRealtimeSearcher" is being called optimistically on a new doc because mbeee some future atomic update will need to see it. And not just any type of atomic update; one that is directly to a nested child doc (something I consider highly experimental). It's as if we're optimizing for making that future atomic update faster by doing work in advance that will, I think, very rarely actually be used. It's a tragedy, if I'm understanding this right. There's a bit of conversation before in the issue about it as well. It's difficult for me to say at the moment what the fix is because that's fairly complex low-level Solr code that I think few people understand well. Nonetheless I'll look into it further this week. > Indexing performance is unacceptable when child documents are involved > -- > > Key: SOLR-14923 > URL: https://issues.apache.org/jira/browse/SOLR-14923 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: update, UpdateRequestProcessors >Affects Versions: master (9.0), 8.3, 8.4, 8.5, 8.6 >Reporter: Thomas Wöckinger >Priority: Critical > Labels: performance > > Parallel indexing does not make sense at moment when child documents are used. > The org.apache.solr.update.processor.DistributedUpdateProcessor checks at the > end of the method doVersionAdd if Ulog caches should be refreshed. > This check will return true if any child document is included in the > AddUpdateCommand. > If so ulog.openRealtimeSearcher(); is called, this call is very expensive, > and executed in a synchronized block of the UpdateLog instance, therefore all > other operations on the UpdateLog are blocked too. > Because every important UpdateLog method (add, delete, ...) is done using a > synchronized block almost each operation is blocked. > This reduces multi threaded index update to a single thread behavior. > The described behavior is not depending on any option of the UpdateRequest, > so it does not make any difference if 'waitFlush', 'waitSearcher' or > 'softCommit' is true or false. > The described behavior makes the usage of ChildDocuments useless, because the > performance is unacceptable. > > -- 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-14923) Indexing performance is unacceptable when child documents are involved
[
https://issues.apache.org/jira/browse/SOLR-14923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213094#comment-17213094
]
Thomas Wöckinger commented on SOLR-14923:
-
Nearly the same results when moving (line 688 to 694)
RefCounted holder = uhandler.core.openNewSearcher(true,
true);
out of the synchronized block, so a performance boost of factor 26 at least!
I don't know how is responsible for this part of code.
The final implementation of the method would be:
{code:java}
//
public void openRealtimeSearcher() {
try {
RefCounted holder =
uhandler.core.openNewSearcher(true, true);
holder.decref();
} catch (Exception e) {
SolrException.log(log, "Error opening realtime searcher", e);
return;
}
synchronized (this) {
// We must cause a new IndexReader to be opened before anything looks at
these caches again
// so that a cache miss will read fresh data. if (map != null)
map.clear();
if (prevMap != null) prevMap.clear();
if (prevMap2 != null) prevMap2.clear();
}
}
{code}
Side effects are open for discussion, may [~erickerickson] , [~dsmiley] ,
[~noble.paul] or [~ab] have some input on this change
> Indexing performance is unacceptable when child documents are involved
> --
>
> Key: SOLR-14923
> URL: https://issues.apache.org/jira/browse/SOLR-14923
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update, UpdateRequestProcessors
>Affects Versions: master (9.0), 8.3, 8.4, 8.5, 8.6
>Reporter: Thomas Wöckinger
>Priority: Critical
> Labels: performance
>
> Parallel indexing does not make sense at moment when child documents are used.
> The org.apache.solr.update.processor.DistributedUpdateProcessor checks at the
> end of the method doVersionAdd if Ulog caches should be refreshed.
> This check will return true if any child document is included in the
> AddUpdateCommand.
> If so ulog.openRealtimeSearcher(); is called, this call is very expensive,
> and executed in a synchronized block of the UpdateLog instance, therefore all
> other operations on the UpdateLog are blocked too.
> Because every important UpdateLog method (add, delete, ...) is done using a
> synchronized block almost each operation is blocked.
> This reduces multi threaded index update to a single thread behavior.
> The described behavior is not depending on any option of the UpdateRequest,
> so it does not make any difference if 'waitFlush', 'waitSearcher' or
> 'softCommit' is true or false.
> The described behavior makes the usage of ChildDocuments useless, because the
> performance is unacceptable.
>
>
--
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] [Moved] (SOLR-14929) Clean up Solr dependencies to use transitives and explicit exclusions
[
https://issues.apache.org/jira/browse/SOLR-14929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley moved LUCENE-9140 to SOLR-14929:
-
Key: SOLR-14929 (was: LUCENE-9140)
Lucene Fields: (was: New)
Issue Type: Task (was: Bug)
Project: Solr (was: Lucene - Core)
> Clean up Solr dependencies to use transitives and explicit exclusions
> -
>
> Key: SOLR-14929
> URL: https://issues.apache.org/jira/browse/SOLR-14929
> Project: Solr
> Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: David Smiley
>Priority: Critical
>
> Many Solr dependencies in gradle are currently explicitly expanded into a
> flat structure with { transitive = false }, reflecting ivy/ant build.
> We should explicitly depend on what's really needed, allow for transitive
> dependencies and exclude what's not required. This will make the dependency
> graph clearer. We still have the warning check for creeping transitive
> dependencies in the form of versions lock file and jar checksums.
> A side effect would also be to figure out which scope dependencies belong to
> (api level or internal).
--
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-14861) CoreContainer shutdown needs to be aware of other ongoing operations and wait until they're complete
[ https://issues.apache.org/jira/browse/SOLR-14861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213118#comment-17213118 ] Gus Heck commented on SOLR-14861: - Why aren't we viewing the problem as reload (etc) returns before it has ACTUALLY completed? How can the test be proceeding to shutdown if we aren't lying to it about the completion of reload? (assuming the test isn't making it's own threads and failing to track when they complete) A call to any admin level operation (from Java, SolrJ or the admin API) really should not complete until the command is complete, and the definition of complete should be the target resource is 100% ready to use (see also: create collection) Tests should never need any waiting strategies unless they themselves have started their own threads. (Credit: Above, I'm parroting a rehashed form of something Mark Miller said ages ago, at least as I recall it) If we *need* to track what's in-flight on shutdown, we've failed in the event of a power loss, so we shouldn't be doing that (Where need defined as "otherwise persisted state will be corrupted", anything else is "want"). If we want a graceful "drain existing requests" process we should build that explicitly by tracking all requests at a high level (we do this with SolrRequestInfo partly already, plus need to account for async)... Of course that only works if we don't lie about request completion in the first place. Once we can perform a "start rejecting and drain" (that doesn't lie about when it completes) we can paste request draining on the front of shutdown and reload fairly trivially. > CoreContainer shutdown needs to be aware of other ongoing operations and wait > until they're complete > > > Key: SOLR-14861 > URL: https://issues.apache.org/jira/browse/SOLR-14861 > Project: Solr > Issue Type: Bug >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-14861.patch > > > Noble and I are trying to get to the bottom of the TestBulkSchemaConcurrent > failures and found what looks like a glaring gap in how > CoreContainer.shutdown operates. I don't know the impact on production since > we're shutting down anyway, but I think this is responsible for the errors in > TestBulkSchemaConcurrent and likely behind others, especially any other test > that fails intermittently that involves core reloads, including and > especially any tests that exercise managed schema. > We have clear evidence of this sequence: > 1> some CoreContainer.reloads come in and get _partway_ through, in > particular past the test at the top where CoreContainer.reload() throws an > AlreadyClosed exception if (isShutdown). > 2> Some CoreContainer.shutdown() threads get some processing time before the > reloads in <1> are finished. > 3> the threads in <1> pick back up and go wonky. I suspect that there are a > number of different things that could be going wrong here depending on how > far through CoreContainer.shutdown() gets that pop out in different ways. > Since it's my shift (Noble has to sleep sometime), I put some crude locking > in just to test the idea; incrementing an AtomicInteger on entry to > CoreContainer.reload then decrementing it at the end, and spinning in > CoreContainer.shutdown() until the AtomicInteger was back to zero. With that > in place, 100 runs and no errors whereas before I could never get even 10 > runs to finish without an error. This is not a proper fix at all, and the way > it's currently running there are still possible race conditions, just much > smaller windows. And I suspect it risks spinning forever. But it's enough to > make me believe I finally understand what's happening. > I also suspect that reload is more sensitive than most operations on a core > due to the fact that it runs for a long time, but I assume other operations > have the same potential. Shouldn't CoreContainer.shutDown() wait until no > other operations are in flight? > On a quick scan of CoreContainer, there are actually few places where we even > check for isShutdown, I suspect the places we do are ad-hoc that we've found > by trial-and-error when tests fail. We need a design rather than hit-or-miss > hacking. > I think that isShutdown should be replaced with something more robust. What > that is IDK quite yet because I've been hammering at this long enough and I > need a break. > This is consistent with another observation about this particular test. If > there's sleep at the end, it wouldn't fail; all the reloads get a chance to > finish before anything was shut down. > An open question how much this matters to production systems. In the testing > case, bunches of these reloads are issued the
[jira] [Comment Edited] (SOLR-14861) CoreContainer shutdown needs to be aware of other ongoing operations and wait until they're complete
[ https://issues.apache.org/jira/browse/SOLR-14861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213118#comment-17213118 ] Gus Heck edited comment on SOLR-14861 at 10/13/20, 1:33 PM: Why aren't we viewing the problem as reload (etc) returns before it has ACTUALLY completed? How can the test be proceeding to shutdown if we aren't lying to it about the completion of reload? (assuming the test isn't making it's own threads and failing to track when they complete) A call to any admin level operation (from Java, SolrJ or the admin API) really should not complete until the command is complete, and the definition of complete should be the target resource is 100% ready to use (see also: create collection) Tests should never need any waiting strategies unless they themselves have started their own threads. (Credit: Above, I'm parroting a rehashed form of something Mark Miller said ages ago, at least as I recall it) If we *need* to track what's in-flight on shutdown, we've failed in the event of a power loss, so we shouldn't be doing that (Where need defined as "otherwise persisted state will be corrupted", anything else is "want"). If we want a graceful "drain existing requests" process we should build that explicitly by tracking all requests at a high level (we do this with SolrRequestInfo partly already, plus need to account for async)... Of course that only works if we don't lie about request completion in the first place. Once we can perform a "start rejecting and drain" (that doesn't lie about when it completes) we can paste request draining on the front of shutdown and reload fairly trivially as an option. was (Author: gus_heck): Why aren't we viewing the problem as reload (etc) returns before it has ACTUALLY completed? How can the test be proceeding to shutdown if we aren't lying to it about the completion of reload? (assuming the test isn't making it's own threads and failing to track when they complete) A call to any admin level operation (from Java, SolrJ or the admin API) really should not complete until the command is complete, and the definition of complete should be the target resource is 100% ready to use (see also: create collection) Tests should never need any waiting strategies unless they themselves have started their own threads. (Credit: Above, I'm parroting a rehashed form of something Mark Miller said ages ago, at least as I recall it) If we *need* to track what's in-flight on shutdown, we've failed in the event of a power loss, so we shouldn't be doing that (Where need defined as "otherwise persisted state will be corrupted", anything else is "want"). If we want a graceful "drain existing requests" process we should build that explicitly by tracking all requests at a high level (we do this with SolrRequestInfo partly already, plus need to account for async)... Of course that only works if we don't lie about request completion in the first place. Once we can perform a "start rejecting and drain" (that doesn't lie about when it completes) we can paste request draining on the front of shutdown and reload fairly trivially. > CoreContainer shutdown needs to be aware of other ongoing operations and wait > until they're complete > > > Key: SOLR-14861 > URL: https://issues.apache.org/jira/browse/SOLR-14861 > Project: Solr > Issue Type: Bug >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-14861.patch > > > Noble and I are trying to get to the bottom of the TestBulkSchemaConcurrent > failures and found what looks like a glaring gap in how > CoreContainer.shutdown operates. I don't know the impact on production since > we're shutting down anyway, but I think this is responsible for the errors in > TestBulkSchemaConcurrent and likely behind others, especially any other test > that fails intermittently that involves core reloads, including and > especially any tests that exercise managed schema. > We have clear evidence of this sequence: > 1> some CoreContainer.reloads come in and get _partway_ through, in > particular past the test at the top where CoreContainer.reload() throws an > AlreadyClosed exception if (isShutdown). > 2> Some CoreContainer.shutdown() threads get some processing time before the > reloads in <1> are finished. > 3> the threads in <1> pick back up and go wonky. I suspect that there are a > number of different things that could be going wrong here depending on how > far through CoreContainer.shutdown() gets that pop out in different ways. > Since it's my shift (Noble has to sleep sometime), I put some crude locking > in just to test the idea; incrementing an AtomicInteger on entry to
[jira] [Updated] (SOLR-14282) /get handler doesn't return copied fields
[
https://issues.apache.org/jira/browse/SOLR-14282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Minin updated SOLR-14282:
Attachment: SOLR-14282-test-update.patch
> /get handler doesn't return copied fields
> -
>
> Key: SOLR-14282
> URL: https://issues.apache.org/jira/browse/SOLR-14282
> Project: Solr
> Issue Type: Bug
> Components: search, SolrJ
>Affects Versions: 8.4
> Environment: SOLR 8.4.0, SOLRJ, Oracle Java 8
>Reporter: Andrei Minin
>Priority: Major
> Attachments: SOLR-14282-test-update.patch, copied_fields_test.zip,
> managed-schema.xml
>
>
> We are using /get handler to retrieve documents by id in our Java application
> (SolrJ)
> I found that copied fields are missing in documents returned by /get handler
> but same documents returned by query contain copied (by schema) fields.
> Attached documents:
> # Integration test project archive
> # Managed schema file for SOLR
> SOLR schema details:
> # Unique field name "d_ida_s"
> # Lowecase text type definition:
> {code:java}
> positionIncrementGap="100">
>
>
>
>
> {code}
> 3. Copy field instruction sample:
> {code:java}
> stored="true" multiValued="false"/>
> />
> {code}
> ConcurrenceUserNamea_s is string type field and ConcurrenceUserNameu_lca_s is
> lower case text type field.
> Integration test uploads document to SOLR server and makes 2 requests: one
> using /get rest point to fetch document by id and one using query field name>:.
> Document returned by /get rest, doesn't have copied fields while document
> returned by query, contains copied fields.
--
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-14282) /get handler doesn't return copied fields
[
https://issues.apache.org/jira/browse/SOLR-14282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213167#comment-17213167
]
Andrei Minin commented on SOLR-14282:
-
Thank you Eric, I updated TestRealTimeGet and uncommented line 770 in the
RealTimeGetComponent:
{code:java}
// don't return copyField targets
// if (sf != null && schema.isCopyFieldTarget(sf)) continue;{code}
Now document from /get contains copied field but field value is not correct
because not changed by field index analyzer.
SolrDocument returned by /get by id should contain field transformations as
after Lucene write/read cycle.
Patch with updated test [^SOLR-14282-test-update.patch].
> /get handler doesn't return copied fields
> -
>
> Key: SOLR-14282
> URL: https://issues.apache.org/jira/browse/SOLR-14282
> Project: Solr
> Issue Type: Bug
> Components: search, SolrJ
>Affects Versions: 8.4
> Environment: SOLR 8.4.0, SOLRJ, Oracle Java 8
>Reporter: Andrei Minin
>Priority: Major
> Attachments: SOLR-14282-test-update.patch, copied_fields_test.zip,
> managed-schema.xml
>
>
> We are using /get handler to retrieve documents by id in our Java application
> (SolrJ)
> I found that copied fields are missing in documents returned by /get handler
> but same documents returned by query contain copied (by schema) fields.
> Attached documents:
> # Integration test project archive
> # Managed schema file for SOLR
> SOLR schema details:
> # Unique field name "d_ida_s"
> # Lowecase text type definition:
> {code:java}
> positionIncrementGap="100">
>
>
>
>
> {code}
> 3. Copy field instruction sample:
> {code:java}
> stored="true" multiValued="false"/>
> />
> {code}
> ConcurrenceUserNamea_s is string type field and ConcurrenceUserNameu_lca_s is
> lower case text type field.
> Integration test uploads document to SOLR server and makes 2 requests: one
> using /get rest point to fetch document by id and one using query field name>:.
> Document returned by /get rest, doesn't have copied fields while document
> returned by query, contains copied fields.
--
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-14282) /get handler doesn't return copied fields
[
https://issues.apache.org/jira/browse/SOLR-14282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213167#comment-17213167
]
Andrei Minin edited comment on SOLR-14282 at 10/13/20, 3:28 PM:
Thank you Eric, I updated TestRealTimeGet and commented line 770 in the
RealTimeGetComponent:
{code:java}
// don't return copyField targets
// if (sf != null && schema.isCopyFieldTarget(sf)) continue;{code}
Now document from /get contains copied field but field value is not correct
because not changed by field index analyzer.
SolrDocument returned by /get by id should contain field transformations as
after Lucene write/read cycle.
Patch with updated test [^SOLR-14282-test-update.patch].
was (Author: ami...@intellective.com):
Thank you Eric, I updated TestRealTimeGet and uncommented line 770 in the
RealTimeGetComponent:
{code:java}
// don't return copyField targets
// if (sf != null && schema.isCopyFieldTarget(sf)) continue;{code}
Now document from /get contains copied field but field value is not correct
because not changed by field index analyzer.
SolrDocument returned by /get by id should contain field transformations as
after Lucene write/read cycle.
Patch with updated test [^SOLR-14282-test-update.patch].
> /get handler doesn't return copied fields
> -
>
> Key: SOLR-14282
> URL: https://issues.apache.org/jira/browse/SOLR-14282
> Project: Solr
> Issue Type: Bug
> Components: search, SolrJ
>Affects Versions: 8.4
> Environment: SOLR 8.4.0, SOLRJ, Oracle Java 8
>Reporter: Andrei Minin
>Priority: Major
> Attachments: SOLR-14282-test-update.patch, copied_fields_test.zip,
> managed-schema.xml
>
>
> We are using /get handler to retrieve documents by id in our Java application
> (SolrJ)
> I found that copied fields are missing in documents returned by /get handler
> but same documents returned by query contain copied (by schema) fields.
> Attached documents:
> # Integration test project archive
> # Managed schema file for SOLR
> SOLR schema details:
> # Unique field name "d_ida_s"
> # Lowecase text type definition:
> {code:java}
> positionIncrementGap="100">
>
>
>
>
> {code}
> 3. Copy field instruction sample:
> {code:java}
> stored="true" multiValued="false"/>
> />
> {code}
> ConcurrenceUserNamea_s is string type field and ConcurrenceUserNameu_lca_s is
> lower case text type field.
> Integration test uploads document to SOLR server and makes 2 requests: one
> using /get rest point to fetch document by id and one using query field name>:.
> Document returned by /get rest, doesn't have copied fields while document
> returned by query, contains copied fields.
--
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-14861) CoreContainer shutdown needs to be aware of other ongoing operations and wait until they're complete
[ https://issues.apache.org/jira/browse/SOLR-14861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213179#comment-17213179 ] Erick Erickson commented on SOLR-14861: --- Hey, man, I'm just reporting how it works now ;)... I think you're missing the sequence here though. reload _does_ complete before returning. So does _shutdown_. They just get time-sliced out before being completed and that's what causes problems. - reload starts, gets past the isShutdown check then gets time-sliced out - shutdown is called (particularly troublesome in tests because we start the termination process at the end of the test) - reload gets time sliced back in and falls apart because shutdown has partially completed. take a look at all the code in CoreContainer.shutdown() that happens after the isShutdown flag is set. Then take a quick look at all the places we reference that in the code (not just admin level tasks) then carry on blindly. It's pretty scary. Power loss also has nothing to do with it, because there's no time-slicing involved in that event. And there's no corruption that I've seen, just test failures. It's exactly that we need a way to hold up processing shutdown until all outstanding requests are completed while refusing existing requests. However, "request" is a tricky concept here. The testing case it's particularly nasty because tests directly call coreContainer.shutdown(), there's really no high-level request involved. As I stated, the wait in the test is just evidence that this is the problem, I never suggested it be a real fix. > CoreContainer shutdown needs to be aware of other ongoing operations and wait > until they're complete > > > Key: SOLR-14861 > URL: https://issues.apache.org/jira/browse/SOLR-14861 > Project: Solr > Issue Type: Bug >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-14861.patch > > > Noble and I are trying to get to the bottom of the TestBulkSchemaConcurrent > failures and found what looks like a glaring gap in how > CoreContainer.shutdown operates. I don't know the impact on production since > we're shutting down anyway, but I think this is responsible for the errors in > TestBulkSchemaConcurrent and likely behind others, especially any other test > that fails intermittently that involves core reloads, including and > especially any tests that exercise managed schema. > We have clear evidence of this sequence: > 1> some CoreContainer.reloads come in and get _partway_ through, in > particular past the test at the top where CoreContainer.reload() throws an > AlreadyClosed exception if (isShutdown). > 2> Some CoreContainer.shutdown() threads get some processing time before the > reloads in <1> are finished. > 3> the threads in <1> pick back up and go wonky. I suspect that there are a > number of different things that could be going wrong here depending on how > far through CoreContainer.shutdown() gets that pop out in different ways. > Since it's my shift (Noble has to sleep sometime), I put some crude locking > in just to test the idea; incrementing an AtomicInteger on entry to > CoreContainer.reload then decrementing it at the end, and spinning in > CoreContainer.shutdown() until the AtomicInteger was back to zero. With that > in place, 100 runs and no errors whereas before I could never get even 10 > runs to finish without an error. This is not a proper fix at all, and the way > it's currently running there are still possible race conditions, just much > smaller windows. And I suspect it risks spinning forever. But it's enough to > make me believe I finally understand what's happening. > I also suspect that reload is more sensitive than most operations on a core > due to the fact that it runs for a long time, but I assume other operations > have the same potential. Shouldn't CoreContainer.shutDown() wait until no > other operations are in flight? > On a quick scan of CoreContainer, there are actually few places where we even > check for isShutdown, I suspect the places we do are ad-hoc that we've found > by trial-and-error when tests fail. We need a design rather than hit-or-miss > hacking. > I think that isShutdown should be replaced with something more robust. What > that is IDK quite yet because I've been hammering at this long enough and I > need a break. > This is consistent with another observation about this particular test. If > there's sleep at the end, it wouldn't fail; all the reloads get a chance to > finish before anything was shut down. > An open question how much this matters to production systems. In the testing > case, bunches of these reloads are issued then we immediately end the test > and
[jira] [Commented] (LUCENE-9568) FuzzyTermEnums sets negative boost for fuzzy search & highlight
[
https://issues.apache.org/jira/browse/LUCENE-9568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213185#comment-17213185
]
Robert Muir commented on LUCENE-9568:
-
Yeah, and I think it also explains why the problem only happens with
highlighter. I'm guessing it doesn't use TopTermsRewrite, but something else.
> FuzzyTermEnums sets negative boost for fuzzy search & highlight
> ---
>
> Key: LUCENE-9568
> URL: https://issues.apache.org/jira/browse/LUCENE-9568
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/highlighter
>Affects Versions: 8.5.1
>Reporter: Juraj Jurčo
>Priority: Minor
> Labels: highlighting, newbie
> Attachments: FindSqlHighlightTest.java
>
>
> *Description*
> When user indexes a word with an apostrophe and constructs a fuzzy query for
> highlighter, it throws an exception with set negative boost for a query.
> *Repro Steps*
> # Index a text with apostrophe. E.g. doesn't
> # Parse a fuzzy query e.g.: se~, se~2, se~3
> # Try to highlight a text with apostrophe
> # The exception is thrown (for details see attached test test with repro
> steps)
> *Actual Result*
> {{java.lang.IllegalArgumentException: boost must be a positive float, got
> -1.0}}
> *Expected Result*
> * No exception.
> * Highlighting marks are inserted into a text.
> *Workaround*
> - not known.
--
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-14282) /get handler doesn't return copied fields
[
https://issues.apache.org/jira/browse/SOLR-14282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213210#comment-17213210
]
David Eric Pugh commented on SOLR-14282:
Is the `/get` not meant to be used by clients for display purposes?I know
that inside of SolrCloud we use `/get` to move data around, and so I can
completely understand why we wouldn't include copyField results.
But in a client who is just looking up a document by ID, it seems like in that
use case that returning the copyFields makes sense?
Is this one of those cases where we need a flag to /get to control this
behavior?
> /get handler doesn't return copied fields
> -
>
> Key: SOLR-14282
> URL: https://issues.apache.org/jira/browse/SOLR-14282
> Project: Solr
> Issue Type: Bug
> Components: search, SolrJ
>Affects Versions: 8.4
> Environment: SOLR 8.4.0, SOLRJ, Oracle Java 8
>Reporter: Andrei Minin
>Priority: Major
> Attachments: SOLR-14282-test-update.patch, copied_fields_test.zip,
> managed-schema.xml
>
>
> We are using /get handler to retrieve documents by id in our Java application
> (SolrJ)
> I found that copied fields are missing in documents returned by /get handler
> but same documents returned by query contain copied (by schema) fields.
> Attached documents:
> # Integration test project archive
> # Managed schema file for SOLR
> SOLR schema details:
> # Unique field name "d_ida_s"
> # Lowecase text type definition:
> {code:java}
> positionIncrementGap="100">
>
>
>
>
> {code}
> 3. Copy field instruction sample:
> {code:java}
> stored="true" multiValued="false"/>
> />
> {code}
> ConcurrenceUserNamea_s is string type field and ConcurrenceUserNameu_lca_s is
> lower case text type field.
> Integration test uploads document to SOLR server and makes 2 requests: one
> using /get rest point to fetch document by id and one using query field name>:.
> Document returned by /get rest, doesn't have copied fields while document
> returned by query, contains copied fields.
--
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-14861) CoreContainer shutdown needs to be aware of other ongoing operations and wait until they're complete
[
https://issues.apache.org/jira/browse/SOLR-14861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213282#comment-17213282
]
Gus Heck commented on SOLR-14861:
-
Sorry didn't mean to sound accusatory. I guess I'm not understanding this: How
is reload "complete" if it's time-sliced out.. that sounds like it's not
"complete" to me.
Looking at the test specifically, it appears to create 5 threads start them and
then thread.join all of them, if reload is timesliced out, the thread in
question shouldn't' be finished (unless the reload call is happening async
which would be the problem I'm talking about) and the join should continue to
block preventing the test harness from shutting down (because the test method
isn't finished). Alternately maybe I'm confused about who is calling shutdown?
Looking into the sub-methods I find another example of what I'm talking about
even though it shouldn't actually cause failure here unless perhaps this
heuristic can pass before reload completes...
{code:java}
RestTestHarness publisher = randomRestTestHarness(r);
String response = publisher.post("/schema", SolrTestCaseJ4.json(payload));
{code}
should be blocking until the core is reloaded and changes are safe for use by
the caller (IMHO). The subsequent loop should not be needed:
{code:java}
try {
long startTime = System.nanoTime();
long maxTimeoutMillis = 10;
while (TimeUnit.MILLISECONDS.convert(System.nanoTime() - startTime,
TimeUnit.NANOSECONDS) < maxTimeoutMillis) {
errmessages.clear();
Map m = getObj(harness, aField, "fields");
if (m != null) errmessages.add(StrUtils.formatString("field {0} still
exists", aField));
m = getObj(harness, dynamicFldName, "dynamicFields");
if (m != null) errmessages.add(StrUtils.formatString("dynamic field {0}
still exists", dynamicFldName));
List l = getSourceCopyFields(harness, aField);
if (checkCopyField(l, aField, dynamicCopyFldDest))
errmessages.add(StrUtils.formatString("CopyField source={0},dest={1}
still exists", aField, dynamicCopyFldDest));
m = getObj(harness, newFieldTypeName, "fieldTypes");
if (m != null) errmessages.add(StrUtils.formatString("new type {0}
still exists", newFieldTypeName));
if (errmessages.isEmpty()) break;
Thread.sleep(10);
}
{code}
As for code after shutdown, It looks like people may have read isShutDown two
different ways perhaps? Maybe we need two flags with clearer names...
isShutDownComplete and isShutDownInProgress?
> CoreContainer shutdown needs to be aware of other ongoing operations and wait
> until they're complete
>
>
> Key: SOLR-14861
> URL: https://issues.apache.org/jira/browse/SOLR-14861
> Project: Solr
> Issue Type: Bug
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-14861.patch
>
>
> Noble and I are trying to get to the bottom of the TestBulkSchemaConcurrent
> failures and found what looks like a glaring gap in how
> CoreContainer.shutdown operates. I don't know the impact on production since
> we're shutting down anyway, but I think this is responsible for the errors in
> TestBulkSchemaConcurrent and likely behind others, especially any other test
> that fails intermittently that involves core reloads, including and
> especially any tests that exercise managed schema.
> We have clear evidence of this sequence:
> 1> some CoreContainer.reloads come in and get _partway_ through, in
> particular past the test at the top where CoreContainer.reload() throws an
> AlreadyClosed exception if (isShutdown).
> 2> Some CoreContainer.shutdown() threads get some processing time before the
> reloads in <1> are finished.
> 3> the threads in <1> pick back up and go wonky. I suspect that there are a
> number of different things that could be going wrong here depending on how
> far through CoreContainer.shutdown() gets that pop out in different ways.
> Since it's my shift (Noble has to sleep sometime), I put some crude locking
> in just to test the idea; incrementing an AtomicInteger on entry to
> CoreContainer.reload then decrementing it at the end, and spinning in
> CoreContainer.shutdown() until the AtomicInteger was back to zero. With that
> in place, 100 runs and no errors whereas before I could never get even 10
> runs to finish without an error. This is not a proper fix at all, and the way
> it's currently running there are still possible race conditions, just much
> smaller windows. And I suspect it risks spinning forever. But it's enough to
> make me believe I finally understand what's happening.
> I also suspect that reload is more sensitive than most operations
[jira] [Updated] (SOLR-14925) CVE-2020-13957: The checks added to unauthenticated configset uploads can be circumvented
[
https://issues.apache.org/jira/browse/SOLR-14925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe updated SOLR-14925:
-
Affects Version/s: 6.6.6
> CVE-2020-13957: The checks added to unauthenticated configset uploads can be
> circumvented
> -
>
> Key: SOLR-14925
> URL: https://issues.apache.org/jira/browse/SOLR-14925
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 7.0,
> 7.0.1, 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1, 7.7.2, 8.0,
> 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.6, 8.5.1, 8.5.2,
> 8.6.1, 8.6.2
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Fix For: master (9.0), 8.7, 8.6.3
>
>
> Severity: High
> Vendor: The Apache Software Foundation
> Versions Affected:
> 6.6.0 to 6.6.5
> 7.0.0 to 7.7.3
> 8.0.0 to 8.6.2
> Description:
> Solr prevents some features considered dangerous (which could be used for
> remote code execution) to be configured in a ConfigSet that's uploaded via
> API without authentication/authorization. The checks in place to prevent such
> features can be circumvented by using a combination of UPLOAD/CREATE actions.
> Mitigation:
> Any of the following are enough to prevent this vulnerability:
> * Disable UPLOAD command in ConfigSets API if not used by setting the system
> property: {{configset.upload.enabled}} to {{false}} [1]
> * Use Authentication/Authorization and make sure unknown requests aren't
> allowed [2]
> * Upgrade to Solr 8.6.3 or greater.
> * If upgrading is not an option, consider applying the patch in SOLR-14663
> ([3])
> * No Solr API, including the Admin UI, is designed to be exposed to
> non-trusted parties. Tune your firewall so that only trusted computers and
> people are allowed access
> Credit:
> Tomás Fernández Löbbe, András Salamon
> References:
> [1] https://lucene.apache.org/solr/guide/8_6/configsets-api.html
> [2]
> https://lucene.apache.org/solr/guide/8_6/authentication-and-authorization-plugins.html
> [3] https://issues.apache.org/jira/browse/SOLR-14663
> [4] https://issues.apache.org/jira/browse/SOLR-14925
> [5] https://wiki.apache.org/solr/SolrSecurity
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14861) CoreContainer shutdown needs to be aware of other ongoing operations and wait until they're complete
[
https://issues.apache.org/jira/browse/SOLR-14861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213316#comment-17213316
]
Erick Erickson commented on SOLR-14861:
---
Yeah, the threads join, but each one calls testHarness.close(). It's not clear
to me whether/how that gets to coreContainer.shutdown() or whether somehow
coreContainer.shutdown() is called by the test ending. But it doesn't matter
because it led me to look at the code, and it's fragile.
What I can guarantee is that the reload does not necessarily complete before
coreContainer.shutdown is called().
Forget the test for a minute and look for the places like this in the code
(from the aforementioned coreContainer.reload). Or where
coreContainer.isShutDown() is called.
{code}
if (isShutDown) {
throw new AlreadyClosedException();
}
continue on with the rest of the method
{code}
Once a thread is past that check, it _assumes_ that coreContainer is OK to use
and will remain so until the method ends. If, for any reason, the thread is
suspended and time is given to another thread that is processing shutdown,
things can go wonky.
Having two variables wouldn't make any difference that I can see, the
assumption that once past any such test test you're safe is inherently
fragile/sensitive to race conditions...
> CoreContainer shutdown needs to be aware of other ongoing operations and wait
> until they're complete
>
>
> Key: SOLR-14861
> URL: https://issues.apache.org/jira/browse/SOLR-14861
> Project: Solr
> Issue Type: Bug
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-14861.patch
>
>
> Noble and I are trying to get to the bottom of the TestBulkSchemaConcurrent
> failures and found what looks like a glaring gap in how
> CoreContainer.shutdown operates. I don't know the impact on production since
> we're shutting down anyway, but I think this is responsible for the errors in
> TestBulkSchemaConcurrent and likely behind others, especially any other test
> that fails intermittently that involves core reloads, including and
> especially any tests that exercise managed schema.
> We have clear evidence of this sequence:
> 1> some CoreContainer.reloads come in and get _partway_ through, in
> particular past the test at the top where CoreContainer.reload() throws an
> AlreadyClosed exception if (isShutdown).
> 2> Some CoreContainer.shutdown() threads get some processing time before the
> reloads in <1> are finished.
> 3> the threads in <1> pick back up and go wonky. I suspect that there are a
> number of different things that could be going wrong here depending on how
> far through CoreContainer.shutdown() gets that pop out in different ways.
> Since it's my shift (Noble has to sleep sometime), I put some crude locking
> in just to test the idea; incrementing an AtomicInteger on entry to
> CoreContainer.reload then decrementing it at the end, and spinning in
> CoreContainer.shutdown() until the AtomicInteger was back to zero. With that
> in place, 100 runs and no errors whereas before I could never get even 10
> runs to finish without an error. This is not a proper fix at all, and the way
> it's currently running there are still possible race conditions, just much
> smaller windows. And I suspect it risks spinning forever. But it's enough to
> make me believe I finally understand what's happening.
> I also suspect that reload is more sensitive than most operations on a core
> due to the fact that it runs for a long time, but I assume other operations
> have the same potential. Shouldn't CoreContainer.shutDown() wait until no
> other operations are in flight?
> On a quick scan of CoreContainer, there are actually few places where we even
> check for isShutdown, I suspect the places we do are ad-hoc that we've found
> by trial-and-error when tests fail. We need a design rather than hit-or-miss
> hacking.
> I think that isShutdown should be replaced with something more robust. What
> that is IDK quite yet because I've been hammering at this long enough and I
> need a break.
> This is consistent with another observation about this particular test. If
> there's sleep at the end, it wouldn't fail; all the reloads get a chance to
> finish before anything was shut down.
> An open question how much this matters to production systems. In the testing
> case, bunches of these reloads are issued then we immediately end the test
> and start shutting things down. It needs to be fixed if we're going to cut
> down on test failures though. Besides, it's just wrong ;)
> Assigning to myself to track. I'd be perfectly happy, now that Noble and I
> have done the hard work, for someone to swoop in and
[jira] [Resolved] (SOLR-14918) add "failIfEmptyCores" option for HealthCheckHandler
[ https://issues.apache.org/jira/browse/SOLR-14918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taisuke Miyazaki resolved SOLR-14918. - Resolution: Won't Fix > add "failIfEmptyCores" option for HealthCheckHandler > > > Key: SOLR-14918 > URL: https://issues.apache.org/jira/browse/SOLR-14918 > Project: Solr > Issue Type: New Feature >Affects Versions: 8.6 >Reporter: Taisuke Miyazaki >Priority: Major > Labels: features, ready-to-commit > Time Spent: 10m > Remaining Estimate: 0h > > h2. Background > We are hosting Solr on AWS EC2. > We have set up Solr to start in systemd and create a core at startup. (The > replica type is "pull".) > I manage those EC2 instances in the AWS AutoScaling Group and use TargetGroup > to access Solr via the Application Load Balancer. > For health checks in TargetGroup, we use the requireHealthyCores option using > /api/node/health (henceforth called HealthCheckHandler). > In most cases this is not a problem. > However, this can cause additional problems with a rare core creation failure > issue at startup. > If you use the requireHealthyCores option for HealtchCheckHandler, the status > will be OK if the core is not there in the first place, so the health check > will be OK even though the core is not present (an unusual condition). > h2. Proposal > Therefore, we propose to add an option to set the status to Fail if the core > does not exist. That way, we can make the health check fail even if the core > was not created for some reason. > We believe this option should only work if the requireHealthyCores option is > true. > > Translated with www.DeepL.com/Translator (free version) -- 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-14282) /get handler doesn't return copied fields
[
https://issues.apache.org/jira/browse/SOLR-14282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213331#comment-17213331
]
Andrei Minin commented on SOLR-14282:
-
By documentation, real time get designed to make Solr similar to NoSql
store.So, /get should work as specialized, optimuzed search by id. But, by
behaviour, it is not "get from store" but "get from input log / queue"
Most repositories provide search and get/fetch API - NoSql storages like
Cassandra, Box, FileNet, Cmod, etc —I am deleloping crawler/checker/searcher
application working with multiple storages where Solr is one of major
repositories and all repos return same documents in search and fetch requests.
Solr index schema copy Field instruction is de facto preprocessor for uploaded
documents and stored/returned in search documents may differ from input
documents (some fields not returned because not stored, modified or new fields
added).
It is hard to make Solr act like real NoSql storage because some information is
lost after document written to index - you may try to recover it but it is not
gurantee.
What would be efficient is combining nosql store and index in one app; index
used for searching only, nosql store to put/get fields and fast recrawl. In my
real projects, some indices recrawling takes around 3 months and it is blocking
fixes, upgrades, etc — being able to quickly recrawl index internally without
using external repositories will be big relief. Sorry for offtopic.
> /get handler doesn't return copied fields
> -
>
> Key: SOLR-14282
> URL: https://issues.apache.org/jira/browse/SOLR-14282
> Project: Solr
> Issue Type: Bug
> Components: search, SolrJ
>Affects Versions: 8.4
> Environment: SOLR 8.4.0, SOLRJ, Oracle Java 8
>Reporter: Andrei Minin
>Priority: Major
> Attachments: SOLR-14282-test-update.patch, copied_fields_test.zip,
> managed-schema.xml
>
>
> We are using /get handler to retrieve documents by id in our Java application
> (SolrJ)
> I found that copied fields are missing in documents returned by /get handler
> but same documents returned by query contain copied (by schema) fields.
> Attached documents:
> # Integration test project archive
> # Managed schema file for SOLR
> SOLR schema details:
> # Unique field name "d_ida_s"
> # Lowecase text type definition:
> {code:java}
> positionIncrementGap="100">
>
>
>
>
> {code}
> 3. Copy field instruction sample:
> {code:java}
> stored="true" multiValued="false"/>
> />
> {code}
> ConcurrenceUserNamea_s is string type field and ConcurrenceUserNameu_lca_s is
> lower case text type field.
> Integration test uploads document to SOLR server and makes 2 requests: one
> using /get rest point to fetch document by id and one using query field name>:.
> Document returned by /get rest, doesn't have copied fields while document
> returned by query, contains copied fields.
--
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-14282) /get handler doesn't return copied fields
[
https://issues.apache.org/jira/browse/SOLR-14282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213338#comment-17213338
]
David Eric Pugh commented on SOLR-14282:
I'm looking for a test in the Solr cloud area that says returning the copyField
targets is bad, and ahven't seen anything yet. [~erickerickson] any advice on
how to find out if this causes some knock on effects elsewhere?
> /get handler doesn't return copied fields
> -
>
> Key: SOLR-14282
> URL: https://issues.apache.org/jira/browse/SOLR-14282
> Project: Solr
> Issue Type: Bug
> Components: search, SolrJ
>Affects Versions: 8.4
> Environment: SOLR 8.4.0, SOLRJ, Oracle Java 8
>Reporter: Andrei Minin
>Priority: Major
> Attachments: SOLR-14282-test-update.patch, copied_fields_test.zip,
> managed-schema.xml
>
>
> We are using /get handler to retrieve documents by id in our Java application
> (SolrJ)
> I found that copied fields are missing in documents returned by /get handler
> but same documents returned by query contain copied (by schema) fields.
> Attached documents:
> # Integration test project archive
> # Managed schema file for SOLR
> SOLR schema details:
> # Unique field name "d_ida_s"
> # Lowecase text type definition:
> {code:java}
> positionIncrementGap="100">
>
>
>
>
> {code}
> 3. Copy field instruction sample:
> {code:java}
> stored="true" multiValued="false"/>
> />
> {code}
> ConcurrenceUserNamea_s is string type field and ConcurrenceUserNameu_lca_s is
> lower case text type field.
> Integration test uploads document to SOLR server and makes 2 requests: one
> using /get rest point to fetch document by id and one using query field name>:.
> Document returned by /get rest, doesn't have copied fields while document
> returned by query, contains copied fields.
--
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-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Pimentel updated SOLR-14066: Attachment: image-2020-10-13-21-01-48-401.png > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png, > image-2020-10-13-21-01-48-401.png > > Time Spent: 1h 10m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- 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-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213341#comment-17213341 ] Rui Pimentel commented on SOLR-14066: - Hi community, Based on this document there are two ways to index document on the Solr platform, [https://lucidworks.com/post/indexing-with-solrj/] Quote: *"Two popular methods of indexing existing data are the Data Import Handler (DIH) and Tika (Solr Cell)/ExtractingRequestHandler"* Now that DHI has been discontinued, only supported by a community package, are there any other options? Best regards Rui > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png, > image-2020-10-13-21-01-48-401.png > > Time Spent: 1h 10m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- 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-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213345#comment-17213345 ] Jan Høydahl commented on SOLR-14066: Please do not use a closed Jira for discussion. Send your question to the "solr-user" mailing list. > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png, > image-2020-10-13-21-01-48-401.png > > Time Spent: 1h 10m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- 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-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Pimentel updated SOLR-14066: Attachment: image-2020-10-13-21-18-43-877.png > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png, > image-2020-10-13-21-01-48-401.png, image-2020-10-13-21-18-43-877.png > > Time Spent: 1h 10m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- 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] gus-asf closed pull request #1966: LUCENE-9574 Add DropIfFlaggedFilterFactory
gus-asf closed pull request #1966: URL: https://github.com/apache/lucene-solr/pull/1966 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-14282) /get handler doesn't return copied fields
[
https://issues.apache.org/jira/browse/SOLR-14282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213353#comment-17213353
]
David Eric Pugh commented on SOLR-14282:
Okay, chasing down I found that this is when we changed it:
https://github.com/apache/lucene-solr/commit/97689f52f2334c3dddb8ea4befa3f01beeedaf06
This was part of SOLR-3743.
> /get handler doesn't return copied fields
> -
>
> Key: SOLR-14282
> URL: https://issues.apache.org/jira/browse/SOLR-14282
> Project: Solr
> Issue Type: Bug
> Components: search, SolrJ
>Affects Versions: 8.4
> Environment: SOLR 8.4.0, SOLRJ, Oracle Java 8
>Reporter: Andrei Minin
>Priority: Major
> Attachments: SOLR-14282-test-update.patch, copied_fields_test.zip,
> managed-schema.xml
>
>
> We are using /get handler to retrieve documents by id in our Java application
> (SolrJ)
> I found that copied fields are missing in documents returned by /get handler
> but same documents returned by query contain copied (by schema) fields.
> Attached documents:
> # Integration test project archive
> # Managed schema file for SOLR
> SOLR schema details:
> # Unique field name "d_ida_s"
> # Lowecase text type definition:
> {code:java}
> positionIncrementGap="100">
>
>
>
>
> {code}
> 3. Copy field instruction sample:
> {code:java}
> stored="true" multiValued="false"/>
> />
> {code}
> ConcurrenceUserNamea_s is string type field and ConcurrenceUserNameu_lca_s is
> lower case text type field.
> Integration test uploads document to SOLR server and makes 2 requests: one
> using /get rest point to fetch document by id and one using query field name>:.
> Document returned by /get rest, doesn't have copied fields while document
> returned by query, contains copied fields.
--
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-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213355#comment-17213355 ] Rui Pimentel commented on SOLR-14066: - Hi, I'm currently using Solr-8.5.2 and I'm trying to do the following : Each time an event appears in the log file, I check, rectify if necessary and clean (Rotate) the logfiles. This causes the solr.log file to run out of data, which is what we want. However if I use the web interface, "localhost: port", and view the "Logging" option, messages remain visible. Any idea why this is happening? Best regards Rui > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png, > image-2020-10-13-21-01-48-401.png, image-2020-10-13-21-18-43-877.png > > Time Spent: 1h 10m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- 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-14575) Solr restore is failing when basic authentication is enabled
[
https://issues.apache.org/jira/browse/SOLR-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213361#comment-17213361
]
Yaswanth commented on SOLR-14575:
-
can I get some traction on this pls? this is not only for the solr restore, but
this is throwing same error when I try to addreplica to already existing
collection.
> Solr restore is failing when basic authentication is enabled
>
>
> Key: SOLR-14575
> URL: https://issues.apache.org/jira/browse/SOLR-14575
> Project: Solr
> Issue Type: Bug
> Components: Backup/Restore
>Affects Versions: 8.2
>Reporter: Yaswanth
>Priority: Major
>
> Hi Team,
> I was testing backup / restore for solrcloud and its failing exactly when I
> am trying to restore a successfully backed up collection.
> I am using solr 8.2 with basic authentication enabled and then creating a 2
> replica collection. When I run the backup like
> curl -u xxx:xxx -k
> '[https://x.x.x.x:8080/solr/admin/collections?action=BACKUP&name=test&collection=test&location=/solrdatabkup'|https://x.x.x.x:8080/solr/admin/collections?action=BACKUP&name=test&collection=test&location=/solrdatabkup%27]
> it worked fine and I do see a folder was created with the collection name
> under /solrdatabackup
> But now when I deleted the existing collection and then try running restore
> api like
> curl -u xxx:xxx -k
> '[https://x.x.x.x:8080/solr/admin/collections?action=RESTORE&name=test&collection=test&location=/solrdatabkup'|https://x.x.x.x:8080/solr/admin/collections?action=BACKUP&name=test&collection=test&location=/solrdatabkup%27]
> its throwing an error like
> {
> "responseHeader":{
> "status":500,
> "QTime":457},
> "Operation restore caused
> *exception:":"org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
> ADDREPLICA failed to create replica",*
> "exception":{
> "msg":"ADDREPLICA failed to create replica",
> "rspCode":500},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"ADDREPLICA failed to create replica",
> "trace":"org.apache.solr.common.SolrException: ADDREPLICA failed to create
> replica\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:280)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:252)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:820)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:786)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:546)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:423)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:350)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(Rewri
[jira] [Commented] (SOLR-14282) /get handler doesn't return copied fields
[
https://issues.apache.org/jira/browse/SOLR-14282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213362#comment-17213362
]
Andrei Minin commented on SOLR-14282:
-
Thank you, David. Is /get returning same result always or it may return
different document when update log expires (can it expire?)
> /get handler doesn't return copied fields
> -
>
> Key: SOLR-14282
> URL: https://issues.apache.org/jira/browse/SOLR-14282
> Project: Solr
> Issue Type: Bug
> Components: search, SolrJ
>Affects Versions: 8.4
> Environment: SOLR 8.4.0, SOLRJ, Oracle Java 8
>Reporter: Andrei Minin
>Priority: Major
> Attachments: SOLR-14282-test-update.patch, copied_fields_test.zip,
> managed-schema.xml
>
>
> We are using /get handler to retrieve documents by id in our Java application
> (SolrJ)
> I found that copied fields are missing in documents returned by /get handler
> but same documents returned by query contain copied (by schema) fields.
> Attached documents:
> # Integration test project archive
> # Managed schema file for SOLR
> SOLR schema details:
> # Unique field name "d_ida_s"
> # Lowecase text type definition:
> {code:java}
> positionIncrementGap="100">
>
>
>
>
> {code}
> 3. Copy field instruction sample:
> {code:java}
> stored="true" multiValued="false"/>
> />
> {code}
> ConcurrenceUserNamea_s is string type field and ConcurrenceUserNameu_lca_s is
> lower case text type field.
> Integration test uploads document to SOLR server and makes 2 requests: one
> using /get rest point to fetch document by id and one using query field name>:.
> Document returned by /get rest, doesn't have copied fields while document
> returned by query, contains copied fields.
--
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] HoustonPutman merged pull request #1977: SOLR-14907: Support single file upload/overwrite in configSet API
HoustonPutman merged pull request #1977: URL: https://github.com/apache/lucene-solr/pull/1977 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-14907) Support single file upload/overwrite in configSet API
[ https://issues.apache.org/jira/browse/SOLR-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213365#comment-17213365 ] ASF subversion and git services commented on SOLR-14907: Commit bcd9cbec95507d19f17b459ea2f4b96d5de9486e in lucene-solr's branch refs/heads/master from Houston Putman [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=bcd9cbe ] SOLR-14907: Support single file upload/overwrite in configSet API (#1977) > Support single file upload/overwrite in configSet API > - > > Key: SOLR-14907 > URL: https://issues.apache.org/jira/browse/SOLR-14907 > Project: Solr > Issue Type: Improvement > Components: configset-api >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > After SOLR-10391 was implemented, users are now able to overwrite existing > configSets using the configSet API. However the files uploaded are still > required to be zipped and indexed from the base configSet path in ZK. Users > might want to just update a single file, such as a synonyms list, and not > have to tar it up first. > The proposed solution is to add parameters to the UPLOAD configSet action, to > allow this single-file use case. This would utilize the protections already > provided by the API, such as maintaining the trustiness of configSets being > modified. > This feature is part of the solution to replace managed resources, which is > planned to be deprecated and removed by 9.0 (SOLR-14766). -- 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-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213414#comment-17213414 ] Jan Høydahl commented on SOLR-14066: [~informat...@spautores.pt] please use the mailing list for questions. JIRA is for bug tracking. See https://lucene.apache.org/solr/community.html#mailing-lists-irc > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png, > image-2020-10-13-21-01-48-401.png, image-2020-10-13-21-18-43-877.png > > Time Spent: 1h 10m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- 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-14907) Support single file upload/overwrite in configSet API
[ https://issues.apache.org/jira/browse/SOLR-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213443#comment-17213443 ] ASF subversion and git services commented on SOLR-14907: Commit 0834589399a682555b1f7b7294bdac1b05b72815 in lucene-solr's branch refs/heads/branch_8x from Houston Putman [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0834589 ] SOLR-14907: Support single file upload/overwrite in configSet API (#1977) > Support single file upload/overwrite in configSet API > - > > Key: SOLR-14907 > URL: https://issues.apache.org/jira/browse/SOLR-14907 > Project: Solr > Issue Type: Improvement > Components: configset-api >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > After SOLR-10391 was implemented, users are now able to overwrite existing > configSets using the configSet API. However the files uploaded are still > required to be zipped and indexed from the base configSet path in ZK. Users > might want to just update a single file, such as a synonyms list, and not > have to tar it up first. > The proposed solution is to add parameters to the UPLOAD configSet action, to > allow this single-file use case. This would utilize the protections already > provided by the API, such as maintaining the trustiness of configSets being > modified. > This feature is part of the solution to replace managed resources, which is > planned to be deprecated and removed by 9.0 (SOLR-14766). -- 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-14907) Support single file upload/overwrite in configSet API
[ https://issues.apache.org/jira/browse/SOLR-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman resolved SOLR-14907. --- Fix Version/s: 8.7 Resolution: Implemented > Support single file upload/overwrite in configSet API > - > > Key: SOLR-14907 > URL: https://issues.apache.org/jira/browse/SOLR-14907 > Project: Solr > Issue Type: Improvement > Components: configset-api >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Major > Fix For: 8.7 > > Time Spent: 40m > Remaining Estimate: 0h > > After SOLR-10391 was implemented, users are now able to overwrite existing > configSets using the configSet API. However the files uploaded are still > required to be zipped and indexed from the base configSet path in ZK. Users > might want to just update a single file, such as a synonyms list, and not > have to tar it up first. > The proposed solution is to add parameters to the UPLOAD configSet action, to > allow this single-file use case. This would utilize the protections already > provided by the API, such as maintaining the trustiness of configSets being > modified. > This feature is part of the solution to replace managed resources, which is > planned to be deprecated and removed by 9.0 (SOLR-14766). -- 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-14575) Solr restore is failing when basic authentication is enabled
[
https://issues.apache.org/jira/browse/SOLR-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213455#comment-17213455
]
Jan Høydahl commented on SOLR-14575:
{quote}You can help us reproducing by downloading a fresh version of Solr (e.g.
8.6.0), and trying to reproduce on a minimal collection with minimal
security.json config. If you are able to provide a step by step reproduction
instruction from scratch, then others may be able to debug and see what is
happening.
{quote}
This is what I wrote June 14th, and you have still not provided such
information. Here is a template that, using Docker, restores a collection in a
cluster with BasicAuth enabled. It works fine here. Are you able to modify the
example in a way that triggers the behavior your're seeing?
{noformat}
# Create a network
docker network create sn
# Start node 1
docker run --rm --name solr1 -v $(pwd):/var/solr/data/v -d --network sn -p
8983:8983 solr:8.6 -p 8983 -h solr1 -c
# Start node 2
docker run --rm --name solr2 -v $(pwd):/var/solr/data/v -d --network sn -p
8984:8984 solr:8.6 -p 8984 -h solr2 -z solr1:9983
# Create a collection
docker exec solr1 solr create -c c -replicationFactor 2
# Backup collection
docker exec solr1 curl
http://localhost:8983/solr/admin/collections?action=BACKUP&name=b&collection=c&location=/var/solr/data/v
ls -l b
# Delete collection
docker exec solr1 solr delete -c c
# Upload security.json
cat Solr restore is failing when basic authentication is enabled
>
>
> Key: SOLR-14575
> URL: https://issues.apache.org/jira/browse/SOLR-14575
> Project: Solr
> Issue Type: Bug
> Components: Backup/Restore
>Affects Versions: 8.2
>Reporter: Yaswanth
>Priority: Major
>
> Hi Team,
> I was testing backup / restore for solrcloud and its failing exactly when I
> am trying to restore a successfully backed up collection.
> I am using solr 8.2 with basic authentication enabled and then creating a 2
> replica collection. When I run the backup like
> curl -u xxx:xxx -k
> '[https://x.x.x.x:8080/solr/admin/collections?action=BACKUP&name=test&collection=test&location=/solrdatabkup'|https://x.x.x.x:8080/solr/admin/collections?action=BACKUP&name=test&collection=test&location=/solrdatabkup%27]
> it worked fine and I do see a folder was created with the collection name
> under /solrdatabackup
> But now when I deleted the existing collection and then try running restore
> api like
> curl -u xxx:xxx -k
> '[https://x.x.x.x:8080/solr/admin/collections?action=RESTORE&name=test&collection=test&location=/solrdatabkup'|https://x.x.x.x:8080/solr/admin/collections?action=BACKUP&name=test&collection=test&location=/solrdatabkup%27]
> its throwing an error like
> {
> "responseHeader":{
> "status":500,
> "QTime":457},
> "Operation restore caused
> *exception:":"org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
> ADDREPLICA failed to create replica",*
> "exception":{
> "msg":"ADDREPLICA failed to create replica",
> "rspCode":500},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"ADDREPLICA failed to create replica",
> "trace":"org.apache.solr.common.SolrException: ADDREPLICA failed to create
> replica\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:280)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:252)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:820)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:786)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:546)\n\tat
> org.apache.solr.servlet.SolrDispatchFi
[jira] [Comment Edited] (SOLR-14575) Solr restore is failing when basic authentication is enabled
[
https://issues.apache.org/jira/browse/SOLR-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213455#comment-17213455
]
Jan Høydahl edited comment on SOLR-14575 at 10/13/20, 10:17 PM:
{quote}You can help us reproducing by downloading a fresh version of Solr (e.g.
8.6.0), and trying to reproduce on a minimal collection with minimal
security.json config. If you are able to provide a step by step reproduction
instruction from scratch, then others may be able to debug and see what is
happening.
{quote}
This is what I wrote June 14th, and you have still not provided such
information. Here is a template that, using Docker, restores a collection in a
cluster with BasicAuth enabled. It works fine here. Are you able to modify the
example in a way that triggers the behavior your're seeing?
{noformat}
# Create a network
docker network create sn
# Start node 1
docker run --rm --name solr1 -v $(pwd):/var/solr/data/v -d --network sn -p
8983:8983 solr:8.6 -p 8983 -h solr1 -c
# Start node 2
docker run --rm --name solr2 -v $(pwd):/var/solr/data/v -d --network sn -p
8984:8984 solr:8.6 -p 8984 -h solr2 -z solr1:9983
# Create a collection
docker exec solr1 solr create -c c -replicationFactor 2
# Backup collection
docker exec solr1 curl
http://localhost:8983/solr/admin/collections?action=BACKUP&name=b&collection=c&location=/var/solr/data/v
ls -l b
# Delete collection
docker exec solr1 solr delete -c c
# Upload security.json
cat Solr restore is failing when basic authentication is enabled
>
>
> Key: SOLR-14575
> URL: https://issues.apache.org/jira/browse/SOLR-14575
> Project: Solr
> Issue Type: Bug
> Components: Backup/Restore
>Affects Versions: 8.2
>Reporter: Yaswanth
>Priority: Major
>
> Hi Team,
> I was testing backup / restore for solrcloud and its failing exactly
[jira] [Commented] (SOLR-14575) Solr restore is failing when basic authentication is enabled
[
https://issues.apache.org/jira/browse/SOLR-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213459#comment-17213459
]
Yaswanth commented on SOLR-14575:
-
[~janhoy] thanks for the reply, but the problem is that I can't test this on
8.6.0 when we are already on 8.2 live, can you try the same to reproduce with
8.2 and let me know if you see the issue?
Also one more point is that I do have forwardCredientials: true on the
security.json
Thanks,
> Solr restore is failing when basic authentication is enabled
>
>
> Key: SOLR-14575
> URL: https://issues.apache.org/jira/browse/SOLR-14575
> Project: Solr
> Issue Type: Bug
> Components: Backup/Restore
>Affects Versions: 8.2
>Reporter: Yaswanth
>Priority: Major
>
> Hi Team,
> I was testing backup / restore for solrcloud and its failing exactly when I
> am trying to restore a successfully backed up collection.
> I am using solr 8.2 with basic authentication enabled and then creating a 2
> replica collection. When I run the backup like
> curl -u xxx:xxx -k
> '[https://x.x.x.x:8080/solr/admin/collections?action=BACKUP&name=test&collection=test&location=/solrdatabkup'|https://x.x.x.x:8080/solr/admin/collections?action=BACKUP&name=test&collection=test&location=/solrdatabkup%27]
> it worked fine and I do see a folder was created with the collection name
> under /solrdatabackup
> But now when I deleted the existing collection and then try running restore
> api like
> curl -u xxx:xxx -k
> '[https://x.x.x.x:8080/solr/admin/collections?action=RESTORE&name=test&collection=test&location=/solrdatabkup'|https://x.x.x.x:8080/solr/admin/collections?action=BACKUP&name=test&collection=test&location=/solrdatabkup%27]
> its throwing an error like
> {
> "responseHeader":{
> "status":500,
> "QTime":457},
> "Operation restore caused
> *exception:":"org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
> ADDREPLICA failed to create replica",*
> "exception":{
> "msg":"ADDREPLICA failed to create replica",
> "rspCode":500},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"ADDREPLICA failed to create replica",
> "trace":"org.apache.solr.common.SolrException: ADDREPLICA failed to create
> replica\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:280)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:252)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:820)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:786)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:546)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:423)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:350)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152)\n\tat
>
> org.eclipse.jetty.server.
[jira] [Commented] (SOLR-14788) Solr: The Next Big Thing
[
https://issues.apache.org/jira/browse/SOLR-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213467#comment-17213467
]
Mark Robert Miller commented on SOLR-14788:
---
I've been targeting mid October for stable core production behavior and that is
looking pretty much on target. Will see how it proves out over this week and
will be working on wrapping up remaining unignored tests.
> Solr: The Next Big Thing
>
>
> Key: SOLR-14788
> URL: https://issues.apache.org/jira/browse/SOLR-14788
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Priority: Critical
>
> h3.
> [!https://www.unicode.org/consortium/aacimg/1F46E.png!|https://www.unicode.org/consortium/adopted-characters.html#b1F46E]{color:#00875a}*The
> Policeman is on duty!*{color}
> {quote}_{color:#de350b}*When The Policeman is on duty, sit back, relax, and
> have some fun. Try to make some progress. Don't stress too much about the
> impact of your changes or maintaining stability and performance and
> correctness so much. Until the end of phase 1, I've got your back. I have a
> variety of tools and contraptions I have been building over the years and I
> will continue training them on this branch. I will review your changes and
> peer out across the land and course correct where needed. As Mike D will be
> thinking, "Sounds like a bottleneck Mark." And indeed it will be to some
> extent. Which is why once stage one is completed, I will flip The Policeman
> to off duty. When off duty, I'm always* {color:#de350b}*occasionally*{color}
> *down for some vigilante justice, but I won't be walking the beat, all that
> stuff about sit back and relax goes out the window.*{color}_
> {quote}
>
> I have stolen this title from Ishan or Noble and Ishan.
> This issue is meant to capture the work of a small team that is forming to
> push Solr and SolrCloud to the next phase.
> I have kicked off the work with an effort to create a very fast and solid
> base. That work is not 100% done, but it's ready to join the fight.
> Tim Potter has started giving me a tremendous hand in finishing up. Ishan and
> Noble have already contributed support and testing and have plans for
> additional work to shore up some of our current shortcomings.
> Others have expressed an interest in helping and hopefully they will pop up
> here as well.
> Let's organize and discuss our efforts here and in various sub issues.
--
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-14816) Bring back shard whitelisting feature
[ https://issues.apache.org/jira/browse/SOLR-14816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Robert Miller resolved SOLR-14816. --- Resolution: Fixed This is complete. > Bring back shard whitelisting feature > - > > Key: SOLR-14816 > URL: https://issues.apache.org/jira/browse/SOLR-14816 > Project: Solr > Issue Type: Sub-task >Reporter: Mark Robert Miller >Assignee: Noble Paul >Priority: Major > -- 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-14788) Solr: The Next Big Thing
[
https://issues.apache.org/jira/browse/SOLR-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Robert Miller reassigned SOLR-14788:
-
Assignee: Mark Robert Miller
> Solr: The Next Big Thing
>
>
> Key: SOLR-14788
> URL: https://issues.apache.org/jira/browse/SOLR-14788
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Critical
>
> h3.
> [!https://www.unicode.org/consortium/aacimg/1F46E.png!|https://www.unicode.org/consortium/adopted-characters.html#b1F46E]{color:#00875a}*The
> Policeman is on duty!*{color}
> {quote}_{color:#de350b}*When The Policeman is on duty, sit back, relax, and
> have some fun. Try to make some progress. Don't stress too much about the
> impact of your changes or maintaining stability and performance and
> correctness so much. Until the end of phase 1, I've got your back. I have a
> variety of tools and contraptions I have been building over the years and I
> will continue training them on this branch. I will review your changes and
> peer out across the land and course correct where needed. As Mike D will be
> thinking, "Sounds like a bottleneck Mark." And indeed it will be to some
> extent. Which is why once stage one is completed, I will flip The Policeman
> to off duty. When off duty, I'm always* {color:#de350b}*occasionally*{color}
> *down for some vigilante justice, but I won't be walking the beat, all that
> stuff about sit back and relax goes out the window.*{color}_
> {quote}
>
> I have stolen this title from Ishan or Noble and Ishan.
> This issue is meant to capture the work of a small team that is forming to
> push Solr and SolrCloud to the next phase.
> I have kicked off the work with an effort to create a very fast and solid
> base. That work is not 100% done, but it's ready to join the fight.
> Tim Potter has started giving me a tremendous hand in finishing up. Ishan and
> Noble have already contributed support and testing and have plans for
> additional work to shore up some of our current shortcomings.
> Others have expressed an interest in helping and hopefully they will pop up
> here as well.
> Let's organize and discuss our efforts here and in various sub issues.
--
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-14823) Allow Rule Based Replica Assignment Policy
[ https://issues.apache.org/jira/browse/SOLR-14823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213469#comment-17213469 ] Mark Robert Miller commented on SOLR-14823: --- I thought there was still a role based placement policy outside autoscaling - with snitches and what not? Didn't you build that? @Noble > Allow Rule Based Replica Assignment Policy > -- > > Key: SOLR-14823 > URL: https://issues.apache.org/jira/browse/SOLR-14823 > Project: Solr > Issue Type: Sub-task >Reporter: Mark Robert Miller >Priority: Major > > When I disabled the slow replica placement, at the time I also just skipped > the rule based policy - this should be allowed and those tests reenabled. -- 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-14823) Allow Rule Based Replica Assignment Policy
[ https://issues.apache.org/jira/browse/SOLR-14823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213473#comment-17213473 ] Noble Paul commented on SOLR-14823: --- This should be removed both from master & reference branch > Allow Rule Based Replica Assignment Policy > -- > > Key: SOLR-14823 > URL: https://issues.apache.org/jira/browse/SOLR-14823 > Project: Solr > Issue Type: Sub-task >Reporter: Mark Robert Miller >Priority: Major > > When I disabled the slow replica placement, at the time I also just skipped > the rule based policy - this should be allowed and those tests reenabled. -- 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-14654) Remove plugin loading from .system collection (for 9.0)
[ https://issues.apache.org/jira/browse/SOLR-14654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213477#comment-17213477 ] ASF subversion and git services commented on SOLR-14654: Commit 3c0b2b875f839317ee77552fcbfa6ff95a63e15f in lucene-solr's branch refs/heads/reference_impl_dev from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3c0b2b8 ] SOLR-14654: porting from faster > Remove plugin loading from .system collection (for 9.0) > --- > > Key: SOLR-14654 > URL: https://issues.apache.org/jira/browse/SOLR-14654 > Project: Solr > Issue Type: Task >Reporter: Noble Paul >Priority: Major > Fix For: master (9.0) > > Time Spent: 0.5h > Remaining Estimate: 0h > > This code must go from master > all places where "runtimeLib" can be used will be removed from 9.0 . With > the new package system in place we don;t need this anymore -- 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-14851) Http2SolrClient doesn't handle keystore type correctly
[
https://issues.apache.org/jira/browse/SOLR-14851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-14851:
Component/s: Server
> Http2SolrClient doesn't handle keystore type correctly
> --
>
> Key: SOLR-14851
> URL: https://issues.apache.org/jira/browse/SOLR-14851
> Project: Solr
> Issue Type: Bug
> Components: Server
>Reporter: Andras Salamon
>Priority: Major
> Attachments: SOLR-14851-01.patch
>
>
> I wanted to use Solr SSL using bcfks keystore type. Even after specifying the
> following JVM properties, Solr was not able to start:
> {{-Djavax.net.ssl.keyStoreType=bcfks -Djavax.net.ssl.trustStoreType=bcfks
> -Dsolr.jetty.truststore.type=bcfks -Dsolr.jetty.keystore.type=bcfks}}
> The error message in the log:
> {noformat}2020-09-07 14:42:29.429 ERROR (main) [ ] o.a.s.c.SolrCore
> null:org.apache.solr.common.SolrException: Error instantiating
> shardHandlerFactory class [HttpShardHandlerFactory]: java.io.IOException:
> Invalid keystore format
> at
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:56)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:660)
> at
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:262)
> at
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:182)
> at
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:134)
> at
> org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:751)
> at
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
> at
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
> at
> java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647)
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:360)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1445)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1409)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:822)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:275)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:524)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:46)
> at
> org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:188)
> at
> org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:513)
> at
> org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:154)
> at
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:173)
> at
> org.eclipse.jetty.deploy.providers.WebAppProvider.fileAdded(WebAppProvider.java:447)
> at
> org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:66)
> at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:784)
> at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:753)
> at org.eclipse.jetty.util.Scanner.scan(Scanner.java:641)
> at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:540)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:146)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:599)
> at
> org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:249)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at org.eclipse.jetty.server.Server.start(Server.java:407)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97)
> at org.eclipse.jetty.server.Server.doStart(Server.java:371)
>
[jira] [Updated] (SOLR-14851) Http2SolrClient doesn't handle keystore type correctly
[
https://issues.apache.org/jira/browse/SOLR-14851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-14851:
Fix Version/s: 8.7
master (9.0)
> Http2SolrClient doesn't handle keystore type correctly
> --
>
> Key: SOLR-14851
> URL: https://issues.apache.org/jira/browse/SOLR-14851
> Project: Solr
> Issue Type: Bug
> Components: Server
>Reporter: Andras Salamon
>Assignee: Kevin Risden
>Priority: Major
> Fix For: master (9.0), 8.7
>
> Attachments: SOLR-14851-01.patch
>
>
> I wanted to use Solr SSL using bcfks keystore type. Even after specifying the
> following JVM properties, Solr was not able to start:
> {{-Djavax.net.ssl.keyStoreType=bcfks -Djavax.net.ssl.trustStoreType=bcfks
> -Dsolr.jetty.truststore.type=bcfks -Dsolr.jetty.keystore.type=bcfks}}
> The error message in the log:
> {noformat}2020-09-07 14:42:29.429 ERROR (main) [ ] o.a.s.c.SolrCore
> null:org.apache.solr.common.SolrException: Error instantiating
> shardHandlerFactory class [HttpShardHandlerFactory]: java.io.IOException:
> Invalid keystore format
> at
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:56)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:660)
> at
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:262)
> at
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:182)
> at
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:134)
> at
> org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:751)
> at
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
> at
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
> at
> java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647)
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:360)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1445)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1409)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:822)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:275)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:524)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:46)
> at
> org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:188)
> at
> org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:513)
> at
> org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:154)
> at
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:173)
> at
> org.eclipse.jetty.deploy.providers.WebAppProvider.fileAdded(WebAppProvider.java:447)
> at
> org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:66)
> at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:784)
> at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:753)
> at org.eclipse.jetty.util.Scanner.scan(Scanner.java:641)
> at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:540)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:146)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:599)
> at
> org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:249)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at org.eclipse.jetty.server.Server.start(Server.java:407)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
> at
> org.eclipse.jetty.server.handler.AbstractHandle
[jira] [Assigned] (SOLR-14851) Http2SolrClient doesn't handle keystore type correctly
[
https://issues.apache.org/jira/browse/SOLR-14851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden reassigned SOLR-14851:
---
Assignee: Kevin Risden
> Http2SolrClient doesn't handle keystore type correctly
> --
>
> Key: SOLR-14851
> URL: https://issues.apache.org/jira/browse/SOLR-14851
> Project: Solr
> Issue Type: Bug
> Components: Server
>Reporter: Andras Salamon
>Assignee: Kevin Risden
>Priority: Major
> Attachments: SOLR-14851-01.patch
>
>
> I wanted to use Solr SSL using bcfks keystore type. Even after specifying the
> following JVM properties, Solr was not able to start:
> {{-Djavax.net.ssl.keyStoreType=bcfks -Djavax.net.ssl.trustStoreType=bcfks
> -Dsolr.jetty.truststore.type=bcfks -Dsolr.jetty.keystore.type=bcfks}}
> The error message in the log:
> {noformat}2020-09-07 14:42:29.429 ERROR (main) [ ] o.a.s.c.SolrCore
> null:org.apache.solr.common.SolrException: Error instantiating
> shardHandlerFactory class [HttpShardHandlerFactory]: java.io.IOException:
> Invalid keystore format
> at
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:56)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:660)
> at
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:262)
> at
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:182)
> at
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:134)
> at
> org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:751)
> at
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
> at
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
> at
> java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647)
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:360)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1445)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1409)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:822)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:275)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:524)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:46)
> at
> org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:188)
> at
> org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:513)
> at
> org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:154)
> at
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:173)
> at
> org.eclipse.jetty.deploy.providers.WebAppProvider.fileAdded(WebAppProvider.java:447)
> at
> org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:66)
> at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:784)
> at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:753)
> at org.eclipse.jetty.util.Scanner.scan(Scanner.java:641)
> at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:540)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:146)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:599)
> at
> org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:249)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at org.eclipse.jetty.server.Server.start(Server.java:407)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97)
> at org.eclipse.jett
[jira] [Updated] (SOLR-14887) Upgrade JQuery to 3.5.1
[ https://issues.apache.org/jira/browse/SOLR-14887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-14887: Fix Version/s: 8.7 master (9.0) > Upgrade JQuery to 3.5.1 > --- > > Key: SOLR-14887 > URL: https://issues.apache.org/jira/browse/SOLR-14887 > Project: Solr > Issue Type: Task > Components: Admin UI >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: master (9.0), 8.7 > > Time Spent: 10m > Remaining Estimate: 0h > > The Solr admin UI currently uses JQuery 3.4.1 (SOLR-14209). JQuery 3.5.1 is > out and addresses some security vulnerabilities. It would be good to upgrade. -- 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-14887) Upgrade JQuery to 3.5.1
[ https://issues.apache.org/jira/browse/SOLR-14887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden reassigned SOLR-14887: --- Assignee: Kevin Risden > Upgrade JQuery to 3.5.1 > --- > > Key: SOLR-14887 > URL: https://issues.apache.org/jira/browse/SOLR-14887 > Project: Solr > Issue Type: Task > Components: Admin UI >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The Solr admin UI currently uses JQuery 3.4.1 (SOLR-14209). JQuery 3.5.1 is > out and addresses some security vulnerabilities. It would be good to upgrade. -- 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] risdenk merged pull request #1947: SOLR-14887 Upgrade JQuery to 3.5.1
risdenk merged pull request #1947: URL: https://github.com/apache/lucene-solr/pull/1947 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-14887) Upgrade JQuery to 3.5.1
[ https://issues.apache.org/jira/browse/SOLR-14887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213486#comment-17213486 ] ASF subversion and git services commented on SOLR-14887: Commit cf6e83139410427ac975cf0d4c3c0d57a7d41acc in lucene-solr's branch refs/heads/master from gezapeti [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=cf6e831 ] SOLR-14887 Upgrade JQuery to 3.5.1 (#1947) > Upgrade JQuery to 3.5.1 > --- > > Key: SOLR-14887 > URL: https://issues.apache.org/jira/browse/SOLR-14887 > Project: Solr > Issue Type: Task > Components: Admin UI >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: master (9.0) > > Time Spent: 20m > Remaining Estimate: 0h > > The Solr admin UI currently uses JQuery 3.4.1 (SOLR-14209). JQuery 3.5.1 is > out and addresses some security vulnerabilities. It would be good to upgrade. -- 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-14887) Upgrade JQuery to 3.5.1
[ https://issues.apache.org/jira/browse/SOLR-14887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-14887: Fix Version/s: (was: 8.7) > Upgrade JQuery to 3.5.1 > --- > > Key: SOLR-14887 > URL: https://issues.apache.org/jira/browse/SOLR-14887 > Project: Solr > Issue Type: Task > Components: Admin UI >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: master (9.0) > > Time Spent: 10m > Remaining Estimate: 0h > > The Solr admin UI currently uses JQuery 3.4.1 (SOLR-14209). JQuery 3.5.1 is > out and addresses some security vulnerabilities. It would be good to upgrade. -- 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-14851) Http2SolrClient doesn't handle keystore type correctly
[
https://issues.apache.org/jira/browse/SOLR-14851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-14851:
Fix Version/s: (was: 8.7)
(was: master (9.0))
> Http2SolrClient doesn't handle keystore type correctly
> --
>
> Key: SOLR-14851
> URL: https://issues.apache.org/jira/browse/SOLR-14851
> Project: Solr
> Issue Type: Bug
> Components: Server
>Reporter: Andras Salamon
>Assignee: Kevin Risden
>Priority: Major
> Attachments: SOLR-14851-01.patch
>
>
> I wanted to use Solr SSL using bcfks keystore type. Even after specifying the
> following JVM properties, Solr was not able to start:
> {{-Djavax.net.ssl.keyStoreType=bcfks -Djavax.net.ssl.trustStoreType=bcfks
> -Dsolr.jetty.truststore.type=bcfks -Dsolr.jetty.keystore.type=bcfks}}
> The error message in the log:
> {noformat}2020-09-07 14:42:29.429 ERROR (main) [ ] o.a.s.c.SolrCore
> null:org.apache.solr.common.SolrException: Error instantiating
> shardHandlerFactory class [HttpShardHandlerFactory]: java.io.IOException:
> Invalid keystore format
> at
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:56)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:660)
> at
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:262)
> at
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:182)
> at
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:134)
> at
> org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:751)
> at
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
> at
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
> at
> java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647)
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:360)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1445)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1409)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:822)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:275)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:524)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:46)
> at
> org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:188)
> at
> org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:513)
> at
> org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:154)
> at
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:173)
> at
> org.eclipse.jetty.deploy.providers.WebAppProvider.fileAdded(WebAppProvider.java:447)
> at
> org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:66)
> at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:784)
> at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:753)
> at org.eclipse.jetty.util.Scanner.scan(Scanner.java:641)
> at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:540)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:146)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:599)
> at
> org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:249)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at org.eclipse.jetty.server.Server.start(Server.java:407)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHan
[jira] [Resolved] (SOLR-14887) Upgrade JQuery to 3.5.1
[ https://issues.apache.org/jira/browse/SOLR-14887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden resolved SOLR-14887. - Resolution: Fixed Thanks [~gezapeti]! > Upgrade JQuery to 3.5.1 > --- > > Key: SOLR-14887 > URL: https://issues.apache.org/jira/browse/SOLR-14887 > Project: Solr > Issue Type: Task > Components: Admin UI >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: master (9.0), 8.7 > > Time Spent: 20m > Remaining Estimate: 0h > > The Solr admin UI currently uses JQuery 3.4.1 (SOLR-14209). JQuery 3.5.1 is > out and addresses some security vulnerabilities. It would be good to upgrade. -- 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-14887) Upgrade JQuery to 3.5.1
[ https://issues.apache.org/jira/browse/SOLR-14887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-14887: Fix Version/s: 8.7 > Upgrade JQuery to 3.5.1 > --- > > Key: SOLR-14887 > URL: https://issues.apache.org/jira/browse/SOLR-14887 > Project: Solr > Issue Type: Task > Components: Admin UI >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: master (9.0), 8.7 > > Time Spent: 20m > Remaining Estimate: 0h > > The Solr admin UI currently uses JQuery 3.4.1 (SOLR-14209). JQuery 3.5.1 is > out and addresses some security vulnerabilities. It would be good to upgrade. -- 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-14887) Upgrade JQuery to 3.5.1
[ https://issues.apache.org/jira/browse/SOLR-14887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213487#comment-17213487 ] ASF subversion and git services commented on SOLR-14887: Commit 4df929d1fd1432922a50c5fc699ee7e6f1ec81b7 in lucene-solr's branch refs/heads/branch_8x from gezapeti [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4df929d ] SOLR-14887 Upgrade JQuery to 3.5.1 (#1947) > Upgrade JQuery to 3.5.1 > --- > > Key: SOLR-14887 > URL: https://issues.apache.org/jira/browse/SOLR-14887 > Project: Solr > Issue Type: Task > Components: Admin UI >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: master (9.0) > > Time Spent: 20m > Remaining Estimate: 0h > > The Solr admin UI currently uses JQuery 3.4.1 (SOLR-14209). JQuery 3.5.1 is > out and addresses some security vulnerabilities. It would be good to upgrade. -- 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-14654) Remove plugin loading from .system collection (for 9.0)
[ https://issues.apache.org/jira/browse/SOLR-14654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213489#comment-17213489 ] ASF subversion and git services commented on SOLR-14654: Commit 03fe8e52609a76572a1e39084a2f75471c65614e in lucene-solr's branch refs/heads/master from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=03fe8e5 ] SOLR-14654: remove ref guide refernces > Remove plugin loading from .system collection (for 9.0) > --- > > Key: SOLR-14654 > URL: https://issues.apache.org/jira/browse/SOLR-14654 > Project: Solr > Issue Type: Task >Reporter: Noble Paul >Priority: Major > Fix For: master (9.0) > > Time Spent: 0.5h > Remaining Estimate: 0h > > This code must go from master > all places where "runtimeLib" can be used will be removed from 9.0 . With > the new package system in place we don;t need this anymore -- 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-14654) Remove plugin loading from .system collection (for 9.0)
[ https://issues.apache.org/jira/browse/SOLR-14654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213497#comment-17213497 ] ASF subversion and git services commented on SOLR-14654: Commit 2f651b156c47080c5a857378546ae9693dd60656 in lucene-solr's branch refs/heads/master from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2f651b1 ] SOLR-14654: remove all references of runtime lib > Remove plugin loading from .system collection (for 9.0) > --- > > Key: SOLR-14654 > URL: https://issues.apache.org/jira/browse/SOLR-14654 > Project: Solr > Issue Type: Task >Reporter: Noble Paul >Priority: Major > Fix For: master (9.0) > > Time Spent: 0.5h > Remaining Estimate: 0h > > This code must go from master > all places where "runtimeLib" can be used will be removed from 9.0 . With > the new package system in place we don;t need this anymore -- 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-14654) Remove plugin loading from .system collection (for 9.0)
[ https://issues.apache.org/jira/browse/SOLR-14654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213498#comment-17213498 ] ASF subversion and git services commented on SOLR-14654: Commit c111ba7d5222ac97c2ccf7097634d9b0f482431a in lucene-solr's branch refs/heads/reference_impl_dev from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c111ba7 ] SOLR-14654: remove ref guide refernces > Remove plugin loading from .system collection (for 9.0) > --- > > Key: SOLR-14654 > URL: https://issues.apache.org/jira/browse/SOLR-14654 > Project: Solr > Issue Type: Task >Reporter: Noble Paul >Priority: Major > Fix For: master (9.0) > > Time Spent: 0.5h > Remaining Estimate: 0h > > This code must go from master > all places where "runtimeLib" can be used will be removed from 9.0 . With > the new package system in place we don;t need this anymore -- 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-14654) Remove plugin loading from .system collection (for 9.0)
[ https://issues.apache.org/jira/browse/SOLR-14654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213499#comment-17213499 ] ASF subversion and git services commented on SOLR-14654: Commit e9aea61f8bc5447fa46a18e736ff7c1a2a054319 in lucene-solr's branch refs/heads/reference_impl_dev from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e9aea61 ] SOLR-14654: remove all references of runtime lib > Remove plugin loading from .system collection (for 9.0) > --- > > Key: SOLR-14654 > URL: https://issues.apache.org/jira/browse/SOLR-14654 > Project: Solr > Issue Type: Task >Reporter: Noble Paul >Priority: Major > Fix For: master (9.0) > > Time Spent: 0.5h > Remaining Estimate: 0h > > This code must go from master > all places where "runtimeLib" can be used will be removed from 9.0 . With > the new package system in place we don;t need this anymore -- 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-14549) Listing of Files in a Directory on Solr Admin is Broken
[ https://issues.apache.org/jira/browse/SOLR-14549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213513#comment-17213513 ] Kevin Risden commented on SOLR-14549: - Ok well took a bit more time to get back to this. I can definitely see this is happening AND I can see kinda what is going on. Somehow the data being loaded isn't loaded "in time" it looks like. If I hardcode a set of children in https://github.com/apache/lucene-solr/blob/master/solr/webapp/web/js/angular/controllers/files.js#L62 then the tree displays properly. It is almost like things are happening out of order. If I add console.log statements I can see them happening in an order that doesn't make sense to me. So once I fix the ordering or loading of the changed data - then should be good to go. > Listing of Files in a Directory on Solr Admin is Broken > --- > > Key: SOLR-14549 > URL: https://issues.apache.org/jira/browse/SOLR-14549 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: master (9.0), 8.5.1, 8.5.2 >Reporter: David Eric Pugh >Assignee: Kevin Risden >Priority: Major > Attachments: Screenshot at Jun 09 07-40-06.png > > > The Admin interface for showing files only lets you see the top level files, > no nested files in a directory: > http://localhost:8983/solr/#/gettingstarted/files?file=lang%2F > Choosing a nested directory doesn't generate any console errors, but the tree > doesn't open. > I believe this was introduced during SOLR-14209 upgrade in Jquery. -- 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-9568) FuzzyTermEnums sets negative boost for fuzzy search & highlight
[
https://issues.apache.org/jira/browse/LUCENE-9568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213514#comment-17213514
]
Michael Sokolov commented on LUCENE-9568:
-
> Hopefully I have explained it ok, this thing is hairy Happy to try again if
> needed.
Thanks [~rcmuir] that helps; I think true understanding would require me to
bang my head on the code though :)
> FuzzyTermEnums sets negative boost for fuzzy search & highlight
> ---
>
> Key: LUCENE-9568
> URL: https://issues.apache.org/jira/browse/LUCENE-9568
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/highlighter
>Affects Versions: 8.5.1
>Reporter: Juraj Jurčo
>Priority: Minor
> Labels: highlighting, newbie
> Attachments: FindSqlHighlightTest.java
>
>
> *Description*
> When user indexes a word with an apostrophe and constructs a fuzzy query for
> highlighter, it throws an exception with set negative boost for a query.
> *Repro Steps*
> # Index a text with apostrophe. E.g. doesn't
> # Parse a fuzzy query e.g.: se~, se~2, se~3
> # Try to highlight a text with apostrophe
> # The exception is thrown (for details see attached test test with repro
> steps)
> *Actual Result*
> {{java.lang.IllegalArgumentException: boost must be a positive float, got
> -1.0}}
> *Expected Result*
> * No exception.
> * Highlighting marks are inserted into a text.
> *Workaround*
> - not known.
--
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-14549) Listing of Files in a Directory on Solr Admin is Broken
[ https://issues.apache.org/jira/browse/SOLR-14549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213551#comment-17213551 ] Kevin Risden commented on SOLR-14549: - So I'm about 80% sure that it has something to do with the Files.list and recursively trying to build up the children for jstree. The children array is being modified in the recursive process call and somehow this gets all out of order. I'll need to stare at it again another day. > Listing of Files in a Directory on Solr Admin is Broken > --- > > Key: SOLR-14549 > URL: https://issues.apache.org/jira/browse/SOLR-14549 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: master (9.0), 8.5.1, 8.5.2 >Reporter: David Eric Pugh >Assignee: Kevin Risden >Priority: Major > Attachments: Screenshot at Jun 09 07-40-06.png > > > The Admin interface for showing files only lets you see the top level files, > no nested files in a directory: > http://localhost:8983/solr/#/gettingstarted/files?file=lang%2F > Choosing a nested directory doesn't generate any console errors, but the tree > doesn't open. > I believe this was introduced during SOLR-14209 upgrade in Jquery. -- 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] gus-asf opened a new pull request #1979: LUCENE-9574 Add DropIfFlaggedFilterFactory
gus-asf opened a new pull request #1979: URL: https://github.com/apache/lucene-solr/pull/1979 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] gus-asf commented on pull request #1965: LUCENE-9572 - TypeAsSynonymFilter gains selective flag transfer and an ignore list.
gus-asf commented on pull request #1965: URL: https://github.com/apache/lucene-solr/pull/1965#issuecomment-708144706 @sarowe do you have any comments? 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] noblepaul commented on pull request #1945: SOLR-14680: revert from 8x
noblepaul commented on pull request #1945: URL: https://github.com/apache/lucene-solr/pull/1945#issuecomment-708192186 As requested by @sigram I'm reverting this from 8x 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] noblepaul merged pull request #1945: SOLR-14680: revert from 8x
noblepaul merged pull request #1945: URL: https://github.com/apache/lucene-solr/pull/1945 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-14680) Provide simple interfaces to our concrete SolrCloud classes
[ https://issues.apache.org/jira/browse/SOLR-14680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213657#comment-17213657 ] ASF subversion and git services commented on SOLR-14680: Commit 75aa234c0eb1c76ee0e6d7cc39ddfd15d2330e08 in lucene-solr's branch refs/heads/branch_8x from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=75aa234 ] SOLR-14680: revert from 8x (#1945) > Provide simple interfaces to our concrete SolrCloud classes > --- > > Key: SOLR-14680 > URL: https://issues.apache.org/jira/browse/SOLR-14680 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > Labels: clean-api > Time Spent: 11h > Remaining Estimate: 0h > > All our current implementations of SolrCloud such as > # ClusterState > # DocCollection > # Slice > # Replica > etc are concrete classes. Providing alternate implementations or wrappers is > extremely difficult. > SOLR-14613 is attempting to create such interfaces to make their sdk simpler > The objective is not to have a comprehensive set of methods in these > interfaces. We will start out with a subset of required interfaces. We > guarantee is that signatures of methods in these interfaces will not be > deleted/changed . But we may add more methods as and when it suits us -- 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-14930) Deprecate rulebased replica placement starategy
Noble Paul created SOLR-14930: - Summary: Deprecate rulebased replica placement starategy Key: SOLR-14930 URL: https://issues.apache.org/jira/browse/SOLR-14930 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul Assignee: Noble Paul This should be removed from 9.0 -- 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
