[jira] [Updated] (SOLR-14317) HttpClusterStateProvider throws exception when only one node down
[ https://issues.apache.org/jira/browse/SOLR-14317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyle updated SOLR-14317: Attachment: SOLR-14317.patch > HttpClusterStateProvider throws exception when only one node down > - > > Key: SOLR-14317 > URL: https://issues.apache.org/jira/browse/SOLR-14317 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 7.7.1, 7.7.2 >Reporter: Lyle >Assignee: Ishan Chattopadhyaya >Priority: Major > Attachments: SOLR-14317.patch > > Time Spent: 10m > Remaining Estimate: 0h > > When create a CloudSolrClient with solrUrls, if the first url in the solrUrls > list is invalid or server is down, it will throw exception directly rather > than try remaining url. > In > [https://github.com/apache/lucene-solr/blob/branch_7_7/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpClusterStateProvider.java#L65], > if fetchLiveNodes(initialClient) have any IOException, in > [https://github.com/apache/lucene-solr/blob/branch_7_7/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java#L648], > exceptions will be caught and throw SolrServerException to the upper caller, > while no IOExceptioin will be caught in > HttpClusterStateProvider.fetchLiveNodes(HttpClusterStateProvider.java:200). > The SolrServerException should be caught as well in > [https://github.com/apache/lucene-solr/blob/branch_7_7/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpClusterStateProvider.java#L69], > so that if first node provided in solrUrs down, we can try to use the second > to fetch live nodes. > > -- 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-14317) HttpClusterStateProvider throws exception when only one node down
[ https://issues.apache.org/jira/browse/SOLR-14317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyle updated SOLR-14317: Attachment: (was: SOLR-14317) > HttpClusterStateProvider throws exception when only one node down > - > > Key: SOLR-14317 > URL: https://issues.apache.org/jira/browse/SOLR-14317 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 7.7.1, 7.7.2 >Reporter: Lyle >Assignee: Ishan Chattopadhyaya >Priority: Major > Attachments: SOLR-14317.patch > > Time Spent: 10m > Remaining Estimate: 0h > > When create a CloudSolrClient with solrUrls, if the first url in the solrUrls > list is invalid or server is down, it will throw exception directly rather > than try remaining url. > In > [https://github.com/apache/lucene-solr/blob/branch_7_7/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpClusterStateProvider.java#L65], > if fetchLiveNodes(initialClient) have any IOException, in > [https://github.com/apache/lucene-solr/blob/branch_7_7/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java#L648], > exceptions will be caught and throw SolrServerException to the upper caller, > while no IOExceptioin will be caught in > HttpClusterStateProvider.fetchLiveNodes(HttpClusterStateProvider.java:200). > The SolrServerException should be caught as well in > [https://github.com/apache/lucene-solr/blob/branch_7_7/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpClusterStateProvider.java#L69], > so that if first node provided in solrUrs down, we can try to use the second > to fetch live nodes. > > -- 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-14317) HttpClusterStateProvider throws exception when only one node down
[ https://issues.apache.org/jira/browse/SOLR-14317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyle updated SOLR-14317: Attachment: SOLR-14317 > HttpClusterStateProvider throws exception when only one node down > - > > Key: SOLR-14317 > URL: https://issues.apache.org/jira/browse/SOLR-14317 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 7.7.1, 7.7.2 >Reporter: Lyle >Assignee: Ishan Chattopadhyaya >Priority: Major > Attachments: SOLR-14317 > > Time Spent: 10m > Remaining Estimate: 0h > > When create a CloudSolrClient with solrUrls, if the first url in the solrUrls > list is invalid or server is down, it will throw exception directly rather > than try remaining url. > In > [https://github.com/apache/lucene-solr/blob/branch_7_7/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpClusterStateProvider.java#L65], > if fetchLiveNodes(initialClient) have any IOException, in > [https://github.com/apache/lucene-solr/blob/branch_7_7/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java#L648], > exceptions will be caught and throw SolrServerException to the upper caller, > while no IOExceptioin will be caught in > HttpClusterStateProvider.fetchLiveNodes(HttpClusterStateProvider.java:200). > The SolrServerException should be caught as well in > [https://github.com/apache/lucene-solr/blob/branch_7_7/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpClusterStateProvider.java#L69], > so that if first node provided in solrUrs down, we can try to use the second > to fetch live nodes. > > -- 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-13101) Shared storage support in SolrCloud
[ https://issues.apache.org/jira/browse/SOLR-13101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16926158#comment-16926158 ] Megan Carey edited comment on SOLR-13101 at 3/12/20, 4:33 AM: -- h2. SolrCloud + Blobstore I've attached a PR containing all of the existing blobstore code to this Jira ([https://github.com/apache/lucene-solr/pull/864]). The following description can be found in that PR description, and in my branch under lucene-solr/solr/README-BLOB.md. I'm posting it here as well for extra visibility. h3. Overview This repo introduces a new framework which allows SolrCloud to integrate with an external (typically cloud-based) blobstore. Instead of maintaining a copy of the index on each Solr host, replicating updates to peers, and using a transaction log to maintain consistent ordered updates, Solr hosts will push and pull cores to/from this external store. TL;DR: For now, SolrCloud can be configured to use blobstore at a collection level. Collections backed by blobstore use a new SHARED replica type. When a Solr node makes an update request to a shared shard, it indexes locally and then pushes the change through to a shared blobstore. Zookeeper manages index versioning and provides a source of truth in the case of concurrent writes. Solr nodes in a cluster will no longer use peer-to-peer replication, and instead will pull updates directly from the shared blobstore. Please note that this project is a work in progress, and is by no means production-ready. This code is being published early get feedback, which we will incorporate in future work. In order to modularize these changes and maintain existing functionality, most of the blobstore-related code is isolated to the _solr/core/src/java/org/apache/solr/store/blob directory_. However, there some key integration touchpoints in _HttpSolrCall#init_, _DistributedZkUpdateProcessor_, and _CoreContainer#load_. These classes all have special handling for blobstore-based shards. h3. Pulling from Blobstore Core pulls are, for the most part, asynchronous. When a replica is queried, it enqueues a pull from blobstore but doesn’t wait for the pull to complete before it executes the query, unless the replica is missing a copy of that core altogether. If your operation requires that local cores are in-sync with blobstore, use the method _BlobStoreUtils#syncLocalCoreWithSharedStore_. A more in-depth walkthrough of the pull code: * _BlobCoreSyncer_: manages threads that sync between local and blob store, so that if a pull is in progress, we do not create duplicate work. * Calls into _CorePullTracker_: creates _PullCoreInfo_ object containing data about the core to be pulled and adds to a deduplicated list. * This queue of pull objects is polled by the _CorePullerFeeder_, which uses threads from its dedicated thread pool to execute CorePullTasks. * _CorePullTask_: checks if a pull is already underway for this core; if not, executes a pull from blob store. Resolves differences between blob’s version of the core and local version, and stores the updated core h3. Pushing to Blobstore This happens synchronously. On every local commit, we push to blobstore and only ack that the update was successful when it is committed both locally and in the shared store. A more in-depth walkthrough of the push code: * _DistributedZkUpdateProcessor_: once a commit is complete for a _SHARED_ replica (_onFinish_), we _writeToShareStore_. * This calls into _CoreUpdateTracker_, which creates a _PushPullData_ object containing data about the collection, core, and most recently pulled version of the core on this replica. * _CorePusher_: resolves the differences between blob’s version of the core and local version, and pushes the updated version to blob store h3. Resolving Local and Blobstore The _SharedStoreResolutionUtil_ handles resolving diffs between the Solr node’s local copy of a core and the copy in blobstore. It does so by pulling the metadata for the core from blobstore (_BlobCoreMetadata_), comparing against the local metadata (_ServerSideMetadata_), and creating a list of segments to push or pull. h3. Version Management Only the leader node can push updates to blobstore. Because a new leader can be elected at any time, there is still a possibility for race conditions on writes to blobstore. In order to maintain a consistent global view of the latest version of a core, we keep version data in Zookeeper. Zookeeper stores this version data as a random string called _metadataSuffix_. When a SolrCloud node makes an update request, it first pushes the files to blobstore and then makes a conditional update to the metadataSuffix variable. If Zookeeper rejects the conditional update, the update request fails, and the failure is propagated back to the client. This communication with Zookeeper is coordinated in t
[jira] [Updated] (SOLR-14197) Reduce API of SolrResourceLoader
[ https://issues.apache.org/jira/browse/SOLR-14197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-14197: Description: SolrResourceLoader must exist as an implementation of Lucene ResourceLoader. Over time it has grown a lot more methods that are beyond the scope of doing just that. I think SRL should be simplified to get back to its core necessity, which hopefully allows us to make other changes (either in SRL or nearby) with less entanglement. Some API creep: * listConfigDir _(not used)_ * newAdminHandlerInstance _(not used)_ * getDataDir * getCoreName _(only used for logging)_ * getCoreProperties * openSchema and configSchema _(not needed; barely used)_ EDIT: The following to be done in a follow-up issue: Some methods ought to go to a new subclass of SolrResourceLoader that is specifically for a standalone-mode core: * resourceLocation * getConfigDir * getInstancePath * persistConfLocally was: SolrResourceLoader must exist as an implementation of Lucene ResourceLoader. Over time it has grown a lot more methods that are beyond the scope of doing just that. I think SRL should be simplified to get back to its core necessity, which hopefully allows us to make other changes (either in SRL or nearby) with less entanglement. Some API creep: * listConfigDir _(not used)_ * newAdminHandlerInstance _(not used)_ * getDataDir * getCoreName _(only used for logging)_ * getCoreProperties * openSchema and configSchema _(not needed; barely used)_ Some methods ought to go to a new subclass of SolrResourceLoader that is specifically for a standalone-mode core: * resourceLocation * getConfigDir * getInstancePath * persistConfLocally > Reduce API of SolrResourceLoader > > > Key: SOLR-14197 > URL: https://issues.apache.org/jira/browse/SOLR-14197 > Project: Solr > Issue Type: Improvement >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Fix For: 8.6 > > Time Spent: 3h 50m > Remaining Estimate: 0h > > SolrResourceLoader must exist as an implementation of Lucene ResourceLoader. > Over time it has grown a lot more methods that are beyond the scope of doing > just that. I think SRL should be simplified to get back to its core > necessity, which hopefully allows us to make other changes (either in SRL or > nearby) with less entanglement. Some API creep: > * listConfigDir _(not used)_ > * newAdminHandlerInstance _(not used)_ > * getDataDir > * getCoreName _(only used for logging)_ > * getCoreProperties > * openSchema and configSchema _(not needed; barely used)_ > EDIT: The following to be done in a follow-up issue: > Some methods ought to go to a new subclass of SolrResourceLoader that is > specifically for a standalone-mode core: > * resourceLocation > * getConfigDir > * getInstancePath > * persistConfLocally -- 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-14197) Reduce API of SolrResourceLoader
[ https://issues.apache.org/jira/browse/SOLR-14197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved SOLR-14197. - Fix Version/s: 8.6 Resolution: Fixed The work committed here is capped to the first list in the description -- that which can be done well without changing the class hierarchy. Master (9.0) removes the methods but they remain in 8.x as deprecated. When ready I'll file a new issue to link here pertaining to the SRL hierarchy. That'll be necessary to move off getConfigDir and getInstancePath and will probably allow further improvements. > Reduce API of SolrResourceLoader > > > Key: SOLR-14197 > URL: https://issues.apache.org/jira/browse/SOLR-14197 > Project: Solr > Issue Type: Improvement >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Fix For: 8.6 > > Time Spent: 3h 50m > Remaining Estimate: 0h > > SolrResourceLoader must exist as an implementation of Lucene ResourceLoader. > Over time it has grown a lot more methods that are beyond the scope of doing > just that. I think SRL should be simplified to get back to its core > necessity, which hopefully allows us to make other changes (either in SRL or > nearby) with less entanglement. Some API creep: > * listConfigDir _(not used)_ > * newAdminHandlerInstance _(not used)_ > * getDataDir > * getCoreName _(only used for logging)_ > * getCoreProperties > * openSchema and configSchema _(not needed; barely used)_ > Some methods ought to go to a new subclass of SolrResourceLoader that is > specifically for a standalone-mode core: > * resourceLocation > * getConfigDir > * getInstancePath > * persistConfLocally -- 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-7435) NPE can occur if CollapsingQParserPlugin is used two or more times in the same query
[
https://issues.apache.org/jira/browse/SOLR-7435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057554#comment-17057554
]
Munendra S N commented on SOLR-7435:
Based on description, SOLR-14073 should resolve this?
[~jbernste]
> NPE can occur if CollapsingQParserPlugin is used two or more times in the
> same query
>
>
> Key: SOLR-7435
> URL: https://issues.apache.org/jira/browse/SOLR-7435
> Project: Solr
> Issue Type: Bug
>Affects Versions: 4.8.1, 4.9.1, 4.10.1, 4.10.3, 4.10.4, 5.1, 5.2, 5.2.1,
> 5.3
>Reporter: Markus Jelsma
>Priority: Minor
> Fix For: 5.5
>
>
> The problem is that Solr 4.10.3,
> CollapsingFieldValueCollector.finish(CollapsingQParserPlugin.java:632) is
> looking ahead to the next segment. When you use the CollapsingQParser only
> once that look-ahead is always populated because each segment is processed by
> the scorers. The CollapsingQParser plugin does not process every segment
> though, it stops when it runs out of documents that have been collected. So
> the look-ahead can cause a null pointer in the second Collapse. This is a
> problem in every version of the CollapsingQParserPlugin.
> Below is the original description from Markus which is another NPE during a
> look-ahead in Solr 5.1:
> Not even sure it would work anyway, i tried to collapse on two distinct
> fields, ending up with this:
> select?q=*:*&fq={!collapse field=qst}&fq={!collapse field=rdst}
> {code}
> 584550 [qtp1121454968-20] ERROR org.apache.solr.servlet.SolrDispatchFilter [
> suggests] – null:java.lang.NullPointerException
> at
> org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:743)
> at
> org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:780)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:203)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1660)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1479)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:556)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:518)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:222)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1984)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:829)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:446)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> at org.eclipse.jetty.server.Server.handle(Server.java:368)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
> at
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
> at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParse
[jira] [Commented] (SOLR-10336) NPE during queryCache warming
[
https://issues.apache.org/jira/browse/SOLR-10336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057552#comment-17057552
]
Munendra S N commented on SOLR-10336:
-
Based on description, this too looks like issue was caused to multiple
collapse. [~jbernste] With SOLR-14073, should we resolve this?
> NPE during queryCache warming
> -
>
> Key: SOLR-10336
> URL: https://issues.apache.org/jira/browse/SOLR-10336
> Project: Solr
> Issue Type: Bug
>Affects Versions: 6.4.2
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 7.0
>
>
> Regular cache warming stumbles on this NPE. It seems to be related to
> SOLR-9104, it is the same collection and the query that fails the cache
> warmer is similar to that of SOLR-9104, i.e, two CollapsingQParsers.
> {code}
> Error during auto-warming of
> key:org.apache.solr.search.QueryResultKey@fe9769ca:java.lang.NullPointerException
> at
> org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:816)
> at
> org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:853)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:256)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1823)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1640)
> at
> org.apache.solr.search.SolrIndexSearcher.lambda$initRegenerators$3(SolrIndexSearcher.java:604)
> at org.apache.solr.search.LFUCache.warm(LFUCache.java:188)
> at
> org.apache.solr.search.SolrIndexSearcher.warm(SolrIndexSearcher.java:2376)
> at
> org.apache.solr.core.SolrCore.lambda$getSearcher$2(SolrCore.java:2054)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-9104) NPE in CollapsingQParser when two fq={!collapse} and zero results
[
https://issues.apache.org/jira/browse/SOLR-9104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057547#comment-17057547
]
Munendra S N commented on SOLR-9104:
[~jbernste]
I think with SOLR-14073 this should be resolved. So, should we close this?
> NPE in CollapsingQParser when two fq={!collapse} and zero results
> -
>
> Key: SOLR-9104
> URL: https://issues.apache.org/jira/browse/SOLR-9104
> Project: Solr
> Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 6.2, 7.0
>
>
> This is a very weird problem that is reproducible on a small production
> server, but not on the local machine although they run the same 6.0 version.,
> and have an almost identical index. The only minor difference is that
> production is a SolrCloud with 1 shard and two replica's, just for a bit of
> redundancy.
> The following query yields zero results and throws the NPE:
> {code}
> select?q=query:seis&fq={!collapse field=query_digest}&fq={!collapse
> field=result_digest}
> {code}
> The next query does yield results and does not throw anything, it just works
> as it should work:
> {code}
> select?q=query:seiz&fq={!collapse field=query_digest}&fq={!collapse
> field=result_digest}
> {code}
> The /select handler used does not add any fancy param other than rows.
> Here's the NPE:
> {code}
> 2016-05-11 14:10:27.666 ERROR (qtp1209271652-3338) [c:suggestions s:shard1
> r:core_node1 x:suggestions_shard1_replica1] o.a.s.s.HttpSolrCall
> null:java.lang.NullPointerException
> at
> org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:814)
> at
> org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:851)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:272)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1794)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1611)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:634)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:529)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:287)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> {code}
> Edit: for the sake of clarity. It really needs double fq={!collapse bla bla
> for the NPE to appear. If i remove either of the filters from the query, i
> get a nice zero resultset back. Both fields are defined as int.
--
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-13944) CollapsingQParserPlugin throws NPE instead of bad request
[
https://issues.apache.org/jira/browse/SOLR-13944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057545#comment-17057545
]
Munendra S N commented on SOLR-13944:
-
[~jbernste] [~tflobbe]
I have one quick question. Here, in the collator we are just computing hits and
so, should we consider postFilter like collapse here or just ignore it?
Essentially question is which hits to consider the without collapse one or
with collapse?
> CollapsingQParserPlugin throws NPE instead of bad request
> -
>
> Key: SOLR-13944
> URL: https://issues.apache.org/jira/browse/SOLR-13944
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.3.1
>Reporter: Stefan
>Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-13944.patch, SOLR-13944.patch, SOLR-13944.patch,
> SOLR-13944.patch
>
>
> I noticed the following NPE:
> {code:java}
> java.lang.NullPointerException at
> org.apache.solr.search.CollapsingQParserPlugin$OrdFieldValueCollector.finish(CollapsingQParserPlugin.java:1021)
> at
> org.apache.solr.search.CollapsingQParserPlugin$OrdFieldValueCollector.finish(CollapsingQParserPlugin.java:1081)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:230)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1602)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1419)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:584)
> {code}
> If I am correct, the problem was already addressed in SOLR-8807. The fix does
> was not working in this case though, because of a syntax error in the query
> (I used the local parameter syntax twice instead of combining it). The
> relevant part of the query is:
> {code:java}
> &fq={!tag=collapser}{!collapse field=productId sort='merchantOrder asc, price
> asc, id asc'}
> {code}
> After discussing that on the mailing list, I was asked to open a ticket,
> because this situation should result in a bad request instead of a
> NullpointerException (see
> [https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201911.mbox/%3CCAMJgJxTuSb%3D8szO8bvHiAafJOs08O_NMB4pcaHOXME4Jj-GO2A%40mail.gmail.com%3E])
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on issue #1332: SOLR-14254: Docs for text tagger: FST50 trade-off
dsmiley commented on issue #1332: SOLR-14254: Docs for text tagger: FST50 trade-off URL: https://github.com/apache/lucene-solr/pull/1332#issuecomment-597978433 I thought it'd be good to add a solr-upgrade-notes warning too, both in 8.4 and 8.5 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13944) CollapsingQParserPlugin throws NPE instead of bad request
[
https://issues.apache.org/jira/browse/SOLR-13944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057532#comment-17057532
]
Munendra S N commented on SOLR-13944:
-
[^SOLR-13944.patch] removes redundant checks
> CollapsingQParserPlugin throws NPE instead of bad request
> -
>
> Key: SOLR-13944
> URL: https://issues.apache.org/jira/browse/SOLR-13944
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.3.1
>Reporter: Stefan
>Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-13944.patch, SOLR-13944.patch, SOLR-13944.patch,
> SOLR-13944.patch
>
>
> I noticed the following NPE:
> {code:java}
> java.lang.NullPointerException at
> org.apache.solr.search.CollapsingQParserPlugin$OrdFieldValueCollector.finish(CollapsingQParserPlugin.java:1021)
> at
> org.apache.solr.search.CollapsingQParserPlugin$OrdFieldValueCollector.finish(CollapsingQParserPlugin.java:1081)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:230)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1602)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1419)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:584)
> {code}
> If I am correct, the problem was already addressed in SOLR-8807. The fix does
> was not working in this case though, because of a syntax error in the query
> (I used the local parameter syntax twice instead of combining it). The
> relevant part of the query is:
> {code:java}
> &fq={!tag=collapser}{!collapse field=productId sort='merchantOrder asc, price
> asc, id asc'}
> {code}
> After discussing that on the mailing list, I was asked to open a ticket,
> because this situation should result in a bad request instead of a
> NullpointerException (see
> [https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201911.mbox/%3CCAMJgJxTuSb%3D8szO8bvHiAafJOs08O_NMB4pcaHOXME4Jj-GO2A%40mail.gmail.com%3E])
--
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-13944) CollapsingQParserPlugin throws NPE instead of bad request
[
https://issues.apache.org/jira/browse/SOLR-13944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-13944:
Attachment: SOLR-13944.patch
> CollapsingQParserPlugin throws NPE instead of bad request
> -
>
> Key: SOLR-13944
> URL: https://issues.apache.org/jira/browse/SOLR-13944
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.3.1
>Reporter: Stefan
>Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-13944.patch, SOLR-13944.patch, SOLR-13944.patch,
> SOLR-13944.patch
>
>
> I noticed the following NPE:
> {code:java}
> java.lang.NullPointerException at
> org.apache.solr.search.CollapsingQParserPlugin$OrdFieldValueCollector.finish(CollapsingQParserPlugin.java:1021)
> at
> org.apache.solr.search.CollapsingQParserPlugin$OrdFieldValueCollector.finish(CollapsingQParserPlugin.java:1081)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:230)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1602)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1419)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:584)
> {code}
> If I am correct, the problem was already addressed in SOLR-8807. The fix does
> was not working in this case though, because of a syntax error in the query
> (I used the local parameter syntax twice instead of combining it). The
> relevant part of the query is:
> {code:java}
> &fq={!tag=collapser}{!collapse field=productId sort='merchantOrder asc, price
> asc, id asc'}
> {code}
> After discussing that on the mailing list, I was asked to open a ticket,
> because this situation should result in a bad request instead of a
> NullpointerException (see
> [https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201911.mbox/%3CCAMJgJxTuSb%3D8szO8bvHiAafJOs08O_NMB4pcaHOXME4Jj-GO2A%40mail.gmail.com%3E])
--
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-13944) CollapsingQParserPlugin throws NPE instead of bad request
[
https://issues.apache.org/jira/browse/SOLR-13944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057528#comment-17057528
]
Munendra S N edited comment on SOLR-13944 at 3/12/20, 2:23 AM:
---
[~tflobbe]
Just {{QParser.getParser}} won't work in {{\{!tag=collapser\}\{!collapse
field=productId sort='merchantOrder asc, price asc, id asc'\}}} as it return
default parser and on calling getQuery localParams are parsed
[~jbernste]
Thanks for the ping, I reran tests without Collator and they pass after
SOLR-14073. So, my current idea is to keep the additional tests and simplify
collator logic(not to bother about collapse string match)
[^SOLR-13944.patch]
was (Author: munendrasn):
[~tflobbe]
Just {{QParser.getParser}} won't work in {{\{!tag=collapser\}\{!collapse
field=productId sort='merchantOrder asc, price asc, id asc'\}}} So, we needed
to parsing
[~jbernste]
Thanks for the ping, I reran tests without Collator and they pass after
SOLR-14073. So, my current idea is to keep the additional tests and simplify
collator logic(not to bother about collapse string match)
[^SOLR-13944.patch]
> CollapsingQParserPlugin throws NPE instead of bad request
> -
>
> Key: SOLR-13944
> URL: https://issues.apache.org/jira/browse/SOLR-13944
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.3.1
>Reporter: Stefan
>Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-13944.patch, SOLR-13944.patch, SOLR-13944.patch
>
>
> I noticed the following NPE:
> {code:java}
> java.lang.NullPointerException at
> org.apache.solr.search.CollapsingQParserPlugin$OrdFieldValueCollector.finish(CollapsingQParserPlugin.java:1021)
> at
> org.apache.solr.search.CollapsingQParserPlugin$OrdFieldValueCollector.finish(CollapsingQParserPlugin.java:1081)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:230)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1602)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1419)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:584)
> {code}
> If I am correct, the problem was already addressed in SOLR-8807. The fix does
> was not working in this case though, because of a syntax error in the query
> (I used the local parameter syntax twice instead of combining it). The
> relevant part of the query is:
> {code:java}
> &fq={!tag=collapser}{!collapse field=productId sort='merchantOrder asc, price
> asc, id asc'}
> {code}
> After discussing that on the mailing list, I was asked to open a ticket,
> because this situation should result in a bad request instead of a
> NullpointerException (see
> [https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201911.mbox/%3CCAMJgJxTuSb%3D8szO8bvHiAafJOs08O_NMB4pcaHOXME4Jj-GO2A%40mail.gmail.com%3E])
--
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-13944) CollapsingQParserPlugin throws NPE instead of bad request
[
https://issues.apache.org/jira/browse/SOLR-13944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057528#comment-17057528
]
Munendra S N commented on SOLR-13944:
-
[~tflobbe]
Just {{QParser.getParser}} won't work in {{\{!tag=collapser\}\{!collapse
field=productId sort='merchantOrder asc, price asc, id asc'\}}} So, we needed
to parsing
[~jbernste]
Thanks for the ping, I reran tests without Collator and they pass after
SOLR-14073. So, my current idea is to keep the additional tests and simplify
collator logic(not to bother about collapse string match)
[^SOLR-13944.patch]
> CollapsingQParserPlugin throws NPE instead of bad request
> -
>
> Key: SOLR-13944
> URL: https://issues.apache.org/jira/browse/SOLR-13944
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.3.1
>Reporter: Stefan
>Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-13944.patch, SOLR-13944.patch, SOLR-13944.patch
>
>
> I noticed the following NPE:
> {code:java}
> java.lang.NullPointerException at
> org.apache.solr.search.CollapsingQParserPlugin$OrdFieldValueCollector.finish(CollapsingQParserPlugin.java:1021)
> at
> org.apache.solr.search.CollapsingQParserPlugin$OrdFieldValueCollector.finish(CollapsingQParserPlugin.java:1081)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:230)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1602)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1419)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:584)
> {code}
> If I am correct, the problem was already addressed in SOLR-8807. The fix does
> was not working in this case though, because of a syntax error in the query
> (I used the local parameter syntax twice instead of combining it). The
> relevant part of the query is:
> {code:java}
> &fq={!tag=collapser}{!collapse field=productId sort='merchantOrder asc, price
> asc, id asc'}
> {code}
> After discussing that on the mailing list, I was asked to open a ticket,
> because this situation should result in a bad request instead of a
> NullpointerException (see
> [https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201911.mbox/%3CCAMJgJxTuSb%3D8szO8bvHiAafJOs08O_NMB4pcaHOXME4Jj-GO2A%40mail.gmail.com%3E])
--
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-13944) CollapsingQParserPlugin throws NPE instead of bad request
[
https://issues.apache.org/jira/browse/SOLR-13944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-13944:
Attachment: SOLR-13944.patch
> CollapsingQParserPlugin throws NPE instead of bad request
> -
>
> Key: SOLR-13944
> URL: https://issues.apache.org/jira/browse/SOLR-13944
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.3.1
>Reporter: Stefan
>Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-13944.patch, SOLR-13944.patch, SOLR-13944.patch
>
>
> I noticed the following NPE:
> {code:java}
> java.lang.NullPointerException at
> org.apache.solr.search.CollapsingQParserPlugin$OrdFieldValueCollector.finish(CollapsingQParserPlugin.java:1021)
> at
> org.apache.solr.search.CollapsingQParserPlugin$OrdFieldValueCollector.finish(CollapsingQParserPlugin.java:1081)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:230)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1602)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1419)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:584)
> {code}
> If I am correct, the problem was already addressed in SOLR-8807. The fix does
> was not working in this case though, because of a syntax error in the query
> (I used the local parameter syntax twice instead of combining it). The
> relevant part of the query is:
> {code:java}
> &fq={!tag=collapser}{!collapse field=productId sort='merchantOrder asc, price
> asc, id asc'}
> {code}
> After discussing that on the mailing list, I was asked to open a ticket,
> because this situation should result in a bad request instead of a
> NullpointerException (see
> [https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201911.mbox/%3CCAMJgJxTuSb%3D8szO8bvHiAafJOs08O_NMB4pcaHOXME4Jj-GO2A%40mail.gmail.com%3E])
--
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-13944) CollapsingQParserPlugin throws NPE instead of bad request
[
https://issues.apache.org/jira/browse/SOLR-13944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057523#comment-17057523
]
Joel Bernstein commented on SOLR-13944:
---
SOLR-14073, may have resolved this issue.
> CollapsingQParserPlugin throws NPE instead of bad request
> -
>
> Key: SOLR-13944
> URL: https://issues.apache.org/jira/browse/SOLR-13944
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.3.1
>Reporter: Stefan
>Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-13944.patch, SOLR-13944.patch
>
>
> I noticed the following NPE:
> {code:java}
> java.lang.NullPointerException at
> org.apache.solr.search.CollapsingQParserPlugin$OrdFieldValueCollector.finish(CollapsingQParserPlugin.java:1021)
> at
> org.apache.solr.search.CollapsingQParserPlugin$OrdFieldValueCollector.finish(CollapsingQParserPlugin.java:1081)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:230)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1602)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1419)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:584)
> {code}
> If I am correct, the problem was already addressed in SOLR-8807. The fix does
> was not working in this case though, because of a syntax error in the query
> (I used the local parameter syntax twice instead of combining it). The
> relevant part of the query is:
> {code:java}
> &fq={!tag=collapser}{!collapse field=productId sort='merchantOrder asc, price
> asc, id asc'}
> {code}
> After discussing that on the mailing list, I was asked to open a ticket,
> because this situation should result in a bad request instead of a
> NullpointerException (see
> [https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201911.mbox/%3CCAMJgJxTuSb%3D8szO8bvHiAafJOs08O_NMB4pcaHOXME4Jj-GO2A%40mail.gmail.com%3E])
--
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-14320) TestSQLHandler failures
[
https://issues.apache.org/jira/browse/SOLR-14320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057520#comment-17057520
]
Joel Bernstein commented on SOLR-14320:
---
Ok, I'll take a look.
> TestSQLHandler failures
> ---
>
> Key: SOLR-14320
> URL: https://issues.apache.org/jira/browse/SOLR-14320
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Environment: MacOS 10.15.3
> OpenJDK 11.0.5
>Reporter: Mike Drob
>Priority: Major
>
> I'm getting a reproducible failure locally with:
> {{gradlew clean :solr:core:test --tests
> "org.apache.solr.handler.TestSQLHandler" -Ptests.seed=57C9372573E8FDEC}}
> on current HEAD of master commit {{32a2076c605}}
> cc: [~jbernste]?
--
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-14320) TestSQLHandler failures
[
https://issues.apache.org/jira/browse/SOLR-14320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein reassigned SOLR-14320:
-
Assignee: Joel Bernstein
> TestSQLHandler failures
> ---
>
> Key: SOLR-14320
> URL: https://issues.apache.org/jira/browse/SOLR-14320
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Environment: MacOS 10.15.3
> OpenJDK 11.0.5
>Reporter: Mike Drob
>Assignee: Joel Bernstein
>Priority: Major
>
> I'm getting a reproducible failure locally with:
> {{gradlew clean :solr:core:test --tests
> "org.apache.solr.handler.TestSQLHandler" -Ptests.seed=57C9372573E8FDEC}}
> on current HEAD of master commit {{32a2076c605}}
> cc: [~jbernste]?
--
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-14320) TestSQLHandler failures
[
https://issues.apache.org/jira/browse/SOLR-14320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057425#comment-17057425
]
Mike Drob commented on SOLR-14320:
--
Another seed: {{-Ptests.seed=3BAD7C7ADF282B0B}}
> TestSQLHandler failures
> ---
>
> Key: SOLR-14320
> URL: https://issues.apache.org/jira/browse/SOLR-14320
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Environment: MacOS 10.15.3
> OpenJDK 11.0.5
>Reporter: Mike Drob
>Priority: Major
>
> I'm getting a reproducible failure locally with:
> {{gradlew clean :solr:core:test --tests
> "org.apache.solr.handler.TestSQLHandler" -Ptests.seed=57C9372573E8FDEC}}
> on current HEAD of master commit {{32a2076c605}}
> cc: [~jbernste]?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley closed pull request #1191: SOLR-14197 Reduce API of SolrResourceLoader
dsmiley closed pull request #1191: SOLR-14197 Reduce API of SolrResourceLoader URL: https://github.com/apache/lucene-solr/pull/1191 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14323) Add the ability for post-distributed UpdateRequestProcessors to modify the final update Response
Houston Putman created SOLR-14323:
-
Summary: Add the ability for post-distributed
UpdateRequestProcessors to modify the final update Response
Key: SOLR-14323
URL: https://issues.apache.org/jira/browse/SOLR-14323
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: UpdateRequestProcessors
Reporter: Houston Putman
Currently it is possible for an URP to alter the response for an update.
However an URP is placed after the {{DistrubutedUpdateRequestProcessor}} in the
chain and adds information to its response the information is sent back in the
response to the originating Solr Node and then ignored by the DURP. Thus the
response to the user does not contain this info.
I propose that URPs are given the ability to merge the responses they sent back
in each replica request, so that the DURP can then add the merged responses to
the user response.
--
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-13944) CollapsingQParserPlugin throws NPE instead of bad request
[
https://issues.apache.org/jira/browse/SOLR-13944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057397#comment-17057397
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-13944:
--
Quick question, and again, I'm not very familiar with this part of the code, do
we need to actually parse the filter? would it be enough to validate the parser
that's returned by {{QParse.getParser(...)}}?
> CollapsingQParserPlugin throws NPE instead of bad request
> -
>
> Key: SOLR-13944
> URL: https://issues.apache.org/jira/browse/SOLR-13944
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.3.1
>Reporter: Stefan
>Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-13944.patch, SOLR-13944.patch
>
>
> I noticed the following NPE:
> {code:java}
> java.lang.NullPointerException at
> org.apache.solr.search.CollapsingQParserPlugin$OrdFieldValueCollector.finish(CollapsingQParserPlugin.java:1021)
> at
> org.apache.solr.search.CollapsingQParserPlugin$OrdFieldValueCollector.finish(CollapsingQParserPlugin.java:1081)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:230)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1602)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1419)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:584)
> {code}
> If I am correct, the problem was already addressed in SOLR-8807. The fix does
> was not working in this case though, because of a syntax error in the query
> (I used the local parameter syntax twice instead of combining it). The
> relevant part of the query is:
> {code:java}
> &fq={!tag=collapser}{!collapse field=productId sort='merchantOrder asc, price
> asc, id asc'}
> {code}
> After discussing that on the mailing list, I was asked to open a ticket,
> because this situation should result in a bad request instead of a
> NullpointerException (see
> [https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201911.mbox/%3CCAMJgJxTuSb%3D8szO8bvHiAafJOs08O_NMB4pcaHOXME4Jj-GO2A%40mail.gmail.com%3E])
--
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] (LUCENE-9258) DocTermsIndexDocValues should not assume it's operating on a SortedDocValues field
[ https://issues.apache.org/jira/browse/LUCENE-9258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated LUCENE-9258: - Fix Version/s: 8.6 Resolution: Fixed Status: Resolved (was: Patch Available) Thanks for contributing! > DocTermsIndexDocValues should not assume it's operating on a SortedDocValues > field > -- > > Key: LUCENE-9258 > URL: https://issues.apache.org/jira/browse/LUCENE-9258 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 7.7.2, 8.4 >Reporter: Michele Palmia >Assignee: David Smiley >Priority: Minor > Fix For: 8.6 > > Attachments: LUCENE-9258.patch > > > When requesting a new _ValueSourceScorer_ (with _getRangeScorer_) from > _DocTermsIndexDocValues_ , the latter instantiates a new iterator on > _SortedDocValues_ regardless of the fact that the underlying field can > actually be of a different type (e.g. a _SortedSetDocValues_ processed > through a _SortedSetSelector_). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-8849) DocValuesRewriteMethod.visit should visit the MTQ
[
https://issues.apache.org/jira/browse/LUCENE-8849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved LUCENE-8849.
--
Fix Version/s: 8.6
Assignee: David Smiley
Resolution: Fixed
Thanks for contributing!
> DocValuesRewriteMethod.visit should visit the MTQ
> -
>
> Key: LUCENE-8849
> URL: https://issues.apache.org/jira/browse/LUCENE-8849
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 8.6
>
> Attachments: LUCENE-8849.patch
>
>
> The DocValuesRewriteMethod implements the QueryVisitor API (visit method) in
> a way that surprises me. It does not visit the wrapped MTQ query. Shouldn't
> it? Here is what I think it should do, similar to other query wrappers:
> {code:java}
> @Override
> public void visit(QueryVisitor visitor) {
> query.visit(visitor.getSubVisitor(BooleanClause.Occur.MUST, this));
> }
> {code}
> CC [~romseygeek]
--
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-9258) DocTermsIndexDocValues should not assume it's operating on a SortedDocValues field
[ https://issues.apache.org/jira/browse/LUCENE-9258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057387#comment-17057387 ] ASF subversion and git services commented on LUCENE-9258: - Commit e783f3729d63dff23fc82cd151c4348561b7966d in lucene-solr's branch refs/heads/branch_8x from Michele Palmia [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e783f37 ] LUCENE-9258: DocTermsIndexDocValues' range scorer didn't support multi-valued fields (cherry picked from commit b1ec1cd9e0ce3498945adaac67d497c226072ba7) > DocTermsIndexDocValues should not assume it's operating on a SortedDocValues > field > -- > > Key: LUCENE-9258 > URL: https://issues.apache.org/jira/browse/LUCENE-9258 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 7.7.2, 8.4 >Reporter: Michele Palmia >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE-9258.patch > > > When requesting a new _ValueSourceScorer_ (with _getRangeScorer_) from > _DocTermsIndexDocValues_ , the latter instantiates a new iterator on > _SortedDocValues_ regardless of the fact that the underlying field can > actually be of a different type (e.g. a _SortedSetDocValues_ processed > through a _SortedSetSelector_). -- 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-8849) DocValuesRewriteMethod.visit should visit the MTQ
[
https://issues.apache.org/jira/browse/LUCENE-8849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057386#comment-17057386
]
ASF subversion and git services commented on LUCENE-8849:
-
Commit 2144a46e958250bf8c6e838ed636aeab64318ae4 in lucene-solr's branch
refs/heads/branch_8x from Michele Palmia
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2144a46 ]
LUCENE-8849: DocValuesRewriteMethod.visit should visit subquery
(cherry picked from commit 5286098ac5c2f6bd69ba7b9c9c48343bc1a59ea9)
> DocValuesRewriteMethod.visit should visit the MTQ
> -
>
> Key: LUCENE-8849
> URL: https://issues.apache.org/jira/browse/LUCENE-8849
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Reporter: David Smiley
>Priority: Minor
> Attachments: LUCENE-8849.patch
>
>
> The DocValuesRewriteMethod implements the QueryVisitor API (visit method) in
> a way that surprises me. It does not visit the wrapped MTQ query. Shouldn't
> it? Here is what I think it should do, similar to other query wrappers:
> {code:java}
> @Override
> public void visit(QueryVisitor visitor) {
> query.visit(visitor.getSubVisitor(BooleanClause.Occur.MUST, this));
> }
> {code}
> CC [~romseygeek]
--
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-9258) DocTermsIndexDocValues should not assume it's operating on a SortedDocValues field
[ https://issues.apache.org/jira/browse/LUCENE-9258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057381#comment-17057381 ] ASF subversion and git services commented on LUCENE-9258: - Commit b1ec1cd9e0ce3498945adaac67d497c226072ba7 in lucene-solr's branch refs/heads/master from Michele Palmia [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b1ec1cd ] LUCENE-9258: DocTermsIndexDocValues' range scorer didn't support multi-valued fields > DocTermsIndexDocValues should not assume it's operating on a SortedDocValues > field > -- > > Key: LUCENE-9258 > URL: https://issues.apache.org/jira/browse/LUCENE-9258 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 7.7.2, 8.4 >Reporter: Michele Palmia >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE-9258.patch > > > When requesting a new _ValueSourceScorer_ (with _getRangeScorer_) from > _DocTermsIndexDocValues_ , the latter instantiates a new iterator on > _SortedDocValues_ regardless of the fact that the underlying field can > actually be of a different type (e.g. a _SortedSetDocValues_ processed > through a _SortedSetSelector_). -- 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-8849) DocValuesRewriteMethod.visit should visit the MTQ
[
https://issues.apache.org/jira/browse/LUCENE-8849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057372#comment-17057372
]
ASF subversion and git services commented on LUCENE-8849:
-
Commit 5286098ac5c2f6bd69ba7b9c9c48343bc1a59ea9 in lucene-solr's branch
refs/heads/master from Michele Palmia
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5286098 ]
LUCENE-8849: DocValuesRewriteMethod.visit should visit subquery
> DocValuesRewriteMethod.visit should visit the MTQ
> -
>
> Key: LUCENE-8849
> URL: https://issues.apache.org/jira/browse/LUCENE-8849
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Reporter: David Smiley
>Priority: Minor
> Attachments: LUCENE-8849.patch
>
>
> The DocValuesRewriteMethod implements the QueryVisitor API (visit method) in
> a way that surprises me. It does not visit the wrapped MTQ query. Shouldn't
> it? Here is what I think it should do, similar to other query wrappers:
> {code:java}
> @Override
> public void visit(QueryVisitor visitor) {
> query.visit(visitor.getSubVisitor(BooleanClause.Occur.MUST, this));
> }
> {code}
> CC [~romseygeek]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on issue #1343: LUCENE-8103: Use two-phase iteration in Query- and DoubleValuesSource
dsmiley commented on issue #1343: LUCENE-8103: Use two-phase iteration in Query- and DoubleValuesSource URL: https://github.com/apache/lucene-solr/pull/1343#issuecomment-597830616 BTW thanks for your contributions lately. Perhaps you will be at Berlin Buzzwords this June; I shall be there. 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] aroopganguly edited a comment on issue #1344: SOLR-14316 Remove unchecked type conversion warning in JavaBinCodec's readMapEntry's equals() squashed
aroopganguly edited a comment on issue #1344: SOLR-14316 Remove unchecked type conversion warning in JavaBinCodec's readMapEntry's equals() squashed URL: https://github.com/apache/lucene-solr/pull/1344#issuecomment-597818362 @tflobbe @anshumg @noblepaul This is a squashed version of the original pr. I have addressed review comments from all of you here. If its not too much trouble please re-review PR here and I will close the other one. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14321) SolrJ with Kerberos docs have removed HttpClientUtil.setConfigurer
[
https://issues.apache.org/jira/browse/SOLR-14321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057336#comment-17057336
]
Kevin Risden commented on SOLR-14321:
-
Source is here:
https://github.com/apache/lucene-solr/blob/master/solr/solr-ref-guide/src/kerberos-authentication-plugin.adoc#using-solrj-with-a-kerberized-solr
> SolrJ with Kerberos docs have removed HttpClientUtil.setConfigurer
> ---
>
> Key: SOLR-14321
> URL: https://issues.apache.org/jira/browse/SOLR-14321
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 8.0, 8.1, 8.2,
> 8.3, 8.4
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Major
>
> https://lucene.apache.org/solr/guide/8_4/kerberos-authentication-plugin.html#using-solrj-with-a-kerberized-solr
> {code:java}
> HttpClientUtil.setConfigurer(new Krb5HttpClientConfigurer());
> {code}
> This was removed in Solr 7.0.0 with SOLR-4509
> (https://github.com/apache/lucene-solr/commit/ce172acb8fec6c3bbb18837a4d640da6c5aad649#diff-ab69354d287d536ce35357f6023bafceL104).
> This is briefly mentioned here:
> https://lucene.apache.org/solr/7_0_0/changes/Changes.html#v7.0.0.upgrading_from_solr_6.x
> The replacement should be:
> {code:java}
> HttpClientUtil.setHttpClientBuilder(new Krb5HttpClientBuilder().getBuilder());
> {code}
> An example of this is:
> https://github.com/apache/ranger/blob/master/security-admin/src/main/java/org/apache/ranger/solr/SolrMgr.java#L114
--
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] aroopganguly closed pull request #1335: SOLR-14316 Remove unchecked type conversion warning in JavaBinCodec's readMapEntry's equals() method
aroopganguly closed pull request #1335: SOLR-14316 Remove unchecked type conversion warning in JavaBinCodec's readMapEntry's equals() method URL: https://github.com/apache/lucene-solr/pull/1335 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] aroopganguly commented on issue #1335: SOLR-14316 Remove unchecked type conversion warning in JavaBinCodec's readMapEntry's equals() method
aroopganguly commented on issue #1335: SOLR-14316 Remove unchecked type conversion warning in JavaBinCodec's readMapEntry's equals() method URL: https://github.com/apache/lucene-solr/pull/1335#issuecomment-597827316 closing this PR in favor of https://github.com/apache/lucene-solr/pull/1344 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14322) AbstractFullDistribZkTestBase.waitForThingsToLevelOut is very inconsistent
Mike Drob created SOLR-14322: Summary: AbstractFullDistribZkTestBase.waitForThingsToLevelOut is very inconsistent Key: SOLR-14322 URL: https://issues.apache.org/jira/browse/SOLR-14322 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Mike Drob There are many strange things going on with this method - 1. It accepts a value in seconds, but many callers pass millis 2. The method will only retry on the last shard being inconsistent, not any other shard 3. Catching Throwable is dubious. 4. There's a conditional wait mixed with an unconditional sleep. (this might be ok?) 5. There's a bunch of System.out and System.err 6. If we never get to the "level out state" we still simply return instead of somehow indicating the error condition -- 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-14173) Ref Guide Redesign
[
https://issues.apache.org/jira/browse/SOLR-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057332#comment-17057332
]
Cassandra Targett commented on SOLR-14173:
--
I've sat with the gray theme for a couple of days and prefer it, so I committed
those changes and updated my demo site:
http://people.apache.org/~ctargett/RefGuideRedesign/index.html.
I added in some CSS changes to make the current page being viewed more obvious
(it will be bold).
There's only one more issue that I can tell, which is to get the sidebar to
scroll to the section of the nav that shows the current page. But the same
problem exists today (not sure why I never noticed it) and my goal with phase 2
is to make a number of improvements to page organization and simplify that nav
a lot more, so I'm willing to go ahead with it as is and hopefully address it
in the future.
I think this is otherwise ready to go into master and branch_8x. I hadn't
planned on doing it on branch_8_5, but since that hasn't been published yet, I
could (timing seems to work out).
I could also backport it into branch_8_4 and all previous ref guide branches
(back to branch_6_6) so they are all consistent in look & feel...not sure if
anyone has an opinion about that.
> Ref Guide Redesign
> --
>
> Key: SOLR-14173
> URL: https://issues.apache.org/jira/browse/SOLR-14173
> Project: Solr
> Issue Type: Improvement
> Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Major
> Attachments: SOLR-14173.patch, blue-left-nav.png, gray-left-nav.png
>
>
> The current design of the Ref Guide was essentially copied from a
> Jekyll-based documentation theme
> (https://idratherbewriting.com/documentation-theme-jekyll/), which had a
> couple important benefits for that time:
> * It was well-documented and since I had little experience with Jekyll and
> its Liquid templates and since I was the one doing it, I wanted to make it as
> easy on myself as possible
> * It was designed for documentation specifically so took care of all the
> things like inter-page navigation, etc.
> * It helped us get from Confluence to our current system quickly
> It had some drawbacks, though:
> * It wasted a lot of space on the page
> * The theme was built for Markdown files, so did not take advantage of the
> features of the {{jekyll-asciidoc}} plugin we use (the in-page TOC being one
> big example - the plugin could create it at build time, but the theme
> included JS to do it as the page loads, so we use the JS)
> * It had a lot of JS and overlapping CSS files. While it used Bootstrap it
> used a customized CSS on top of it for theming that made modifications
> complex (it was hard to figure out how exactly a change would behave)
> * With all the stuff I'd changed in my bumbling way just to get things to
> work back then, I broke a lot of the stuff Bootstrap is supposed to give us
> in terms of responsiveness and making the Guide usable even on smaller screen
> sizes.
> After upgrading the Asciidoctor components in SOLR-12786 and stopping the PDF
> (SOLR-13782), I wanted to try to set us up for a more flexible system. We
> need it for things like Joel's work on the visual guide for streaming
> expressions (SOLR-13105), and in order to implement other ideas we might have
> on how to present information in the future.
> I view this issue as a phase 1 of an overall redesign that I've already
> started in a local branch. I'll explain in a comment the changes I've already
> made, and will use this issue to create and push a branch where we can
> discuss in more detail.
> Phase 1 here will be under-the-hood CSS/JS changes + overall page layout
> changes.
> Phase 2 (issue TBD) will be a wholesale re-organization of all the pages of
> the Guide.
> Phase 3 (issue TBD) will explore moving us from Jekyll to another static site
> generator that is better suited for our content format, file types, and build
> conventions.
--
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] aroopganguly commented on issue #1344: SOLR-14316 Remove unchecked type conversion warning in JavaBinCodec's readMapEntry's equals() squashed
aroopganguly commented on issue #1344: SOLR-14316 Remove unchecked type conversion warning in JavaBinCodec's readMapEntry's equals() squashed URL: https://github.com/apache/lucene-solr/pull/1344#issuecomment-597818362 @tflobbe @anshumg @noblepaul this is a squashed version of the original pr. I have addressed review comments from there here. If its not too much trouble please re-review PR here and I will close the other one. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9272) No longer verify checksum of the tip file when opening the terms dict
[ https://issues.apache.org/jira/browse/LUCENE-9272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057321#comment-17057321 ] ASF subversion and git services commented on LUCENE-9272: - Commit 795e16f9abfdb0580cbcc72d77a19b5e12fc4e49 in lucene-solr's branch refs/heads/branch_8x from Adrien Grand [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=795e16f ] LUCENE-9272: Add a CHANGES entry. > No longer verify checksum of the tip file when opening the terms dict > - > > Key: LUCENE-9272 > URL: https://issues.apache.org/jira/browse/LUCENE-9272 > Project: Lucene - Core > Issue Type: Task >Reporter: Adrien Grand >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > We currently verify the checksum of the tip file when opening the terms > dictionary. This made sense when we would load the FST on-heap, but now that > we load it off-heap, maybe we should verify its integrity in checkIntegrity > instead, like we do for other files that we don't have to read eagerly? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9272) No longer verify checksum of the tip file when opening the terms dict
[ https://issues.apache.org/jira/browse/LUCENE-9272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved LUCENE-9272. -- Fix Version/s: 8.6 Resolution: Fixed > No longer verify checksum of the tip file when opening the terms dict > - > > Key: LUCENE-9272 > URL: https://issues.apache.org/jira/browse/LUCENE-9272 > Project: Lucene - Core > Issue Type: Task >Reporter: Adrien Grand >Priority: Minor > Fix For: 8.6 > > Time Spent: 0.5h > Remaining Estimate: 0h > > We currently verify the checksum of the tip file when opening the terms > dictionary. This made sense when we would load the FST on-heap, but now that > we load it off-heap, maybe we should verify its integrity in checkIntegrity > instead, like we do for other files that we don't have to read eagerly? -- 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-9272) No longer verify checksum of the tip file when opening the terms dict
[ https://issues.apache.org/jira/browse/LUCENE-9272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057319#comment-17057319 ] Adrien Grand commented on LUCENE-9272: -- Sigh, I had forgotten the CHANGES entry. > No longer verify checksum of the tip file when opening the terms dict > - > > Key: LUCENE-9272 > URL: https://issues.apache.org/jira/browse/LUCENE-9272 > Project: Lucene - Core > Issue Type: Task >Reporter: Adrien Grand >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > We currently verify the checksum of the tip file when opening the terms > dictionary. This made sense when we would load the FST on-heap, but now that > we load it off-heap, maybe we should verify its integrity in checkIntegrity > instead, like we do for other files that we don't have to read eagerly? -- 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-9272) No longer verify checksum of the tip file when opening the terms dict
[ https://issues.apache.org/jira/browse/LUCENE-9272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057320#comment-17057320 ] ASF subversion and git services commented on LUCENE-9272: - Commit e43f8572cba9d818088cf2b8bd2e74e35f0a6d34 in lucene-solr's branch refs/heads/master from Adrien Grand [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e43f857 ] LUCENE-9272: Add a CHANGES entry. > No longer verify checksum of the tip file when opening the terms dict > - > > Key: LUCENE-9272 > URL: https://issues.apache.org/jira/browse/LUCENE-9272 > Project: Lucene - Core > Issue Type: Task >Reporter: Adrien Grand >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > We currently verify the checksum of the tip file when opening the terms > dictionary. This made sense when we would load the FST on-heap, but now that > we load it off-heap, maybe we should verify its integrity in checkIntegrity > instead, like we do for other files that we don't have to read eagerly? -- 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-9272) No longer verify checksum of the tip file when opening the terms dict
[ https://issues.apache.org/jira/browse/LUCENE-9272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057317#comment-17057317 ] ASF subversion and git services commented on LUCENE-9272: - Commit 048e24eeba4554d043053d3e4d254f9a4893fa50 in lucene-solr's branch refs/heads/branch_8x from Adrien Grand [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=048e24e ] LUCENE-9272: Move checksum verification of the `.tip` file to `checkIntegrity()`. (#1339) > No longer verify checksum of the tip file when opening the terms dict > - > > Key: LUCENE-9272 > URL: https://issues.apache.org/jira/browse/LUCENE-9272 > Project: Lucene - Core > Issue Type: Task >Reporter: Adrien Grand >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > We currently verify the checksum of the tip file when opening the terms > dictionary. This made sense when we would load the FST on-heap, but now that > we load it off-heap, maybe we should verify its integrity in checkIntegrity > instead, like we do for other files that we don't have to read eagerly? -- 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-14321) SolrJ with Kerberos docs have removed HttpClientUtil.setConfigurer
[
https://issues.apache.org/jira/browse/SOLR-14321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057316#comment-17057316
]
Kevin Risden commented on SOLR-14321:
-
FWIW this affects basically all the published HTML guides -
https://lucene.apache.org/solr/guide/ all but the 6.6 one. Going to try to see
what is involved in getting this updated.
> SolrJ with Kerberos docs have removed HttpClientUtil.setConfigurer
> ---
>
> Key: SOLR-14321
> URL: https://issues.apache.org/jira/browse/SOLR-14321
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 8.0, 8.1, 8.2,
> 8.3, 8.4
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Major
>
> https://lucene.apache.org/solr/guide/8_4/kerberos-authentication-plugin.html#using-solrj-with-a-kerberized-solr
> {code:java}
> HttpClientUtil.setConfigurer(new Krb5HttpClientConfigurer());
> {code}
> This was removed in Solr 7.0.0 with SOLR-4509
> (https://github.com/apache/lucene-solr/commit/ce172acb8fec6c3bbb18837a4d640da6c5aad649#diff-ab69354d287d536ce35357f6023bafceL104).
> This is briefly mentioned here:
> https://lucene.apache.org/solr/7_0_0/changes/Changes.html#v7.0.0.upgrading_from_solr_6.x
> The replacement should be:
> {code:java}
> HttpClientUtil.setHttpClientBuilder(new Krb5HttpClientBuilder().getBuilder());
> {code}
> An example of this is:
> https://github.com/apache/ranger/blob/master/security-admin/src/main/java/org/apache/ranger/solr/SolrMgr.java#L114
--
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] atris commented on issue #1294: LUCENE-9074: Slice Allocation Control Plane For Concurrent Searches
atris commented on issue #1294: LUCENE-9074: Slice Allocation Control Plane For Concurrent Searches URL: https://github.com/apache/lucene-solr/pull/1294#issuecomment-597808136 @jpountz Fixed, please see and let me know your thoughts. 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] atris commented on a change in pull request #1294: LUCENE-9074: Slice Allocation Control Plane For Concurrent Searches
atris commented on a change in pull request #1294: LUCENE-9074: Slice
Allocation Control Plane For Concurrent Searches
URL: https://github.com/apache/lucene-solr/pull/1294#discussion_r391192155
##
File path: lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
##
@@ -211,6 +213,18 @@ public IndexSearcher(IndexReaderContext context, Executor
executor) {
assert context.isTopLevel: "IndexSearcher's ReaderContext must be topLevel
for reader" + context.reader();
reader = context.reader();
this.executor = executor;
+this.sliceExecutionControlPlane = executor == null ? null :
getSliceExecutionControlPlane(executor);
+this.readerContext = context;
+leafContexts = context.leaves();
+this.leafSlices = executor == null ? null : slices(leafContexts);
+ }
+
+ // Package private for testing
+ IndexSearcher(IndexReaderContext context, Executor executor,
SliceExecutionControlPlane sliceExecutionControlPlane) {
+assert context.isTopLevel: "IndexSearcher's ReaderContext must be topLevel
for reader" + context.reader();
+reader = context.reader();
+this.executor = executor;
+this.sliceExecutionControlPlane = executor == null ? null :
sliceExecutionControlPlane;
Review comment:
+1, did not add it since it was a test method but I see your point. Added
now, thanks!
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14321) SolrJ with Kerberos docs have removed HttpClientUtil.setConfigurer
[
https://issues.apache.org/jira/browse/SOLR-14321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-14321:
Description:
https://lucene.apache.org/solr/guide/8_4/kerberos-authentication-plugin.html#using-solrj-with-a-kerberized-solr
{code:java}
HttpClientUtil.setConfigurer(new Krb5HttpClientConfigurer());
{code}
This was removed in Solr 7.0.0 with SOLR-4509
(https://github.com/apache/lucene-solr/commit/ce172acb8fec6c3bbb18837a4d640da6c5aad649#diff-ab69354d287d536ce35357f6023bafceL104).
This is briefly mentioned here:
https://lucene.apache.org/solr/7_0_0/changes/Changes.html#v7.0.0.upgrading_from_solr_6.x
The replacement should be:
{code:java}
HttpClientUtil.setHttpClientBuilder(new Krb5HttpClientBuilder().getBuilder());
{code}
An example of this is:
https://github.com/apache/ranger/blob/master/security-admin/src/main/java/org/apache/ranger/solr/SolrMgr.java#L114
was:
https://lucene.apache.org/solr/guide/8_4/kerberos-authentication-plugin.html#using-solrj-with-a-kerberized-solr
{code:java}
HttpClientUtil.setConfigurer(new Krb5HttpClientConfigurer());
{code}
This was removed in Solr 7.0.0 with SOLR-4509
(https://github.com/apache/lucene-solr/commit/ce172acb8fec6c3bbb18837a4d640da6c5aad649#diff-ab69354d287d536ce35357f6023bafceL104).
The replacement should be:
{code:java}
HttpClientUtil.setHttpClientBuilder(new Krb5HttpClientBuilder().getBuilder());
{code}
An example of this is:
https://github.com/apache/ranger/blob/master/security-admin/src/main/java/org/apache/ranger/solr/SolrMgr.java#L114
> SolrJ with Kerberos docs have removed HttpClientUtil.setConfigurer
> ---
>
> Key: SOLR-14321
> URL: https://issues.apache.org/jira/browse/SOLR-14321
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 8.0, 8.1, 8.2,
> 8.3, 8.4
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Major
>
> https://lucene.apache.org/solr/guide/8_4/kerberos-authentication-plugin.html#using-solrj-with-a-kerberized-solr
> {code:java}
> HttpClientUtil.setConfigurer(new Krb5HttpClientConfigurer());
> {code}
> This was removed in Solr 7.0.0 with SOLR-4509
> (https://github.com/apache/lucene-solr/commit/ce172acb8fec6c3bbb18837a4d640da6c5aad649#diff-ab69354d287d536ce35357f6023bafceL104).
> This is briefly mentioned here:
> https://lucene.apache.org/solr/7_0_0/changes/Changes.html#v7.0.0.upgrading_from_solr_6.x
> The replacement should be:
> {code:java}
> HttpClientUtil.setHttpClientBuilder(new Krb5HttpClientBuilder().getBuilder());
> {code}
> An example of this is:
> https://github.com/apache/ranger/blob/master/security-admin/src/main/java/org/apache/ranger/solr/SolrMgr.java#L114
--
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-14321) SolrJ with Kerberos docs have removed HttpClientUtil.setConfigurer
Kevin Risden created SOLR-14321:
---
Summary: SolrJ with Kerberos docs have removed
HttpClientUtil.setConfigurer
Key: SOLR-14321
URL: https://issues.apache.org/jira/browse/SOLR-14321
Project: Solr
Issue Type: Task
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 8.4, 8.3, 8.2, 8.1, 8.0, 7.7, 7.6, 7.5, 7.4, 7.3, 7.2,
7.1, 7.0
Reporter: Kevin Risden
Assignee: Kevin Risden
https://lucene.apache.org/solr/guide/8_4/kerberos-authentication-plugin.html#using-solrj-with-a-kerberized-solr
{code:java}
HttpClientUtil.setConfigurer(new Krb5HttpClientConfigurer());
{code}
This was removed in Solr 7.0.0 with SOLR-4509
(https://github.com/apache/lucene-solr/commit/ce172acb8fec6c3bbb18837a4d640da6c5aad649#diff-ab69354d287d536ce35357f6023bafceL104).
The replacement should be:
{code:java}
HttpClientUtil.setHttpClientBuilder(new Krb5HttpClientBuilder().getBuilder());
{code}
An example of this is:
https://github.com/apache/ranger/blob/master/security-admin/src/main/java/org/apache/ranger/solr/SolrMgr.java#L114
--
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-14321) SolrJ with Kerberos docs have removed HttpClientUtil.setConfigurer
[
https://issues.apache.org/jira/browse/SOLR-14321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-14321:
Component/s: documentation
> SolrJ with Kerberos docs have removed HttpClientUtil.setConfigurer
> ---
>
> Key: SOLR-14321
> URL: https://issues.apache.org/jira/browse/SOLR-14321
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 8.0, 8.1, 8.2,
> 8.3, 8.4
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Major
>
> https://lucene.apache.org/solr/guide/8_4/kerberos-authentication-plugin.html#using-solrj-with-a-kerberized-solr
> {code:java}
> HttpClientUtil.setConfigurer(new Krb5HttpClientConfigurer());
> {code}
> This was removed in Solr 7.0.0 with SOLR-4509
> (https://github.com/apache/lucene-solr/commit/ce172acb8fec6c3bbb18837a4d640da6c5aad649#diff-ab69354d287d536ce35357f6023bafceL104).
> The replacement should be:
> {code:java}
> HttpClientUtil.setHttpClientBuilder(new Krb5HttpClientBuilder().getBuilder());
> {code}
> An example of this is:
> https://github.com/apache/ranger/blob/master/security-admin/src/main/java/org/apache/ranger/solr/SolrMgr.java#L114
--
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] aroopganguly opened a new pull request #1344: squashed changes
aroopganguly opened a new pull request #1344: squashed changes URL: https://github.com/apache/lucene-solr/pull/1344 # Description Please provide a short description of the changes you're making with this pull request. # Solution Please provide a short description of the approach taken to implement your solution. # Tests Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem. # Checklist Please review the following and check all that apply: - [ ] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [ ] I have developed this patch against the `master` branch. - [ ] I have run `ant precommit` and the appropriate test suite. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] aroopganguly commented on a change in pull request #1335: SOLR-14316 Remove unchecked type conversion warning in JavaBinCodec's readMapEntry's equals() method
aroopganguly commented on a change in pull request #1335: SOLR-14316 Remove
unchecked type conversion warning in JavaBinCodec's readMapEntry's equals()
method
URL: https://github.com/apache/lucene-solr/pull/1335#discussion_r391184644
##
File path:
solr/solrj/src/test/org/apache/solr/common/util/TestJavaBinCodec.java
##
@@ -287,6 +289,45 @@ public void testAllTypes() throws IOException {
);
}
+ @Test
+ public void testReadMapEntry() throws IOException {
+Map.Entry extryFromTextDoc1 =
getMapFromJavaBinCodec(SOLRJ_DOCS_1);
+Map.Entry extryFromTextDoc1_clone =
getMapFromJavaBinCodec(SOLRJ_DOCS_1);
+
+Map.Entry extryFromTextDoc2 =
getMapFromJavaBinCodec(SOLRJ_DOCS_2);
+Map.Entry extryFromTextDoc2_clone =
getMapFromJavaBinCodec(SOLRJ_DOCS_2);
+
+// exactly same document read twice should have same content
+assert (extryFromTextDoc1.equals(extryFromTextDoc1_clone));
+// doc1 and doc2 are 2 text files with different content on line 1
+assert (!extryFromTextDoc2.equals(extryFromTextDoc1));
+// exactly same document read twice should have same content
+assert (extryFromTextDoc2.equals(extryFromTextDoc2_clone));
+
+// now lets look at binary files
Review comment:
sure
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] micpalmia commented on issue #1343: LUCENE-8103: Use two-phase iteration in Query- and DoubleValuesSource
micpalmia commented on issue #1343: LUCENE-8103: Use two-phase iteration in Query- and DoubleValuesSource URL: https://github.com/apache/lucene-solr/pull/1343#issuecomment-597801420 Copying comments by @dsmiley here: > minor: I suggest using the variable name "disi" for a DocIdSetIterator as this choice is quite common elsewhere. > > In DoubleValueSource I think it'd be better to declare the state you need like tpi, disi inside the anonymous DoubleValues class to keep the scope smaller and to reduce extra hidden indirection that I think Java adds. Also declare final where applicable. scorerMatch boolean is confusing to me; and I think the initial value as written doesn't matter either. I suggest renaming this to thisDocMatches, initialize to false (since we are unpositioned at the start), and then update it appropriately. The logic you have now around scoreMatch seems to do maybe extra work and/or isn't as simple as it could be. If doubleValue is invoked and not thisDocMatches then don't delegate to the scorer, which is probably invalid. Return NaN. > > In QueryValueSource.exists, maybe you could improve this a bit to be simpler; I find the way it was written prior to be confusing. 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] aroopganguly commented on a change in pull request #1335: SOLR-14316 Remove unchecked type conversion warning in JavaBinCodec's readMapEntry's equals() method
aroopganguly commented on a change in pull request #1335: SOLR-14316 Remove
unchecked type conversion warning in JavaBinCodec's readMapEntry's equals()
method
URL: https://github.com/apache/lucene-solr/pull/1335#discussion_r391184047
##
File path:
solr/solrj/src/test/org/apache/solr/common/util/TestJavaBinCodec.java
##
@@ -287,6 +289,45 @@ public void testAllTypes() throws IOException {
);
}
+ @Test
+ public void testReadMapEntry() throws IOException {
+Map.Entry extryFromTextDoc1 =
getMapFromJavaBinCodec(SOLRJ_DOCS_1);
+Map.Entry extryFromTextDoc1_clone =
getMapFromJavaBinCodec(SOLRJ_DOCS_1);
+
+Map.Entry extryFromTextDoc2 =
getMapFromJavaBinCodec(SOLRJ_DOCS_2);
+Map.Entry extryFromTextDoc2_clone =
getMapFromJavaBinCodec(SOLRJ_DOCS_2);
+
+// exactly same document read twice should have same content
+assert (extryFromTextDoc1.equals(extryFromTextDoc1_clone));
Review comment:
sure !
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] atris commented on a change in pull request #1294: LUCENE-9074: Slice Allocation Control Plane For Concurrent Searches
atris commented on a change in pull request #1294: LUCENE-9074: Slice
Allocation Control Plane For Concurrent Searches
URL: https://github.com/apache/lucene-solr/pull/1294#discussion_r391181418
##
File path: lucene/core/src/java/org/apache/lucene/search/SliceExecutor.java
##
@@ -0,0 +1,105 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.lucene.search;
+
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.List;
+import java.util.concurrent.CompletableFuture;
+import java.util.concurrent.Executor;
+import java.util.concurrent.Future;
+import java.util.concurrent.FutureTask;
+import java.util.concurrent.RejectedExecutionException;
+
+/**
+ * Executor which is responsible
+ * for execution of slices based on the current status
+ * of the system and current system load
+ */
+class SliceExecutor {
+ private final Executor executor;
+
+ public SliceExecutor(Executor executor) {
+this.executor = executor;
+ }
+
+ public List> invokeAll(Collection> tasks) {
Review comment:
Agreed, fixed, thanks
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] micpalmia opened a new pull request #1343: LUCENE-8103: Use two-phase iterator in Query- and DoubleValuesSource
micpalmia opened a new pull request #1343: LUCENE-8103: Use two-phase iterator in Query- and DoubleValuesSource URL: https://github.com/apache/lucene-solr/pull/1343 # Description QueryValueSource (in "queries" module) is a ValueSource representation of a Query; the score is the value. It ought to try to use a TwoPhaseIterator from the query if it can be offered. # Solution Always check whether a TwoPhaseIterator can be offered, and use it. Since its `matches()` function may only be called once, while there is no restrictions on QueryValueSource's or DoubleValuesSource's method calling, I unfortunately had to add some state. # Tests For each value source, I added a test case that makes use of a query that serves a TwoPhaseIterator. I don't think that's the best solution, but was not sure about how to solve this differently. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `master` branch. - [x] I have run `ant precommit` and the appropriate test suite. - [x] I have added tests for my changes. 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14320) TestSQLHandler failures
[
https://issues.apache.org/jira/browse/SOLR-14320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob updated SOLR-14320:
-
Attachment: (was: OUTPUT-org.apache.solr.handler.TestSQLHandler.txt)
> TestSQLHandler failures
> ---
>
> Key: SOLR-14320
> URL: https://issues.apache.org/jira/browse/SOLR-14320
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Environment: MacOS 10.15.3
> OpenJDK 11.0.5
>Reporter: Mike Drob
>Priority: Major
>
> I'm getting a reproducible failure locally with:
> {{gradlew clean :solr:core:test --tests
> "org.apache.solr.handler.TestSQLHandler" -Ptests.seed=57C9372573E8FDEC}}
> on current HEAD of master commit {{32a2076c605}}
> cc: [~jbernste]?
--
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-14320) TestSQLHandler failures
[
https://issues.apache.org/jira/browse/SOLR-14320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob updated SOLR-14320:
-
Attachment: OUTPUT-org.apache.solr.handler.TestSQLHandler.txt
> TestSQLHandler failures
> ---
>
> Key: SOLR-14320
> URL: https://issues.apache.org/jira/browse/SOLR-14320
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Environment: MacOS 10.15.3
> OpenJDK 11.0.5
>Reporter: Mike Drob
>Priority: Major
> Attachments: OUTPUT-org.apache.solr.handler.TestSQLHandler.txt
>
>
> I'm getting a reproducible failure locally with:
> {{gradlew clean :solr:core:test --tests
> "org.apache.solr.handler.TestSQLHandler" -Ptests.seed=57C9372573E8FDEC}}
> on current HEAD of master commit {{32a2076c605}}
> cc: [~jbernste]?
--
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-9270) Update Javadoc about normalizeEntry in Kuromoji DictionaryBuilder
[
https://issues.apache.org/jira/browse/LUCENE-9270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057278#comment-17057278
]
ASF subversion and git services commented on LUCENE-9270:
-
Commit 8bbae8feae7c8656748b82101be61dbc7b6b7fb1 in lucene-solr's branch
refs/heads/branch_8x from Namgyu Kim
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8bbae8f ]
LUCENE-9270: Update Javadoc about normalizeEntry in the Kuromoji
DictionaryBuilder
> Update Javadoc about normalizeEntry in Kuromoji DictionaryBuilder
> -
>
> Key: LUCENE-9270
> URL: https://issues.apache.org/jira/browse/LUCENE-9270
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Namgyu Kim
>Assignee: Namgyu Kim
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The normalizeEntry option is missing from the Javadoc of Kuromoji
> DictionaryBuilder.
> Without this explanation, users don't know what it means until they see the
> code.
> Also, if user follows the usage of Javadoc, it will not be built.
> So the following contents need to be applied:
> 1) Change usage
> before:
> java -cp [lucene classpath]
> org.apache.lucene.analysis.ja.util.DictionaryBuilder \
> ${inputDir} ${outputDir} ${encoding}
> after:
> java -cp [lucene classpath]
> org.apache.lucene.analysis.ja.util.DictionaryBuilder \
> ${inputDir} ${outputDir} ${encoding} *${normalizeEntry}*
> 2) Add description about normalizeEntry
>
--
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-9270) Update Javadoc about normalizeEntry in Kuromoji DictionaryBuilder
[
https://issues.apache.org/jira/browse/LUCENE-9270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057271#comment-17057271
]
ASF subversion and git services commented on LUCENE-9270:
-
Commit f0a49738ca661564cd5b222d00a316dfb20e41e4 in lucene-solr's branch
refs/heads/master from Namgyu Kim
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f0a4973 ]
LUCENE-9270: Update Javadoc about normalizeEntry in the Kuromoji
DictionaryBuilder
> Update Javadoc about normalizeEntry in Kuromoji DictionaryBuilder
> -
>
> Key: LUCENE-9270
> URL: https://issues.apache.org/jira/browse/LUCENE-9270
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Namgyu Kim
>Assignee: Namgyu Kim
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The normalizeEntry option is missing from the Javadoc of Kuromoji
> DictionaryBuilder.
> Without this explanation, users don't know what it means until they see the
> code.
> Also, if user follows the usage of Javadoc, it will not be built.
> So the following contents need to be applied:
> 1) Change usage
> before:
> java -cp [lucene classpath]
> org.apache.lucene.analysis.ja.util.DictionaryBuilder \
> ${inputDir} ${outputDir} ${encoding}
> after:
> java -cp [lucene classpath]
> org.apache.lucene.analysis.ja.util.DictionaryBuilder \
> ${inputDir} ${outputDir} ${encoding} *${normalizeEntry}*
> 2) Add description about normalizeEntry
>
--
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] danmuzi merged pull request #1336: LUCENE-9270: Update Javadoc about normalizeEntry in the Kuromoji DictionaryBuilder
danmuzi merged pull request #1336: LUCENE-9270: Update Javadoc about normalizeEntry in the Kuromoji DictionaryBuilder URL: https://github.com/apache/lucene-solr/pull/1336 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] danmuzi commented on a change in pull request #1338: LUCENE-9271: Move BufferedIndexInput to the ByteBuffer API
danmuzi commented on a change in pull request #1338: LUCENE-9271: Move
BufferedIndexInput to the ByteBuffer API
URL: https://github.com/apache/lucene-solr/pull/1338#discussion_r391152040
##
File path: lucene/core/src/java/org/apache/lucene/store/BufferedIndexInput.java
##
@@ -154,65 +146,60 @@ public final void readBytes(byte[] b, int offset, int
len, boolean useBuffer) th
// this function, there is no need to do a seek
// here, because there's no need to reread what we
// had in the buffer.
-long after = bufferStart+bufferPosition+len;
+long after = bufferStart+buffer.position()+len;
if(after > length())
throw new EOFException("read past EOF: " + this);
-readInternal(b, offset, len);
+readInternal(ByteBuffer.wrap(b, offset, len));
bufferStart = after;
-bufferPosition = 0;
-bufferLength = 0;// trigger refill() on read
+buffer.position(0);
Review comment:
I think if there is `buffer.limit(0)` on the next line, `buffer.position(0)`
doesn't look necessary.
Because there is a code of initializing position value within
`buffer.limit(0)`.
```java
// ByteBuffer.java
public abstract class ByteBuffer extends Buffer implements
Comparable
{
...
ByteBuffer limit(int newLimit) {
super.limit(newLimit);
return this;
}
...
}
// Buffer.java
public abstract class Buffer {
...
public Buffer limit(int newLimit) {
if (newLimit > capacity | newLimit < 0)
throw createLimitException(newLimit);
limit = newLimit;
if (position > limit) position = limit; // position will be 0.
if (mark > limit) mark = -1;
return this;
}
...
}
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dweiss commented on a change in pull request #1304: LUCENE-9242: generate javadocs by calling Ant javadoc task
dweiss commented on a change in pull request #1304: LUCENE-9242: generate
javadocs by calling Ant javadoc task
URL: https://github.com/apache/lucene-solr/pull/1304#discussion_r391154353
##
File path: gradle/invoke-javadoc.gradle
##
@@ -0,0 +1,335 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+// invoke javadoc tool
+
+allprojects {
+
+ ext {
+javadocRoot = project.path.startsWith(':lucene') ?
project(':lucene').file("build/docs") : project(':solr').file("build/docs")
+javadocDestDir = "${javadocRoot}/${project.name}"
+ }
+
+ plugins.withType(JavaPlugin) {
+def libName = project.path.startsWith(":lucene") ? "Lucene" : "Solr"
+def title = "${libName} ${project.version} ${project.name} API".toString()
+def srcDirs = sourceSets.main.java.srcDirs.findAll { dir -> dir.exists() }
+
+task invokeJavadoc {
+ description "Generates Javadoc API documentation for the main source
code. This invokes Ant Javadoc Task."
+ group "documentation"
+
+ dependsOn sourceSets.main.compileClasspath
+
+ inputs.property("linksource", "no")
+ inputs.property("linkJUnit", false)
+ inputs.property("linkHref", [])
+
+ inputs.files sourceSets.main.java.asFileTree
+ outputs.dir project.javadocRoot
+
+ doFirst {
+srcDirs.each { srcDir ->
+ ant.javadoc(
+ overview: file("${srcDir}/overview.html"),
+ packagenames: "org.apache.lucene.*,org.apache.solr.*",
+ destDir: project.javadocDestDir,
+ access: "protected",
+ encoding: "UTF-8",
+ charset: "UTF-8",
+ docencoding: "UTF-8",
+ noindex: "true",
+ includenosourcepackages: "true",
+ author: "true",
+ version: "true",
+ linksource: inputs.properties.linksource,
+ use: "true",
+ failonerror: "true",
+ locale: "en_US",
+ windowtitle: title,
+ doctitle: title,
+ maxmemory: "512m",
+ classpath: sourceSets.main.compileClasspath.asPath,
+ bottom: "Copyright © 2000-${buildYear} Apache Software
Foundation. All Rights Reserved."
+ ) {
+packageset(dir: srcDir)
+
+tag(name: "lucene.experimental", description: "WARNING: This API
is experimental and might change in incompatible ways in the next release.")
+tag(name: "lucene.internal", description: "NOTE: This API is for
internal purposes only and might change in incompatible ways in the next
release.")
+tag(name: "lucene.spi", description: "SPI Name (Note: This is
case-insensitive. e.g., if the name is 'htmlStrip', 'htmlstrip' can be used
when looking up the service):", scope: "types")
+
+// resolve links to JavaSE and JUnit API
+link(offline: "true", href:
"https://docs.oracle.com/en/java/javase/11/docs/api/";, packageListLoc:
project(":lucene").file("tools/javadoc/java11/").toString())
+if (inputs.properties.get("linkJUnit")) {
+ link(offline: "true", href:
"https://junit.org/junit4/javadoc/4.12/";, packageListLoc:
project(":lucene").file("tools/javadoc/junit").toString())
+}
+// resolve inter-module links if 'linkHref' property is specified
+inputs.properties.get("linkHref").each { href ->
+ link(href: href)
+}
+
+arg(line: "--release 11")
+arg(line: "-Xdoclint:all,-missing")
+
+// force locale to be "en_US" (fix for:
https://bugs.openjdk.java.net/browse/JDK-8222793)
+arg(line: "-J-Duser.language=en -J-Duser.country=US")
+ }
+}
+
+// append some special table css, prettify css
+ant.concat(destfile: "${javadocDestDir}/stylesheet.css", append:
"true", fixlastline: "true", encoding: "UTF-8") {
+ filelist(dir: project(":lucene").file("tools/javadoc"), files:
"table_padding.css")
+ filelist(dir: project(":lucene").file("tools/prettify"), files:
"prettify.css")
+}
+// append prettify to scripts
+ant.concat(destfile: "${javadocDestDi
[GitHub] [lucene-solr] tflobbe commented on a change in pull request #1335: SOLR-14316 Remove unchecked type conversion warning in JavaBinCodec's readMapEntry's equals() method
tflobbe commented on a change in pull request #1335: SOLR-14316 Remove
unchecked type conversion warning in JavaBinCodec's readMapEntry's equals()
method
URL: https://github.com/apache/lucene-solr/pull/1335#discussion_r391143892
##
File path:
solr/solrj/src/test/org/apache/solr/common/util/TestJavaBinCodec.java
##
@@ -287,6 +289,45 @@ public void testAllTypes() throws IOException {
);
}
+ @Test
+ public void testReadMapEntry() throws IOException {
+Map.Entry extryFromTextDoc1 =
getMapFromJavaBinCodec(SOLRJ_DOCS_1);
+Map.Entry extryFromTextDoc1_clone =
getMapFromJavaBinCodec(SOLRJ_DOCS_1);
+
+Map.Entry extryFromTextDoc2 =
getMapFromJavaBinCodec(SOLRJ_DOCS_2);
+Map.Entry extryFromTextDoc2_clone =
getMapFromJavaBinCodec(SOLRJ_DOCS_2);
+
+// exactly same document read twice should have same content
+assert (extryFromTextDoc1.equals(extryFromTextDoc1_clone));
Review comment:
While this would work because we force to enable assertions while running
tests, we usually use JUnit's assertions, such as `assertEquals("", obj1,
obj2);`
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] tflobbe commented on a change in pull request #1335: SOLR-14316 Remove unchecked type conversion warning in JavaBinCodec's readMapEntry's equals() method
tflobbe commented on a change in pull request #1335: SOLR-14316 Remove
unchecked type conversion warning in JavaBinCodec's readMapEntry's equals()
method
URL: https://github.com/apache/lucene-solr/pull/1335#discussion_r391146435
##
File path:
solr/solrj/src/test/org/apache/solr/common/util/TestJavaBinCodec.java
##
@@ -287,6 +289,45 @@ public void testAllTypes() throws IOException {
);
}
+ @Test
+ public void testReadMapEntry() throws IOException {
+Map.Entry extryFromTextDoc1 =
getMapFromJavaBinCodec(SOLRJ_DOCS_1);
+Map.Entry extryFromTextDoc1_clone =
getMapFromJavaBinCodec(SOLRJ_DOCS_1);
+
+Map.Entry extryFromTextDoc2 =
getMapFromJavaBinCodec(SOLRJ_DOCS_2);
+Map.Entry extryFromTextDoc2_clone =
getMapFromJavaBinCodec(SOLRJ_DOCS_2);
+
+// exactly same document read twice should have same content
+assert (extryFromTextDoc1.equals(extryFromTextDoc1_clone));
+// doc1 and doc2 are 2 text files with different content on line 1
+assert (!extryFromTextDoc2.equals(extryFromTextDoc1));
+// exactly same document read twice should have same content
+assert (extryFromTextDoc2.equals(extryFromTextDoc2_clone));
+
+// now lets look at binary files
Review comment:
suggestion, maybe take this to a different method?
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] tflobbe commented on a change in pull request #1335: SOLR-14316 Remove unchecked type conversion warning in JavaBinCodec's readMapEntry's equals() method
tflobbe commented on a change in pull request #1335: SOLR-14316 Remove
unchecked type conversion warning in JavaBinCodec's readMapEntry's equals()
method
URL: https://github.com/apache/lucene-solr/pull/1335#discussion_r391150799
##
File path:
solr/solrj/src/test/org/apache/solr/common/util/TestJavaBinCodec.java
##
@@ -287,6 +289,45 @@ public void testAllTypes() throws IOException {
);
}
+ @Test
+ public void testReadMapEntry() throws IOException {
+Map.Entry extryFromTextDoc1 =
getMapFromJavaBinCodec(SOLRJ_DOCS_1);
+Map.Entry extryFromTextDoc1_clone =
getMapFromJavaBinCodec(SOLRJ_DOCS_1);
+
+Map.Entry extryFromTextDoc2 =
getMapFromJavaBinCodec(SOLRJ_DOCS_2);
+Map.Entry extryFromTextDoc2_clone =
getMapFromJavaBinCodec(SOLRJ_DOCS_2);
+
+// exactly same document read twice should have same content
+assert (extryFromTextDoc1.equals(extryFromTextDoc1_clone));
+// doc1 and doc2 are 2 text files with different content on line 1
+assert (!extryFromTextDoc2.equals(extryFromTextDoc1));
+// exactly same document read twice should have same content
+assert (extryFromTextDoc2.equals(extryFromTextDoc2_clone));
+
+// now lets look at binary files
+Map.Entry entryFromBinFileA =
getMapFromJavaBinCodec(SOLRJ_JAVABIN_BACKCOMPAT_BIN);
+Map.Entry entryFromBinFileA_clone =
getMapFromJavaBinCodec(SOLRJ_JAVABIN_BACKCOMPAT_BIN);
+
+// as the equals assertion is based on the hashcode, even the same exact
bin file
+// will produce different Objects and hence different hashcodes
Review comment:
this is interesting. what's the type of the objects in the map for this case?
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9274) UnifiedHighlighter cannot handle SpanMultiTermQueryWrapper with an Automaton of type SINGLE
[ https://issues.apache.org/jira/browse/LUCENE-9274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christoph Goller updated LUCENE-9274: - Attachment: TestUnifiedHighlighterMTQ.java > UnifiedHighlighter cannot handle SpanMultiTermQueryWrapper with an Automaton > of type SINGLE > --- > > Key: LUCENE-9274 > URL: https://issues.apache.org/jira/browse/LUCENE-9274 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 8.4 >Reporter: Christoph Goller >Priority: Major > Attachments: TestUnifiedHighlighterMTQ.java > > > MultiTermHighlighting.extractAutomata ignores a Term from a SINGLE Automaton > and Highlighting does not work. > Of course an AutomatonQuery with a single term does not make much sense, but > it may be generated by an automatic process. > Possible fixes: > * Either implement consumeTerms in MultiTermHighlighting.AutomataCollector > * Or remove special case for SINGLE in CompiledAutomaton.visit > I attatch a Unit Test -- 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] (LUCENE-9274) UnifiedHighlighter cannot handle SpanMultiTermQueryWrapper with an Automaton of type SINGLE
Christoph Goller created LUCENE-9274: Summary: UnifiedHighlighter cannot handle SpanMultiTermQueryWrapper with an Automaton of type SINGLE Key: LUCENE-9274 URL: https://issues.apache.org/jira/browse/LUCENE-9274 Project: Lucene - Core Issue Type: Bug Affects Versions: 8.4 Reporter: Christoph Goller MultiTermHighlighting.extractAutomata ignores a Term from a SINGLE Automaton and Highlighting does not work. Of course an AutomatonQuery with a single term does not make much sense, but it may be generated by an automatic process. Possible fixes: * Either implement consumeTerms in MultiTermHighlighting.AutomataCollector * Or remove special case for SINGLE in CompiledAutomaton.visit I attatch a Unit Test -- 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-14320) TestSQLHandler failures
Mike Drob created SOLR-14320:
Summary: TestSQLHandler failures
Key: SOLR-14320
URL: https://issues.apache.org/jira/browse/SOLR-14320
Project: Solr
Issue Type: Task
Security Level: Public (Default Security Level. Issues are Public)
Environment: MacOS 10.15.3
OpenJDK 11.0.5
Reporter: Mike Drob
I'm getting a reproducible failure locally with:
{{gradlew clean :solr:core:test --tests
"org.apache.solr.handler.TestSQLHandler" -Ptests.seed=57C9372573E8FDEC}}
on current HEAD of master commit {{32a2076c605}}
cc: [~jbernste]?
--
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-8103) QueryValueSource should use TwoPhaseIterator
[ https://issues.apache.org/jira/browse/LUCENE-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057233#comment-17057233 ] David Smiley commented on LUCENE-8103: -- FWIW I find GitHub easier to conduct a code review. If you switch to that, please first commit what you have here and then after make changes so I can see what you did from iteration to iteration. minor: I suggest using the variable name "disi" for a DocIdSetIterator as this choice is quite common elsewhere. In DoubleValueSource I think it'd be better to declare the state you need like tpi, disi inside the anonymous DoubleValues class to keep the scope smaller and to reduce extra hidden indirection that I think Java adds. Also declare final where applicable. scorerMatch boolean is confusing to me; and I think the initial value as written doesn't matter either. I suggest renaming this to thisDocMatches, initialize to false (since we are unpositioned at the start), and then update it appropriately. The logic you have now around scoreMatch seems to do maybe extra work and/or isn't as simple as it could be. If doubleValue is invoked and not thisDocMatches then don't delegate to the scorer, which is probably invalid. Return NaN. In QueryValueSource.exists, maybe you could improve this a bit to be simpler; I find the way it was written prior to be confusing. > QueryValueSource should use TwoPhaseIterator > > > Key: LUCENE-8103 > URL: https://issues.apache.org/jira/browse/LUCENE-8103 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/other >Reporter: David Smiley >Priority: Minor > Attachments: LUCENE-8103.patch, LUCENE-8103.patch > > > QueryValueSource (in "queries" module) is a ValueSource representation of a > Query; the score is the value. It ought to try to use a TwoPhaseIterator > from the query if it can be offered. This will prevent possibly expensive > advancing beyond documents that we aren't interested in. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9272) No longer verify checksum of the tip file when opening the terms dict
[ https://issues.apache.org/jira/browse/LUCENE-9272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057231#comment-17057231 ] ASF subversion and git services commented on LUCENE-9272: - Commit ed59c3eb33e8fec99edec416e51113737c5e0e2e in lucene-solr's branch refs/heads/master from Adrien Grand [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ed59c3e ] LUCENE-9272: Move checksum verification of the `.tip` file to `checkIntegrity()`. (#1339) > No longer verify checksum of the tip file when opening the terms dict > - > > Key: LUCENE-9272 > URL: https://issues.apache.org/jira/browse/LUCENE-9272 > Project: Lucene - Core > Issue Type: Task >Reporter: Adrien Grand >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > We currently verify the checksum of the tip file when opening the terms > dictionary. This made sense when we would load the FST on-heap, but now that > we load it off-heap, maybe we should verify its integrity in checkIntegrity > instead, like we do for other files that we don't have to read eagerly? -- 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] jpountz merged pull request #1339: LUCENE-9272: Move checksum verification of the `.tip` file to `checkIntegrity()`.
jpountz merged pull request #1339: LUCENE-9272: Move checksum verification of the `.tip` file to `checkIntegrity()`. URL: https://github.com/apache/lucene-solr/pull/1339 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mbwaheed commented on a change in pull request #1317: SOLR-13101: Create metadataSuffix znode only at common shard creating api calls
mbwaheed commented on a change in pull request #1317: SOLR-13101: Create
metadataSuffix znode only at common shard creating api calls
URL: https://github.com/apache/lucene-solr/pull/1317#discussion_r391124376
##
File path:
solr/core/src/java/org/apache/solr/store/shared/metadata/SharedShardMetadataController.java
##
@@ -53,12 +53,12 @@ public SharedShardMetadataController(SolrCloudManager
cloudManager) {
/**
* Creates a new metadata node if it doesn't exist for shared shared index
whose correctness metadata
- * is managed by ZooKeeper
+ * is managed by ZooKeeper. This node should only be created during Shard
creation or Recovery events
*
* @param collectionName name of the collection that needs a metadata node
* @param shardName name of the shard that needs a metadata node
*/
- public void ensureMetadataNodeExists(String collectionName, String
shardName) throws IOException {
+ public void initiateMetadataNode(String collectionName, String shardName)
throws IOException {
Review comment:
Wouldn't it be more appropriate to call it createMetadataNode and fail in
case the node already exists?
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] danmuzi commented on issue #1336: LUCENE-9270: Update Javadoc about normalizeEntry in the Kuromoji DictionaryBuilder
danmuzi commented on issue #1336: LUCENE-9270: Update Javadoc about normalizeEntry in the Kuromoji DictionaryBuilder URL: https://github.com/apache/lucene-solr/pull/1336#issuecomment-597750320 Thanks for your checking, @mocobeta 👍 I'll push it to master and 8.x branch. 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] aroopganguly commented on issue #1335: SOLR-14316 Remove unchecked type conversion warning in JavaBinCodec's readMapEntry's equals() method
aroopganguly commented on issue #1335: SOLR-14316 Remove unchecked type conversion warning in JavaBinCodec's readMapEntry's equals() method URL: https://github.com/apache/lucene-solr/pull/1335#issuecomment-597734765 Thanks @anshumg I have added a changelog entry as advised. 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14197) Reduce API of SolrResourceLoader
[ https://issues.apache.org/jira/browse/SOLR-14197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057174#comment-17057174 ] ASF subversion and git services commented on SOLR-14197: Commit 17ae79b0905b2bf8635c1b260b30807cae2f5463 in lucene-solr's branch refs/heads/branch_8x from David Smiley [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=17ae79b ] SOLR-14197: SolrResourceLoader refactorings to reduce API * Deprecate SRL.listConfigDir (unused) * Deprecate SRL.getDataDir * Deprecate SRL.getCoreProperties XmlConfigFile needs to be passed in the substitutableProperties IndexSchema needs to be passed in the substitutableProperties Remove redundant Properties from CoreContainer constructors * Remove SRL.newAdminHandlerInstance (unused) * Deprecate SRL.openSchema and openConfig * Avoid SRL.getConfigDir Also harmonized similar initialization logic between DIH Tika processor & ExtractingRequestHandler. * Ensure SRL.addToClassLoader and reloadLuceneSPI are called at most once Don't auto-load "lib" in constructor; wrong place for this logic. * Avoid SRL.getInstancePath Added SolrCore.getInstancePath instead Use CoreContainer.getSolrHome instead NodeConfig should track solrHome separate from SolrResourceLoader * Simplify some SolrCore constructors * Move locateSolrHome to new SolrPaths (Deprecate existing) * Move "User Files" stuff to SolrPaths (Deprecate existing) (cherry picked from commit 732348ec7f9c6b6f7bf9d539a40e50d16198) > Reduce API of SolrResourceLoader > > > Key: SOLR-14197 > URL: https://issues.apache.org/jira/browse/SOLR-14197 > Project: Solr > Issue Type: Improvement >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Time Spent: 3h 40m > Remaining Estimate: 0h > > SolrResourceLoader must exist as an implementation of Lucene ResourceLoader. > Over time it has grown a lot more methods that are beyond the scope of doing > just that. I think SRL should be simplified to get back to its core > necessity, which hopefully allows us to make other changes (either in SRL or > nearby) with less entanglement. Some API creep: > * listConfigDir _(not used)_ > * newAdminHandlerInstance _(not used)_ > * getDataDir > * getCoreName _(only used for logging)_ > * getCoreProperties > * openSchema and configSchema _(not needed; barely used)_ > Some methods ought to go to a new subclass of SolrResourceLoader that is > specifically for a standalone-mode core: > * resourceLocation > * getConfigDir > * getInstancePath > * persistConfLocally -- 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-14054) Upgrade Tika to 1.23
[ https://issues.apache.org/jira/browse/SOLR-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057147#comment-17057147 ] Tim Allison commented on SOLR-14054: Thank you! I realize it is trivial for you. Onward! > Upgrade Tika to 1.23 > > > Key: SOLR-14054 > URL: https://issues.apache.org/jira/browse/SOLR-14054 > Project: Solr > Issue Type: Task > Components: contrib - DataImportHandler >Reporter: Tim Allison >Assignee: Tim Allison >Priority: Minor > Fix For: 8.5 > > Attachments: test-documents.7z, > tika-integration-example-9.0.0-SNAPSHOT.tgz > > Time Spent: 20m > Remaining Estimate: 0h > > We just released 1.23. Let's upgrade Tika. -- 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-14054) Upgrade Tika to 1.23
[ https://issues.apache.org/jira/browse/SOLR-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057145#comment-17057145 ] Alan Woodward commented on SOLR-14054: -- I'll handle it. > Upgrade Tika to 1.23 > > > Key: SOLR-14054 > URL: https://issues.apache.org/jira/browse/SOLR-14054 > Project: Solr > Issue Type: Task > Components: contrib - DataImportHandler >Reporter: Tim Allison >Assignee: Tim Allison >Priority: Minor > Fix For: 8.5 > > Attachments: test-documents.7z, > tika-integration-example-9.0.0-SNAPSHOT.tgz > > Time Spent: 20m > Remaining Estimate: 0h > > We just released 1.23. Let's upgrade Tika. -- 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-14054) Upgrade Tika to 1.23
[ https://issues.apache.org/jira/browse/SOLR-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057143#comment-17057143 ] Tim Allison commented on SOLR-14054: Y. I think that'd be best for Solr 8.x. The problem disappears in master with Java > 8. Would you be willing to take that, or should I give it a spin? > Upgrade Tika to 1.23 > > > Key: SOLR-14054 > URL: https://issues.apache.org/jira/browse/SOLR-14054 > Project: Solr > Issue Type: Task > Components: contrib - DataImportHandler >Reporter: Tim Allison >Assignee: Tim Allison >Priority: Minor > Fix For: 8.5 > > Attachments: test-documents.7z, > tika-integration-example-9.0.0-SNAPSHOT.tgz > > Time Spent: 20m > Remaining Estimate: 0h > > We just released 1.23. Let's upgrade Tika. -- 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-14054) Upgrade Tika to 1.23
[ https://issues.apache.org/jira/browse/SOLR-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057124#comment-17057124 ] Alan Woodward commented on SOLR-14054: -- The smoketester already has exceptions for certain third-party dependencies (eg javax.mail in dataimporthandler-extras). Maybe we should add another exception for the extraction module here? > Upgrade Tika to 1.23 > > > Key: SOLR-14054 > URL: https://issues.apache.org/jira/browse/SOLR-14054 > Project: Solr > Issue Type: Task > Components: contrib - DataImportHandler >Reporter: Tim Allison >Assignee: Tim Allison >Priority: Minor > Fix For: 8.5 > > Attachments: test-documents.7z, > tika-integration-example-9.0.0-SNAPSHOT.tgz > > Time Spent: 20m > Remaining Estimate: 0h > > We just released 1.23. Let's upgrade Tika. -- 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-14314) Solr does not response most of the update request some times
[
https://issues.apache.org/jira/browse/SOLR-14314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057112#comment-17057112
]
Ishan Chattopadhyaya commented on SOLR-14314:
-
This is expected. What you're observing is a stop-the-world GC pause. Try
running multiple Solr nodes (JVMs) on the same machine, each with about 20-25GB
heap each.
Try [www.gceasy.io|http://www.gceasy.io/] for analyzing your GC logs.
> Solr does not response most of the update request some times
>
>
> Key: SOLR-14314
> URL: https://issues.apache.org/jira/browse/SOLR-14314
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Aaron Sun
>Priority: Critical
> Attachments: jstack_bad_state.log, solrlog.tar.gz
>
>
> Solr version:
> {noformat}
> solr-spec
> 8.4.1
> solr-impl
> 8.4.1 832bf13dd9187095831caf69783179d41059d013 - ishan - 2020-01-10 13:40:28
> lucene-spec
> 8.4.1
> lucene-impl
> 8.4.1 832bf13dd9187095831caf69783179d41059d013 - ishan - 2020-01-10 13:35:00
> {noformat}
>
> Java process:
> {noformat}
> java -Xms100G -Xmx200G -DSTOP.PORT=8078 -DSTOP.KEY=ardsolrstop
> -Dsolr.solr.home=/ardome/solr -Djetty.port=8983
> -Dsolr.log.dir=/var/ardendo/log -jar start.jar --module=http
> {noformat}
> Run on a powerful server with 32 cores, 265GB RAM.
> The problem is that time to time it start to get very slow to update solr
> documents, for example time out after 30 minutes.
> document size is around 20k~50K each, each http request send to /update is
> around 4MB~10MB.
> /update request is done by multi processes.
> Some of the update get response, but the differences between "QTime" and
> http response time is big, one example, qtime = 66s, http response time is
> 2304s.
> According to jstack for the thread state, lots of BLOCKED state.
> thread dump log is attached.
> Any hint would be appreciate, thanks!
>
>
>
>
>
>
>
>
>
>
>
>
>
--
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-9229) Lucene web site broken links
[ https://issues.apache.org/jira/browse/LUCENE-9229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057108#comment-17057108 ] ASF subversion and git services commented on LUCENE-9229: - Commit d45ad8165a826ed88f2063b85799666bd8083c74 in lucene-solr's branch refs/heads/branch_8x from Cassandra Targett [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d45ad81 ] LUCENE-9229: fix Ref Guide broken links > Lucene web site broken links > > > Key: LUCENE-9229 > URL: https://issues.apache.org/jira/browse/LUCENE-9229 > Project: Lucene - Core > Issue Type: Bug > Components: general/javadocs, general/website >Reporter: Jan Høydahl >Priority: Major > Labels: newdev > > The new website is live, so I ran a dead-link checker on it to see if > anything is broken. Here is the list of dead links. A bunch of them are from > JavaDoc or from RefGuide, but some are also missing graphics on the site > itself. > Feel free to grab broken links and commit fixes either to lucene-site repo or > lucene-solr repo as you see fit. When a link is fixed, please change (x) into > (/) here so we see progress. Some of the broken links are in legacy changes > html, guess we don't need to fix those. > h2. Website > h3. [http://lucene.apache.org/pylucene/jcc/install.html] > (/) [404] [https://bugs.python.org/setuptools/issue43] > h3. [http://lucene.apache.org/pylucene/features.html] > (/) [404] [https://svn.apache.org/viewcvs.cgi/lucene/pylucene/trunk/test] > h3. [http://lucene.apache.org/solr/resources.html] > (x) [0] [http://hrishikesh.karambelkar.co.in/] > (x) [404] [http://lucenerevolution.org/past-events/] > (x) [404] [http://www.packtpub.com/apache-solr-for-indexing-data/book] > (x) [0] [http://www.inkstall.com/] > h3. [http://lucene.apache.org/pylucene/jcc/features.html] > (/) [0] [https://peak.telecommunity.com/DevCenter/EasyInstall] > h2. Javadoc > h3. [http://lucene.apache.org/solr/api/changes/Changes.html] > (/) [404] [http://wiki.apache.org/solr/FunctionQuery]. > h3. [http://lucene.apache.org/solr/api/solr-test-framework/overview-tree.html] > (x) [404] > [https://junit.org/junit4/javadoc/4.12/org/junit/rules.TestRule.html?is-external=true] > h3. > [http://lucene.apache.org/solr/api/solr-test-framework/org/apache/solr/util/RevertDefaultThreadHandlerRule.html] > (x) [404] > [https://junit.org/junit4/javadoc/4.12/org/junit/runners/model.Statement.html?is-external=true] > h3. > [http://lucene.apache.org/solr/api/solr-test-framework/org/apache/solr/util/SSLTestConfig.html] > (x) [404] > [https://junit.org/junit4/javadoc/4.12/org/junit/internal.AssumptionViolatedException.html?is-external=true] > h3. > [http://lucene.apache.org/solr/api/solr-solrj/org/apache/solr/common/util/ByteArrayUtf8CharSequence.html] > (x) [404] [http://download.java.net/java/jdk9/docs/api/java/util/Arrays.html] > h3. > [http://lucene.apache.org/solr/api/solr-solrj/org/apache/solr/client/solrj/SolrQuery.html] > (x) [404] [https://wiki.apache.org/solr/SimpleFacetParameters] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/BBoxStrategy.html] > (x) [404] > [http://geoportal.svn.sourceforge.net/svnroot/geoportal/Geoportal/trunk/src/com/esri/gpt/catalog/lucene/SpatialClauseAdapter.java] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/search/FastLRUCache.html] > (x) [404] [http://wiki.apache.org/solr/SolrCaching] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/util/hll/HLL.html] > (x) [404] > [http://guava-libraries.googlecode.com/git/guava/src/com/google/common/hash/Murmur3_128HashFunction.java] > (x) [404] > [https://github.com/aggregateknowledge/postgresql-hll/blob/master/README.markdown] > (x) [404] > [https://github.com/aggregateknowledge/postgresql-hll/blob/master/STORAGE.markdown] > h3. [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/] > (x) [404] [http://lucene.apache.org/icons/blank.gif] > (x) [404] [http://lucene.apache.org/icons/text.gif] > (x) [404] [http://lucene.apache.org/icons/folder.gif] > (x) [404] [http://lucene.apache.org/icons/back.gif] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/doc-files/] > (x) [404] [http://lucene.apache.org/icons/image2.gif] > h2. Solr Reference Guide > h3. [http://lucene.apache.org/solr/guide/updating-parts-of-documents.html] > (/) [0] > [https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=blob;f=solr/core/src/test-files/solr/collection1/conf/solrconfig-externalversionconstraint.xml;hb=HEAD] > h3. [http://lucene.apache.org/solr/guide/relevance.html] > (/) [404] > [https://lucidworks.com/blog/2009/09/02/debugging-search-application-relevance-issues/] > h3. [http://lucene.apache.org/solr/guide/tokenizers.html] > (/) [404] [http://
[jira] [Commented] (LUCENE-9229) Lucene web site broken links
[ https://issues.apache.org/jira/browse/LUCENE-9229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057109#comment-17057109 ] ASF subversion and git services commented on LUCENE-9229: - Commit d5fe7c2ad18e75f57ac9bd080c6feb12b42bffb1 in lucene-solr's branch refs/heads/branch_8_5 from Cassandra Targett [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d5fe7c2 ] LUCENE-9229: fix Ref Guide broken links > Lucene web site broken links > > > Key: LUCENE-9229 > URL: https://issues.apache.org/jira/browse/LUCENE-9229 > Project: Lucene - Core > Issue Type: Bug > Components: general/javadocs, general/website >Reporter: Jan Høydahl >Priority: Major > Labels: newdev > > The new website is live, so I ran a dead-link checker on it to see if > anything is broken. Here is the list of dead links. A bunch of them are from > JavaDoc or from RefGuide, but some are also missing graphics on the site > itself. > Feel free to grab broken links and commit fixes either to lucene-site repo or > lucene-solr repo as you see fit. When a link is fixed, please change (x) into > (/) here so we see progress. Some of the broken links are in legacy changes > html, guess we don't need to fix those. > h2. Website > h3. [http://lucene.apache.org/pylucene/jcc/install.html] > (/) [404] [https://bugs.python.org/setuptools/issue43] > h3. [http://lucene.apache.org/pylucene/features.html] > (/) [404] [https://svn.apache.org/viewcvs.cgi/lucene/pylucene/trunk/test] > h3. [http://lucene.apache.org/solr/resources.html] > (x) [0] [http://hrishikesh.karambelkar.co.in/] > (x) [404] [http://lucenerevolution.org/past-events/] > (x) [404] [http://www.packtpub.com/apache-solr-for-indexing-data/book] > (x) [0] [http://www.inkstall.com/] > h3. [http://lucene.apache.org/pylucene/jcc/features.html] > (/) [0] [https://peak.telecommunity.com/DevCenter/EasyInstall] > h2. Javadoc > h3. [http://lucene.apache.org/solr/api/changes/Changes.html] > (/) [404] [http://wiki.apache.org/solr/FunctionQuery]. > h3. [http://lucene.apache.org/solr/api/solr-test-framework/overview-tree.html] > (x) [404] > [https://junit.org/junit4/javadoc/4.12/org/junit/rules.TestRule.html?is-external=true] > h3. > [http://lucene.apache.org/solr/api/solr-test-framework/org/apache/solr/util/RevertDefaultThreadHandlerRule.html] > (x) [404] > [https://junit.org/junit4/javadoc/4.12/org/junit/runners/model.Statement.html?is-external=true] > h3. > [http://lucene.apache.org/solr/api/solr-test-framework/org/apache/solr/util/SSLTestConfig.html] > (x) [404] > [https://junit.org/junit4/javadoc/4.12/org/junit/internal.AssumptionViolatedException.html?is-external=true] > h3. > [http://lucene.apache.org/solr/api/solr-solrj/org/apache/solr/common/util/ByteArrayUtf8CharSequence.html] > (x) [404] [http://download.java.net/java/jdk9/docs/api/java/util/Arrays.html] > h3. > [http://lucene.apache.org/solr/api/solr-solrj/org/apache/solr/client/solrj/SolrQuery.html] > (x) [404] [https://wiki.apache.org/solr/SimpleFacetParameters] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/BBoxStrategy.html] > (x) [404] > [http://geoportal.svn.sourceforge.net/svnroot/geoportal/Geoportal/trunk/src/com/esri/gpt/catalog/lucene/SpatialClauseAdapter.java] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/search/FastLRUCache.html] > (x) [404] [http://wiki.apache.org/solr/SolrCaching] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/util/hll/HLL.html] > (x) [404] > [http://guava-libraries.googlecode.com/git/guava/src/com/google/common/hash/Murmur3_128HashFunction.java] > (x) [404] > [https://github.com/aggregateknowledge/postgresql-hll/blob/master/README.markdown] > (x) [404] > [https://github.com/aggregateknowledge/postgresql-hll/blob/master/STORAGE.markdown] > h3. [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/] > (x) [404] [http://lucene.apache.org/icons/blank.gif] > (x) [404] [http://lucene.apache.org/icons/text.gif] > (x) [404] [http://lucene.apache.org/icons/folder.gif] > (x) [404] [http://lucene.apache.org/icons/back.gif] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/doc-files/] > (x) [404] [http://lucene.apache.org/icons/image2.gif] > h2. Solr Reference Guide > h3. [http://lucene.apache.org/solr/guide/updating-parts-of-documents.html] > (/) [0] > [https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=blob;f=solr/core/src/test-files/solr/collection1/conf/solrconfig-externalversionconstraint.xml;hb=HEAD] > h3. [http://lucene.apache.org/solr/guide/relevance.html] > (/) [404] > [https://lucidworks.com/blog/2009/09/02/debugging-search-application-relevance-issues/] > h3. [http://lucene.apache.org/solr/guide/tokenizers.html] > (/) [404] [http:/
[jira] [Commented] (LUCENE-9229) Lucene web site broken links
[ https://issues.apache.org/jira/browse/LUCENE-9229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057107#comment-17057107 ] ASF subversion and git services commented on LUCENE-9229: - Commit 32a2076c605e80cda1c8c93b1e5a0ffe5e90e84e in lucene-solr's branch refs/heads/master from Cassandra Targett [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=32a2076 ] LUCENE-9229: fix Ref Guide broken links > Lucene web site broken links > > > Key: LUCENE-9229 > URL: https://issues.apache.org/jira/browse/LUCENE-9229 > Project: Lucene - Core > Issue Type: Bug > Components: general/javadocs, general/website >Reporter: Jan Høydahl >Priority: Major > Labels: newdev > > The new website is live, so I ran a dead-link checker on it to see if > anything is broken. Here is the list of dead links. A bunch of them are from > JavaDoc or from RefGuide, but some are also missing graphics on the site > itself. > Feel free to grab broken links and commit fixes either to lucene-site repo or > lucene-solr repo as you see fit. When a link is fixed, please change (x) into > (/) here so we see progress. Some of the broken links are in legacy changes > html, guess we don't need to fix those. > h2. Website > h3. [http://lucene.apache.org/pylucene/jcc/install.html] > (/) [404] [https://bugs.python.org/setuptools/issue43] > h3. [http://lucene.apache.org/pylucene/features.html] > (/) [404] [https://svn.apache.org/viewcvs.cgi/lucene/pylucene/trunk/test] > h3. [http://lucene.apache.org/solr/resources.html] > (x) [0] [http://hrishikesh.karambelkar.co.in/] > (x) [404] [http://lucenerevolution.org/past-events/] > (x) [404] [http://www.packtpub.com/apache-solr-for-indexing-data/book] > (x) [0] [http://www.inkstall.com/] > h3. [http://lucene.apache.org/pylucene/jcc/features.html] > (/) [0] [https://peak.telecommunity.com/DevCenter/EasyInstall] > h2. Javadoc > h3. [http://lucene.apache.org/solr/api/changes/Changes.html] > (/) [404] [http://wiki.apache.org/solr/FunctionQuery]. > h3. [http://lucene.apache.org/solr/api/solr-test-framework/overview-tree.html] > (x) [404] > [https://junit.org/junit4/javadoc/4.12/org/junit/rules.TestRule.html?is-external=true] > h3. > [http://lucene.apache.org/solr/api/solr-test-framework/org/apache/solr/util/RevertDefaultThreadHandlerRule.html] > (x) [404] > [https://junit.org/junit4/javadoc/4.12/org/junit/runners/model.Statement.html?is-external=true] > h3. > [http://lucene.apache.org/solr/api/solr-test-framework/org/apache/solr/util/SSLTestConfig.html] > (x) [404] > [https://junit.org/junit4/javadoc/4.12/org/junit/internal.AssumptionViolatedException.html?is-external=true] > h3. > [http://lucene.apache.org/solr/api/solr-solrj/org/apache/solr/common/util/ByteArrayUtf8CharSequence.html] > (x) [404] [http://download.java.net/java/jdk9/docs/api/java/util/Arrays.html] > h3. > [http://lucene.apache.org/solr/api/solr-solrj/org/apache/solr/client/solrj/SolrQuery.html] > (x) [404] [https://wiki.apache.org/solr/SimpleFacetParameters] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/BBoxStrategy.html] > (x) [404] > [http://geoportal.svn.sourceforge.net/svnroot/geoportal/Geoportal/trunk/src/com/esri/gpt/catalog/lucene/SpatialClauseAdapter.java] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/search/FastLRUCache.html] > (x) [404] [http://wiki.apache.org/solr/SolrCaching] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/util/hll/HLL.html] > (x) [404] > [http://guava-libraries.googlecode.com/git/guava/src/com/google/common/hash/Murmur3_128HashFunction.java] > (x) [404] > [https://github.com/aggregateknowledge/postgresql-hll/blob/master/README.markdown] > (x) [404] > [https://github.com/aggregateknowledge/postgresql-hll/blob/master/STORAGE.markdown] > h3. [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/] > (x) [404] [http://lucene.apache.org/icons/blank.gif] > (x) [404] [http://lucene.apache.org/icons/text.gif] > (x) [404] [http://lucene.apache.org/icons/folder.gif] > (x) [404] [http://lucene.apache.org/icons/back.gif] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/doc-files/] > (x) [404] [http://lucene.apache.org/icons/image2.gif] > h2. Solr Reference Guide > h3. [http://lucene.apache.org/solr/guide/updating-parts-of-documents.html] > (/) [0] > [https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=blob;f=solr/core/src/test-files/solr/collection1/conf/solrconfig-externalversionconstraint.xml;hb=HEAD] > h3. [http://lucene.apache.org/solr/guide/relevance.html] > (/) [404] > [https://lucidworks.com/blog/2009/09/02/debugging-search-application-relevance-issues/] > h3. [http://lucene.apache.org/solr/guide/tokenizers.html] > (/) [404] [http://acc
[jira] [Commented] (LUCENE-9229) Lucene web site broken links
[ https://issues.apache.org/jira/browse/LUCENE-9229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057106#comment-17057106 ] Cassandra Targett commented on LUCENE-9229: --- I fixed all the ones I could for the Ref Guide (commit incoming) - the ones I did not fix are ones I cannot find a suitable replacement and don't understand the topic well enough to know if simply removing the link entirely is a reasonable choice. > Lucene web site broken links > > > Key: LUCENE-9229 > URL: https://issues.apache.org/jira/browse/LUCENE-9229 > Project: Lucene - Core > Issue Type: Bug > Components: general/javadocs, general/website >Reporter: Jan Høydahl >Priority: Major > Labels: newdev > > The new website is live, so I ran a dead-link checker on it to see if > anything is broken. Here is the list of dead links. A bunch of them are from > JavaDoc or from RefGuide, but some are also missing graphics on the site > itself. > Feel free to grab broken links and commit fixes either to lucene-site repo or > lucene-solr repo as you see fit. When a link is fixed, please change (x) into > (/) here so we see progress. Some of the broken links are in legacy changes > html, guess we don't need to fix those. > h2. Website > h3. [http://lucene.apache.org/pylucene/jcc/install.html] > (/) [404] [https://bugs.python.org/setuptools/issue43] > h3. [http://lucene.apache.org/pylucene/features.html] > (/) [404] [https://svn.apache.org/viewcvs.cgi/lucene/pylucene/trunk/test] > h3. [http://lucene.apache.org/solr/resources.html] > (x) [0] [http://hrishikesh.karambelkar.co.in/] > (x) [404] [http://lucenerevolution.org/past-events/] > (x) [404] [http://www.packtpub.com/apache-solr-for-indexing-data/book] > (x) [0] [http://www.inkstall.com/] > h3. [http://lucene.apache.org/pylucene/jcc/features.html] > (/) [0] [https://peak.telecommunity.com/DevCenter/EasyInstall] > h2. Javadoc > h3. [http://lucene.apache.org/solr/api/changes/Changes.html] > (/) [404] [http://wiki.apache.org/solr/FunctionQuery]. > h3. [http://lucene.apache.org/solr/api/solr-test-framework/overview-tree.html] > (x) [404] > [https://junit.org/junit4/javadoc/4.12/org/junit/rules.TestRule.html?is-external=true] > h3. > [http://lucene.apache.org/solr/api/solr-test-framework/org/apache/solr/util/RevertDefaultThreadHandlerRule.html] > (x) [404] > [https://junit.org/junit4/javadoc/4.12/org/junit/runners/model.Statement.html?is-external=true] > h3. > [http://lucene.apache.org/solr/api/solr-test-framework/org/apache/solr/util/SSLTestConfig.html] > (x) [404] > [https://junit.org/junit4/javadoc/4.12/org/junit/internal.AssumptionViolatedException.html?is-external=true] > h3. > [http://lucene.apache.org/solr/api/solr-solrj/org/apache/solr/common/util/ByteArrayUtf8CharSequence.html] > (x) [404] [http://download.java.net/java/jdk9/docs/api/java/util/Arrays.html] > h3. > [http://lucene.apache.org/solr/api/solr-solrj/org/apache/solr/client/solrj/SolrQuery.html] > (x) [404] [https://wiki.apache.org/solr/SimpleFacetParameters] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/BBoxStrategy.html] > (x) [404] > [http://geoportal.svn.sourceforge.net/svnroot/geoportal/Geoportal/trunk/src/com/esri/gpt/catalog/lucene/SpatialClauseAdapter.java] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/search/FastLRUCache.html] > (x) [404] [http://wiki.apache.org/solr/SolrCaching] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/util/hll/HLL.html] > (x) [404] > [http://guava-libraries.googlecode.com/git/guava/src/com/google/common/hash/Murmur3_128HashFunction.java] > (x) [404] > [https://github.com/aggregateknowledge/postgresql-hll/blob/master/README.markdown] > (x) [404] > [https://github.com/aggregateknowledge/postgresql-hll/blob/master/STORAGE.markdown] > h3. [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/] > (x) [404] [http://lucene.apache.org/icons/blank.gif] > (x) [404] [http://lucene.apache.org/icons/text.gif] > (x) [404] [http://lucene.apache.org/icons/folder.gif] > (x) [404] [http://lucene.apache.org/icons/back.gif] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/doc-files/] > (x) [404] [http://lucene.apache.org/icons/image2.gif] > h2. Solr Reference Guide > h3. [http://lucene.apache.org/solr/guide/updating-parts-of-documents.html] > (/) [0] > [https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=blob;f=solr/core/src/test-files/solr/collection1/conf/solrconfig-externalversionconstraint.xml;hb=HEAD] > h3. [http://lucene.apache.org/solr/guide/relevance.html] > (/) [404] > [https://lucidworks.com/blog/2009/09/02/debugging-search-application-relevance-issues/] > h3. [http://lucene.apache.org/solr/guide/tokenizers.html] > (/) [404] [http://acca
[jira] [Updated] (LUCENE-9229) Lucene web site broken links
[ https://issues.apache.org/jira/browse/LUCENE-9229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett updated LUCENE-9229: -- Description: The new website is live, so I ran a dead-link checker on it to see if anything is broken. Here is the list of dead links. A bunch of them are from JavaDoc or from RefGuide, but some are also missing graphics on the site itself. Feel free to grab broken links and commit fixes either to lucene-site repo or lucene-solr repo as you see fit. When a link is fixed, please change (x) into (/) here so we see progress. Some of the broken links are in legacy changes html, guess we don't need to fix those. h2. Website h3. [http://lucene.apache.org/pylucene/jcc/install.html] (/) [404] [https://bugs.python.org/setuptools/issue43] h3. [http://lucene.apache.org/pylucene/features.html] (/) [404] [https://svn.apache.org/viewcvs.cgi/lucene/pylucene/trunk/test] h3. [http://lucene.apache.org/solr/resources.html] (x) [0] [http://hrishikesh.karambelkar.co.in/] (x) [404] [http://lucenerevolution.org/past-events/] (x) [404] [http://www.packtpub.com/apache-solr-for-indexing-data/book] (x) [0] [http://www.inkstall.com/] h3. [http://lucene.apache.org/pylucene/jcc/features.html] (/) [0] [https://peak.telecommunity.com/DevCenter/EasyInstall] h2. Javadoc h3. [http://lucene.apache.org/solr/api/changes/Changes.html] (/) [404] [http://wiki.apache.org/solr/FunctionQuery]. h3. [http://lucene.apache.org/solr/api/solr-test-framework/overview-tree.html] (x) [404] [https://junit.org/junit4/javadoc/4.12/org/junit/rules.TestRule.html?is-external=true] h3. [http://lucene.apache.org/solr/api/solr-test-framework/org/apache/solr/util/RevertDefaultThreadHandlerRule.html] (x) [404] [https://junit.org/junit4/javadoc/4.12/org/junit/runners/model.Statement.html?is-external=true] h3. [http://lucene.apache.org/solr/api/solr-test-framework/org/apache/solr/util/SSLTestConfig.html] (x) [404] [https://junit.org/junit4/javadoc/4.12/org/junit/internal.AssumptionViolatedException.html?is-external=true] h3. [http://lucene.apache.org/solr/api/solr-solrj/org/apache/solr/common/util/ByteArrayUtf8CharSequence.html] (x) [404] [http://download.java.net/java/jdk9/docs/api/java/util/Arrays.html] h3. [http://lucene.apache.org/solr/api/solr-solrj/org/apache/solr/client/solrj/SolrQuery.html] (x) [404] [https://wiki.apache.org/solr/SimpleFacetParameters] h3. [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/BBoxStrategy.html] (x) [404] [http://geoportal.svn.sourceforge.net/svnroot/geoportal/Geoportal/trunk/src/com/esri/gpt/catalog/lucene/SpatialClauseAdapter.java] h3. [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/search/FastLRUCache.html] (x) [404] [http://wiki.apache.org/solr/SolrCaching] h3. [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/util/hll/HLL.html] (x) [404] [http://guava-libraries.googlecode.com/git/guava/src/com/google/common/hash/Murmur3_128HashFunction.java] (x) [404] [https://github.com/aggregateknowledge/postgresql-hll/blob/master/README.markdown] (x) [404] [https://github.com/aggregateknowledge/postgresql-hll/blob/master/STORAGE.markdown] h3. [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/] (x) [404] [http://lucene.apache.org/icons/blank.gif] (x) [404] [http://lucene.apache.org/icons/text.gif] (x) [404] [http://lucene.apache.org/icons/folder.gif] (x) [404] [http://lucene.apache.org/icons/back.gif] h3. [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/doc-files/] (x) [404] [http://lucene.apache.org/icons/image2.gif] h2. Solr Reference Guide h3. [http://lucene.apache.org/solr/guide/updating-parts-of-documents.html] (/) [0] [https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=blob;f=solr/core/src/test-files/solr/collection1/conf/solrconfig-externalversionconstraint.xml;hb=HEAD] h3. [http://lucene.apache.org/solr/guide/relevance.html] (/) [404] [https://lucidworks.com/blog/2009/09/02/debugging-search-application-relevance-issues/] h3. [http://lucene.apache.org/solr/guide/tokenizers.html] (/) [404] [http://accarol.com/contact.htm?from=external&a=10] h3. [http://lucene.apache.org/solr/guide/language-analysis.html] (/) [404] [http://www.users.muohio.edu/canf/papers/JASIST2008offPrint.pdf] (x) [0] [http://ldc.upenn.edu/myl/IndianScriptsUnicode.html] h3. [http://lucene.apache.org/solr/guide/response-writers.html] (/) [0] [http://wiki.fasterxml.com/SmileFormat] h3. [http://lucene.apache.org/solr/guide/faceting.html] (/) [0] [http://doctypepdf/] h3. [http://lucene.apache.org/solr/guide/spatial-search.html] (/) [0] [http://central.maven.org/maven2/org/locationtech/jts/jts-core/1.15.0/] h3. [http://lucene.apache.org/solr/guide/result-clustering.html] (/) [404] [http://search.carrot2.org/stable/search?query=solr&results=100&source=web&view=foamtree] (x) [404] [https://github.com/carrot2/carrot
[jira] [Commented] (LUCENE-9242) Gradle Javadoc task should output the same documents as Ant
[
https://issues.apache.org/jira/browse/LUCENE-9242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057093#comment-17057093
]
ASF subversion and git services commented on LUCENE-9242:
-
Commit d4a137d2b694156ac175d6c8f1fcb4fcf30bc756 in lucene-solr's branch
refs/heads/master from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d4a137d ]
LUCENE-9242: generate javadocs by calling Ant javadoc task (#1304)
> Gradle Javadoc task should output the same documents as Ant
> ---
>
> Key: LUCENE-9242
> URL: https://issues.apache.org/jira/browse/LUCENE-9242
> Project: Lucene - Core
> Issue Type: Sub-task
> Components: general/javadocs
>Affects Versions: master (9.0)
>Reporter: Tomoko Uchida
>Priority: Major
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> "javadoc" task for the Gradle build does not correctly output package
> summaries, since it ignores "package.html" file in the source tree (so the
> Python linter {{checkJavaDocs.py}} detects that and fails for now.)
> Also the "javadoc" task should make inter-module links just as Ant build does.
> See for more details: LUCENE-9201
--
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] mocobeta merged pull request #1304: LUCENE-9242: generate javadocs by calling Ant javadoc task
mocobeta merged pull request #1304: LUCENE-9242: generate javadocs by calling Ant javadoc task URL: https://github.com/apache/lucene-solr/pull/1304 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 With regards, Apache Git Services - 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 issue #1338: LUCENE-9271: Move BufferedIndexInput to the ByteBuffer API
jpountz commented on issue #1338: LUCENE-9271: Move BufferedIndexInput to the ByteBuffer API URL: https://github.com/apache/lucene-solr/pull/1338#issuecomment-597688851 Good call. 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8103) QueryValueSource should use TwoPhaseIterator
[ https://issues.apache.org/jira/browse/LUCENE-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michele Palmia updated LUCENE-8103: --- Attachment: LUCENE-8103.patch > QueryValueSource should use TwoPhaseIterator > > > Key: LUCENE-8103 > URL: https://issues.apache.org/jira/browse/LUCENE-8103 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/other >Reporter: David Smiley >Priority: Minor > Attachments: LUCENE-8103.patch, LUCENE-8103.patch > > > QueryValueSource (in "queries" module) is a ValueSource representation of a > Query; the score is the value. It ought to try to use a TwoPhaseIterator > from the query if it can be offered. This will prevent possibly expensive > advancing beyond documents that we aren't interested in. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mocobeta commented on a change in pull request #1304: LUCENE-9242: generate javadocs by calling Ant javadoc task
mocobeta commented on a change in pull request #1304: LUCENE-9242: generate
javadocs by calling Ant javadoc task
URL: https://github.com/apache/lucene-solr/pull/1304#discussion_r391034886
##
File path: gradle/invoke-javadoc.gradle
##
@@ -0,0 +1,335 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+// invoke javadoc tool
+
+allprojects {
+
+ ext {
+javadocRoot = project.path.startsWith(':lucene') ?
project(':lucene').file("build/docs") : project(':solr').file("build/docs")
+javadocDestDir = "${javadocRoot}/${project.name}"
+ }
+
+ plugins.withType(JavaPlugin) {
+def libName = project.path.startsWith(":lucene") ? "Lucene" : "Solr"
+def title = "${libName} ${project.version} ${project.name} API".toString()
+def srcDirs = sourceSets.main.java.srcDirs.findAll { dir -> dir.exists() }
+
+task invokeJavadoc {
+ description "Generates Javadoc API documentation for the main source
code. This invokes Ant Javadoc Task."
+ group "documentation"
+
+ dependsOn sourceSets.main.compileClasspath
+
+ inputs.property("linksource", "no")
+ inputs.property("linkJUnit", false)
+ inputs.property("linkHref", [])
+
+ inputs.files sourceSets.main.java.asFileTree
+ outputs.dir project.javadocRoot
+
+ doFirst {
+srcDirs.each { srcDir ->
+ ant.javadoc(
+ overview: file("${srcDir}/overview.html"),
+ packagenames: "org.apache.lucene.*,org.apache.solr.*",
+ destDir: project.javadocDestDir,
+ access: "protected",
+ encoding: "UTF-8",
+ charset: "UTF-8",
+ docencoding: "UTF-8",
+ noindex: "true",
+ includenosourcepackages: "true",
+ author: "true",
+ version: "true",
+ linksource: inputs.properties.linksource,
+ use: "true",
+ failonerror: "true",
+ locale: "en_US",
+ windowtitle: title,
+ doctitle: title,
+ maxmemory: "512m",
+ classpath: sourceSets.main.compileClasspath.asPath,
+ bottom: "Copyright © 2000-${buildYear} Apache Software
Foundation. All Rights Reserved."
+ ) {
+packageset(dir: srcDir)
+
+tag(name: "lucene.experimental", description: "WARNING: This API
is experimental and might change in incompatible ways in the next release.")
+tag(name: "lucene.internal", description: "NOTE: This API is for
internal purposes only and might change in incompatible ways in the next
release.")
+tag(name: "lucene.spi", description: "SPI Name (Note: This is
case-insensitive. e.g., if the name is 'htmlStrip', 'htmlstrip' can be used
when looking up the service):", scope: "types")
+
+// resolve links to JavaSE and JUnit API
+link(offline: "true", href:
"https://docs.oracle.com/en/java/javase/11/docs/api/";, packageListLoc:
project(":lucene").file("tools/javadoc/java11/").toString())
+if (inputs.properties.get("linkJUnit")) {
+ link(offline: "true", href:
"https://junit.org/junit4/javadoc/4.12/";, packageListLoc:
project(":lucene").file("tools/javadoc/junit").toString())
+}
+// resolve inter-module links if 'linkHref' property is specified
+inputs.properties.get("linkHref").each { href ->
+ link(href: href)
+}
+
+arg(line: "--release 11")
+arg(line: "-Xdoclint:all,-missing")
+
+// force locale to be "en_US" (fix for:
https://bugs.openjdk.java.net/browse/JDK-8222793)
+arg(line: "-J-Duser.language=en -J-Duser.country=US")
+ }
+}
+
+// append some special table css, prettify css
+ant.concat(destfile: "${javadocDestDir}/stylesheet.css", append:
"true", fixlastline: "true", encoding: "UTF-8") {
+ filelist(dir: project(":lucene").file("tools/javadoc"), files:
"table_padding.css")
+ filelist(dir: project(":lucene").file("tools/prettify"), files:
"prettify.css")
+}
+// append prettify to scripts
+ant.concat(destfile: "${javadocDest
[jira] [Commented] (LUCENE-8103) QueryValueSource should use TwoPhaseIterator
[ https://issues.apache.org/jira/browse/LUCENE-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057083#comment-17057083 ] Michele Palmia commented on LUCENE-8103: Extremely sorry for wasting your time 🤦🏻♂️. [^LUCENE-8103.patch] > QueryValueSource should use TwoPhaseIterator > > > Key: LUCENE-8103 > URL: https://issues.apache.org/jira/browse/LUCENE-8103 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/other >Reporter: David Smiley >Priority: Minor > Attachments: LUCENE-8103.patch, LUCENE-8103.patch > > > QueryValueSource (in "queries" module) is a ValueSource representation of a > Query; the score is the value. It ought to try to use a TwoPhaseIterator > from the query if it can be offered. This will prevent possibly expensive > advancing beyond documents that we aren't interested in. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14314) Solr does not response most of the update request some times
[
https://issues.apache.org/jira/browse/SOLR-14314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057047#comment-17057047
]
Aaron Sun edited comment on SOLR-14314 at 3/11/20, 2:52 PM:
[~ichattopadhyaya] [~erickerickson] Thanks for the quick response and
appreciate for the help!
The slow response state is not always happens, it seems under some heavy load
it start to happen more often, such as client send burst of queries and add
commands at the same time.
After enable more logging, I notice some times the logging just pause some
seconds, it looks like something is blocking(or too busy to process? CPU/IO?)
{noformat}
{noformat}
Here are some examples:
{noformat}
2020-03-11 15:00:18.101 DEBUG (qtp820914198-32) [ x:agglogtrackitem]
o.a.s.u.p.LogUpdateProcessorFactory PRE_UPDATE
commit\{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
\{{params(commit=true),defaults(wt=json)}}
2020-03-11 15:00:29.111 TRACE (qtp820914198-121) [ x:agglogtrackitem]
o.a.s.u.UpdateLog TLOG: added id 2101702210439403924 to
tlog\{file=/ardome/solr/agglogtrackitem/data/tlog/tlog.0040378
refcount=1} LogPtr(62560436) map=27492440
2020-03-11 15:02:01.019 DEBUG (qtp820914198-101) [ x:agglogtrackitem]
o.a.s.u.p.LogUpdateProcessorFactory PRE_UPDATE
commit\{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
\{{params(commit=true),defaults(wt=json)}}
2020-03-11 15:02:06.583 TRACE (qtp820914198-28) [ x:agglogtrackitem]
o.a.s.u.UpdateLog TLOG: added id 2101802040421290224 to
tlog\{file=/ardome/solr/agglogtrackitem/data/tlog/tlog.0040552
refcount=1} LogPtr(5925467) map=2138772739
2020-03-11 15:02:06.584 DEBUG (qtp820914198-28) [ x:agglogtrackitem]
o.a.s.u.p.LogUpdateProcessorFactory PRE_UPDATE add\{,id=2101802040421395124}
\{{params(commit=true),defaults(wt=json)}}
2020-03-11 15:02:42.897 TRACE (qtp820914198-128) [ x:agglogtrackitem]
o.a.s.u.UpdateLog TLOG: added id 2101702240520633224 to
tlog\{file=/ardome/solr/agglogtrackitem/data/tlog/tlog.0040606
refcount=1} LogPtr(82150345) map=522043138
2020-03-11 15:02:42.897 DEBUG (qtp820914198-128) [ x:agglogtrackitem]
o.a.s.u.p.LogUpdateProcessorFactory PRE_UPDATE
commit\{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
\{{params(commit=true),defaults(wt=json)}}
2020-03-11 15:03:10.117 TRACE (qtp820914198-124) [ x:agglogtrackitem]
o.a.s.u.UpdateLog TLOG: added id 2101702170101660124 to
tlog\{file=/ardome/solr/agglogtrackitem/data/tlog/tlog.0040606
refcount=1} LogPtr(82154733) map=522043138
{noformat}
Client side start to timeout around this time, then time gap in the log
happens more frequently. while the client was sending "add" documents command
continuously, I guess solr shouldn't pause the processing, isn't it?
{noformat}
2020-03-11 15:07:56.699 DEBUG (qtp820914198-1287) [ x:agglogtrackitem]
o.a.s.u.p.LogUpdateProcessorFactory PRE_UPDATE
commit\{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
{{params(commit=true),defaults(wt=
json)}}
2020-03-11 15:08:09.886 TRACE (qtp820914198-1409) [ x:agglogtrackitem]
o.a.s.u.UpdateLog TLOG: added id 2101703060206960524 to
tlog\{file=/ardome/solr/agglogtrackitem/data/tlog/tlog.0040713
refcount=1} LogPtr(50692808) map=35667164
{noformat}
Look at the time stamp gap when follow id qtp820914198-1573
{noformat}
2020-03-11 15:19:15.386 DEBUG (qtp820914198-1573) [ x:agglogtrackitem]
o.a.s.u.DirectUpdateHandler2
updateDocument(add\{_version_=1660877647781036033,id=2101907210548759024})
2020-03-11 15:19:35.983 TRACE (qtp820914198-1573) [ x:agglogtrackitem]
o.a.s.u.UpdateLog TLOG: added id 2101907210548759024 to
tlog\{file=/ardome/solr/agglogtrackitem/data/tlog/tlog.0040731
refcount=1} LogPtr(31050261) map=96441216
2020-03-11 15:19:35.984 DEBUG (qtp820914198-1573) [ x:agglogtrackitem]
o.a.s.u.p.LogUpdateProcessorFactory PRE_UPDATE add\{,id=2101907250565323024}
\{{params(commit=true),defaults(wt=json)}}
2020-03-11 15:19:36.228 DEBUG (qtp820914198-1573) [ x:agglogtrackitem]
o.a.s.u.DirectUpdateHandler2
updateDocument(add\{_version_=1660877669383798784,id=2101907250565323024})
2020-03-11 15:19:41.343 TRACE (qtp820914198-1573) [ x:agglogtrackitem]
o.a.s.u.UpdateLog TLOG: added id 2101907250565323024 to
tlog\{file=/ardome/solr/agglogtrackitem/data/tlog/tlog.0040732
refcount=1} LogPtr(10205943) map=103629868
2020-03-11 15:19:41.343 DEBUG (qtp820914198-1573) [ x:agglogtrackitem]
o.a.s.u.p.LogUpdateProcessorFactory PRE_UPDATE add\{,id=2101907210548498324}
\{{params(commit=true),defaults(wt=json)}}
2020-03-11 15:19:41.346 DEBUG (qtp820914198-1573) [ x:agglogtrackitem]
[jira] [Updated] (LUCENE-9229) Lucene web site broken links
[ https://issues.apache.org/jira/browse/LUCENE-9229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett updated LUCENE-9229: -- Description: The new website is live, so I ran a dead-link checker on it to see if anything is broken. Here is the list of dead links. A bunch of them are from JavaDoc or from RefGuide, but some are also missing graphics on the site itself. Feel free to grab broken links and commit fixes either to lucene-site repo or lucene-solr repo as you see fit. When a link is fixed, please change (x) into (/) here so we see progress. Some of the broken links are in legacy changes html, guess we don't need to fix those. h2. Website h3. [http://lucene.apache.org/pylucene/jcc/install.html] (/) [404] [https://bugs.python.org/setuptools/issue43] h3. [http://lucene.apache.org/pylucene/features.html] (/) [404] [https://svn.apache.org/viewcvs.cgi/lucene/pylucene/trunk/test] h3. [http://lucene.apache.org/solr/resources.html] (x) [0] [http://hrishikesh.karambelkar.co.in/] (x) [404] [http://lucenerevolution.org/past-events/] (x) [404] [http://www.packtpub.com/apache-solr-for-indexing-data/book] (x) [0] [http://www.inkstall.com/] h3. [http://lucene.apache.org/pylucene/jcc/features.html] (/) [0] [https://peak.telecommunity.com/DevCenter/EasyInstall] h2. Javadoc h3. [http://lucene.apache.org/solr/api/changes/Changes.html] (/) [404] [http://wiki.apache.org/solr/FunctionQuery]. h3. [http://lucene.apache.org/solr/api/solr-test-framework/overview-tree.html] (x) [404] [https://junit.org/junit4/javadoc/4.12/org/junit/rules.TestRule.html?is-external=true] h3. [http://lucene.apache.org/solr/api/solr-test-framework/org/apache/solr/util/RevertDefaultThreadHandlerRule.html] (x) [404] [https://junit.org/junit4/javadoc/4.12/org/junit/runners/model.Statement.html?is-external=true] h3. [http://lucene.apache.org/solr/api/solr-test-framework/org/apache/solr/util/SSLTestConfig.html] (x) [404] [https://junit.org/junit4/javadoc/4.12/org/junit/internal.AssumptionViolatedException.html?is-external=true] h3. [http://lucene.apache.org/solr/api/solr-solrj/org/apache/solr/common/util/ByteArrayUtf8CharSequence.html] (x) [404] [http://download.java.net/java/jdk9/docs/api/java/util/Arrays.html] h3. [http://lucene.apache.org/solr/api/solr-solrj/org/apache/solr/client/solrj/SolrQuery.html] (x) [404] [https://wiki.apache.org/solr/SimpleFacetParameters] h3. [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/BBoxStrategy.html] (x) [404] [http://geoportal.svn.sourceforge.net/svnroot/geoportal/Geoportal/trunk/src/com/esri/gpt/catalog/lucene/SpatialClauseAdapter.java] h3. [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/search/FastLRUCache.html] (x) [404] [http://wiki.apache.org/solr/SolrCaching] h3. [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/util/hll/HLL.html] (x) [404] [http://guava-libraries.googlecode.com/git/guava/src/com/google/common/hash/Murmur3_128HashFunction.java] (x) [404] [https://github.com/aggregateknowledge/postgresql-hll/blob/master/README.markdown] (x) [404] [https://github.com/aggregateknowledge/postgresql-hll/blob/master/STORAGE.markdown] h3. [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/] (x) [404] [http://lucene.apache.org/icons/blank.gif] (x) [404] [http://lucene.apache.org/icons/text.gif] (x) [404] [http://lucene.apache.org/icons/folder.gif] (x) [404] [http://lucene.apache.org/icons/back.gif] h3. [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/doc-files/] (x) [404] [http://lucene.apache.org/icons/image2.gif] h2. Solr Reference Guide h3. [http://lucene.apache.org/solr/guide/updating-parts-of-documents.html] (/) [0] [https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=blob;f=solr/core/src/test-files/solr/collection1/conf/solrconfig-externalversionconstraint.xml;hb=HEAD] h3. [http://lucene.apache.org/solr/guide/relevance.html] (x) [404] [https://lucidworks.com/blog/2009/09/02/debugging-search-application-relevance-issues/] h3. [http://lucene.apache.org/solr/guide/tokenizers.html] (x) [404] [http://accarol.com/contact.htm?from=external&a=10] h3. [http://lucene.apache.org/solr/guide/language-analysis.html] (x) [404] [http://www.users.muohio.edu/canf/papers/JASIST2008offPrint.pdf] (x) [0] [http://ldc.upenn.edu/myl/IndianScriptsUnicode.html] h3. [http://lucene.apache.org/solr/guide/response-writers.html] (/) [0] [http://wiki.fasterxml.com/SmileFormat] h3. [http://lucene.apache.org/solr/guide/faceting.html] (/) [0] [http://doctypepdf/] h3. [http://lucene.apache.org/solr/guide/spatial-search.html] (x) [0] [http://central.maven.org/maven2/org/locationtech/jts/jts-core/1.15.0/] h3. [http://lucene.apache.org/solr/guide/result-clustering.html] (x) [404] [http://search.carrot2.org/stable/search?query=solr&results=100&source=web&view=foamtree] (x) [404] [https://github.com/carrot2/carrot
[jira] [Commented] (LUCENE-9229) Lucene web site broken links
[ https://issues.apache.org/jira/browse/LUCENE-9229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057063#comment-17057063 ] Cassandra Targett commented on LUCENE-9229: --- Updated the list to include all the wiki.apache.org links I fixed a few weeks ago. > Lucene web site broken links > > > Key: LUCENE-9229 > URL: https://issues.apache.org/jira/browse/LUCENE-9229 > Project: Lucene - Core > Issue Type: Bug > Components: general/javadocs, general/website >Reporter: Jan Høydahl >Priority: Major > Labels: newdev > > The new website is live, so I ran a dead-link checker on it to see if > anything is broken. Here is the list of dead links. A bunch of them are from > JavaDoc or from RefGuide, but some are also missing graphics on the site > itself. > Feel free to grab broken links and commit fixes either to lucene-site repo or > lucene-solr repo as you see fit. When a link is fixed, please change (x) into > (/) here so we see progress. Some of the broken links are in legacy changes > html, guess we don't need to fix those. > h2. Website > h3. [http://lucene.apache.org/pylucene/jcc/install.html] > (/) [404] [https://bugs.python.org/setuptools/issue43] > h3. [http://lucene.apache.org/pylucene/features.html] > (/) [404] [https://svn.apache.org/viewcvs.cgi/lucene/pylucene/trunk/test] > h3. [http://lucene.apache.org/solr/resources.html] > (x) [0] [http://hrishikesh.karambelkar.co.in/] > (x) [404] [http://lucenerevolution.org/past-events/] > (x) [404] [http://www.packtpub.com/apache-solr-for-indexing-data/book] > (x) [0] [http://www.inkstall.com/] > h3. [http://lucene.apache.org/pylucene/jcc/features.html] > (/) [0] [https://peak.telecommunity.com/DevCenter/EasyInstall] > h2. Javadoc > h3. [http://lucene.apache.org/solr/api/changes/Changes.html] > (/) [404] [http://wiki.apache.org/solr/FunctionQuery]. > h3. [http://lucene.apache.org/solr/api/solr-test-framework/overview-tree.html] > (x) [404] > [https://junit.org/junit4/javadoc/4.12/org/junit/rules.TestRule.html?is-external=true] > h3. > [http://lucene.apache.org/solr/api/solr-test-framework/org/apache/solr/util/RevertDefaultThreadHandlerRule.html] > (x) [404] > [https://junit.org/junit4/javadoc/4.12/org/junit/runners/model.Statement.html?is-external=true] > h3. > [http://lucene.apache.org/solr/api/solr-test-framework/org/apache/solr/util/SSLTestConfig.html] > (x) [404] > [https://junit.org/junit4/javadoc/4.12/org/junit/internal.AssumptionViolatedException.html?is-external=true] > h3. > [http://lucene.apache.org/solr/api/solr-solrj/org/apache/solr/common/util/ByteArrayUtf8CharSequence.html] > (x) [404] [http://download.java.net/java/jdk9/docs/api/java/util/Arrays.html] > h3. > [http://lucene.apache.org/solr/api/solr-solrj/org/apache/solr/client/solrj/SolrQuery.html] > (x) [404] [https://wiki.apache.org/solr/SimpleFacetParameters] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/BBoxStrategy.html] > (x) [404] > [http://geoportal.svn.sourceforge.net/svnroot/geoportal/Geoportal/trunk/src/com/esri/gpt/catalog/lucene/SpatialClauseAdapter.java] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/search/FastLRUCache.html] > (x) [404] [http://wiki.apache.org/solr/SolrCaching] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/util/hll/HLL.html] > (x) [404] > [http://guava-libraries.googlecode.com/git/guava/src/com/google/common/hash/Murmur3_128HashFunction.java] > (x) [404] > [https://github.com/aggregateknowledge/postgresql-hll/blob/master/README.markdown] > (x) [404] > [https://github.com/aggregateknowledge/postgresql-hll/blob/master/STORAGE.markdown] > h3. [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/] > (x) [404] [http://lucene.apache.org/icons/blank.gif] > (x) [404] [http://lucene.apache.org/icons/text.gif] > (x) [404] [http://lucene.apache.org/icons/folder.gif] > (x) [404] [http://lucene.apache.org/icons/back.gif] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/doc-files/] > (x) [404] [http://lucene.apache.org/icons/image2.gif] > h2. Solr Reference Guide > h3. [http://lucene.apache.org/solr/guide/updating-parts-of-documents.html] > (/) [0] > [https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=blob;f=solr/core/src/test-files/solr/collection1/conf/solrconfig-externalversionconstraint.xml;hb=HEAD] > h3. [http://lucene.apache.org/solr/guide/relevance.html] > (x) [404] > [https://lucidworks.com/blog/2009/09/02/debugging-search-application-relevance-issues/] > h3. [http://lucene.apache.org/solr/guide/tokenizers.html] > (x) [404] [http://accarol.com/contact.htm?from=external&a=10] > h3. [http://lucene.apache.org/solr/guide/language-analysis.html] > (x) [404] [http://www.users.muohio.edu/canf/papers/JASIST2
[jira] [Comment Edited] (LUCENE-9229) Lucene web site broken links
[ https://issues.apache.org/jira/browse/LUCENE-9229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057063#comment-17057063 ] Cassandra Targett edited comment on LUCENE-9229 at 3/11/20, 2:46 PM: - Updated the list to include all the wiki.apache.org links in the Ref Guide I fixed a few weeks ago. was (Author: ctargett): Updated the list to include all the wiki.apache.org links I fixed a few weeks ago. > Lucene web site broken links > > > Key: LUCENE-9229 > URL: https://issues.apache.org/jira/browse/LUCENE-9229 > Project: Lucene - Core > Issue Type: Bug > Components: general/javadocs, general/website >Reporter: Jan Høydahl >Priority: Major > Labels: newdev > > The new website is live, so I ran a dead-link checker on it to see if > anything is broken. Here is the list of dead links. A bunch of them are from > JavaDoc or from RefGuide, but some are also missing graphics on the site > itself. > Feel free to grab broken links and commit fixes either to lucene-site repo or > lucene-solr repo as you see fit. When a link is fixed, please change (x) into > (/) here so we see progress. Some of the broken links are in legacy changes > html, guess we don't need to fix those. > h2. Website > h3. [http://lucene.apache.org/pylucene/jcc/install.html] > (/) [404] [https://bugs.python.org/setuptools/issue43] > h3. [http://lucene.apache.org/pylucene/features.html] > (/) [404] [https://svn.apache.org/viewcvs.cgi/lucene/pylucene/trunk/test] > h3. [http://lucene.apache.org/solr/resources.html] > (x) [0] [http://hrishikesh.karambelkar.co.in/] > (x) [404] [http://lucenerevolution.org/past-events/] > (x) [404] [http://www.packtpub.com/apache-solr-for-indexing-data/book] > (x) [0] [http://www.inkstall.com/] > h3. [http://lucene.apache.org/pylucene/jcc/features.html] > (/) [0] [https://peak.telecommunity.com/DevCenter/EasyInstall] > h2. Javadoc > h3. [http://lucene.apache.org/solr/api/changes/Changes.html] > (/) [404] [http://wiki.apache.org/solr/FunctionQuery]. > h3. [http://lucene.apache.org/solr/api/solr-test-framework/overview-tree.html] > (x) [404] > [https://junit.org/junit4/javadoc/4.12/org/junit/rules.TestRule.html?is-external=true] > h3. > [http://lucene.apache.org/solr/api/solr-test-framework/org/apache/solr/util/RevertDefaultThreadHandlerRule.html] > (x) [404] > [https://junit.org/junit4/javadoc/4.12/org/junit/runners/model.Statement.html?is-external=true] > h3. > [http://lucene.apache.org/solr/api/solr-test-framework/org/apache/solr/util/SSLTestConfig.html] > (x) [404] > [https://junit.org/junit4/javadoc/4.12/org/junit/internal.AssumptionViolatedException.html?is-external=true] > h3. > [http://lucene.apache.org/solr/api/solr-solrj/org/apache/solr/common/util/ByteArrayUtf8CharSequence.html] > (x) [404] [http://download.java.net/java/jdk9/docs/api/java/util/Arrays.html] > h3. > [http://lucene.apache.org/solr/api/solr-solrj/org/apache/solr/client/solrj/SolrQuery.html] > (x) [404] [https://wiki.apache.org/solr/SimpleFacetParameters] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/BBoxStrategy.html] > (x) [404] > [http://geoportal.svn.sourceforge.net/svnroot/geoportal/Geoportal/trunk/src/com/esri/gpt/catalog/lucene/SpatialClauseAdapter.java] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/search/FastLRUCache.html] > (x) [404] [http://wiki.apache.org/solr/SolrCaching] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/util/hll/HLL.html] > (x) [404] > [http://guava-libraries.googlecode.com/git/guava/src/com/google/common/hash/Murmur3_128HashFunction.java] > (x) [404] > [https://github.com/aggregateknowledge/postgresql-hll/blob/master/README.markdown] > (x) [404] > [https://github.com/aggregateknowledge/postgresql-hll/blob/master/STORAGE.markdown] > h3. [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/] > (x) [404] [http://lucene.apache.org/icons/blank.gif] > (x) [404] [http://lucene.apache.org/icons/text.gif] > (x) [404] [http://lucene.apache.org/icons/folder.gif] > (x) [404] [http://lucene.apache.org/icons/back.gif] > h3. > [http://lucene.apache.org/solr/api/solr-core/org/apache/solr/legacy/doc-files/] > (x) [404] [http://lucene.apache.org/icons/image2.gif] > h2. Solr Reference Guide > h3. [http://lucene.apache.org/solr/guide/updating-parts-of-documents.html] > (/) [0] > [https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=blob;f=solr/core/src/test-files/solr/collection1/conf/solrconfig-externalversionconstraint.xml;hb=HEAD] > h3. [http://lucene.apache.org/solr/guide/relevance.html] > (x) [404] > [https://lucidworks.com/blog/2009/09/02/debugging-search-application-relevance-issues/] > h3. [http://lucene.apache.org/solr/guide/tokenizers.html] > (x) [404] [
[jira] [Comment Edited] (SOLR-14314) Solr does not response most of the update request some times
[
https://issues.apache.org/jira/browse/SOLR-14314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057047#comment-17057047
]
Aaron Sun edited comment on SOLR-14314 at 3/11/20, 2:38 PM:
[~ichattopadhyaya] [~erickerickson] Thanks for the quick response and
appreciate for the help!
The slow response state is not always happens, it seems under some heavy load
it start to happen more often, such as client send burst of queries and add
commands at the same time.
After enable more logging, I notice some times the logging just pause some
seconds, it looks like something is blocking(or too busy to process? CPU/IO?)
{noformat}
{noformat}
Here are some examples:
{noformat}
2020-03-11 15:00:18.101 DEBUG (qtp820914198-32) [ x:agglogtrackitem]
o.a.s.u.p.LogUpdateProcessorFactory PRE_UPDATE
commit\{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
\{{params(commit=true),defaults(wt=json)}}
2020-03-11 15:00:29.111 TRACE (qtp820914198-121) [ x:agglogtrackitem]
o.a.s.u.UpdateLog TLOG: added id 2101702210439403924 to
tlog\{file=/ardome/solr/agglogtrackitem/data/tlog/tlog.0040378
refcount=1} LogPtr(62560436) map=27492440
2020-03-11 15:02:01.019 DEBUG (qtp820914198-101) [ x:agglogtrackitem]
o.a.s.u.p.LogUpdateProcessorFactory PRE_UPDATE
commit\{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
\{{params(commit=true),defaults(wt=json)}}
2020-03-11 15:02:06.583 TRACE (qtp820914198-28) [ x:agglogtrackitem]
o.a.s.u.UpdateLog TLOG: added id 2101802040421290224 to
tlog\{file=/ardome/solr/agglogtrackitem/data/tlog/tlog.0040552
refcount=1} LogPtr(5925467) map=2138772739
2020-03-11 15:02:06.584 DEBUG (qtp820914198-28) [ x:agglogtrackitem]
o.a.s.u.p.LogUpdateProcessorFactory PRE_UPDATE add\{,id=2101802040421395124}
\{{params(commit=true),defaults(wt=json)}}
2020-03-11 15:02:42.897 TRACE (qtp820914198-128) [ x:agglogtrackitem]
o.a.s.u.UpdateLog TLOG: added id 2101702240520633224 to
tlog\{file=/ardome/solr/agglogtrackitem/data/tlog/tlog.0040606
refcount=1} LogPtr(82150345) map=522043138
2020-03-11 15:02:42.897 DEBUG (qtp820914198-128) [ x:agglogtrackitem]
o.a.s.u.p.LogUpdateProcessorFactory PRE_UPDATE
commit\{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
\{{params(commit=true),defaults(wt=json)}}
2020-03-11 15:03:10.117 TRACE (qtp820914198-124) [ x:agglogtrackitem]
o.a.s.u.UpdateLog TLOG: added id 2101702170101660124 to
tlog\{file=/ardome/solr/agglogtrackitem/data/tlog/tlog.0040606
refcount=1} LogPtr(82154733) map=522043138
{noformat}
Client side start to timeout around this time, then time gap in the log
happens more frequently. while the client was sending "add" documents command
continuously, I guess solr shouldn't pause the processing, isn't it?
{noformat}
2020-03-11 15:07:56.699 DEBUG (qtp820914198-1287) [ x:agglogtrackitem]
o.a.s.u.p.LogUpdateProcessorFactory PRE_UPDATE
commit\{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
{{params(commit=true),defaults(wt=
json)}}
2020-03-11 15:08:09.886 TRACE (qtp820914198-1409) [ x:agglogtrackitem]
o.a.s.u.UpdateLog TLOG: added id 2101703060206960524 to
tlog\{file=/ardome/solr/agglogtrackitem/data/tlog/tlog.0040713
refcount=1} LogPtr(50692808) map=35667164
{noformat}
Running solr with this command
{noformat}
java -verbose:gc -XX:+PrintHeapAtGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps
-XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution
-XX:+PrintGCApplicationStoppedTime -Xloggc:/var/ardendo/log/solr_gc.log
-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=9 -XX:GCLogFileSize=20M
-Xmx200G -DSTOP.PORT=8078 -DSTOP.KEY=ardsolrstop -Dsolr.solr.home=/ardome/solr
-Djetty.port=8983 -Dsolr.log.dir=/var/ardendo/log -jar start.jar --module=http
{noformat}
Here is the solr log and GC log, now sure how to check the GC pause you
mentioned above.
[^solrlog.tar.gz]
Any guidance to enable more log or some way forward would be very useful.
Thanks for the help!
was (Author: aaronsuns):
[~ichattopadhyaya] [~erickerickson] Thanks for the quick response and
appreciate for the help!
The slow response state is not always happens, it seems under some heavy load
it start to happen more often, such as client send burst of queries and add
commands at the same time.
After enable more logging, I notice some times the logging just pause some
seconds, it looks like something is blocking(or too busy to process? CPU/IO?)
{noformat}
{noformat}
Here are some examples:
{noformat}
2020-03-11 15:00:18.101 DEBUG (qtp820914198-32) [ x:agglogtrackitem]
o.a.s.u.p.LogUpdateProcessorFactory PRE_UPDATE
commit\{,optimize=fa
[jira] [Reopened] (SOLR-14314) Solr does not response most of the update request some times
[
https://issues.apache.org/jira/browse/SOLR-14314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Sun reopened SOLR-14314:
--
Adding more log.
> Solr does not response most of the update request some times
>
>
> Key: SOLR-14314
> URL: https://issues.apache.org/jira/browse/SOLR-14314
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Aaron Sun
>Priority: Critical
> Attachments: jstack_bad_state.log, solrlog.tar.gz
>
>
> Solr version:
> {noformat}
> solr-spec
> 8.4.1
> solr-impl
> 8.4.1 832bf13dd9187095831caf69783179d41059d013 - ishan - 2020-01-10 13:40:28
> lucene-spec
> 8.4.1
> lucene-impl
> 8.4.1 832bf13dd9187095831caf69783179d41059d013 - ishan - 2020-01-10 13:35:00
> {noformat}
>
> Java process:
> {noformat}
> java -Xms100G -Xmx200G -DSTOP.PORT=8078 -DSTOP.KEY=ardsolrstop
> -Dsolr.solr.home=/ardome/solr -Djetty.port=8983
> -Dsolr.log.dir=/var/ardendo/log -jar start.jar --module=http
> {noformat}
> Run on a powerful server with 32 cores, 265GB RAM.
> The problem is that time to time it start to get very slow to update solr
> documents, for example time out after 30 minutes.
> document size is around 20k~50K each, each http request send to /update is
> around 4MB~10MB.
> /update request is done by multi processes.
> Some of the update get response, but the differences between "QTime" and
> http response time is big, one example, qtime = 66s, http response time is
> 2304s.
> According to jstack for the thread state, lots of BLOCKED state.
> thread dump log is attached.
> Any hint would be appreciate, thanks!
>
>
>
>
>
>
>
>
>
>
>
>
>
--
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-14314) Solr does not response most of the update request some times
[
https://issues.apache.org/jira/browse/SOLR-14314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057047#comment-17057047
]
Aaron Sun commented on SOLR-14314:
--
[~ichattopadhyaya] [~erickerickson] Thanks for the quick response and
appreciate for the help!
The slow response state is not always happens, it seems under some heavy load
it start to happen more often, such as client send burst of queries and add
commands at the same time.
After enable more logging, I notice some times the logging just pause some
seconds, it looks like something is blocking(or too busy to process? CPU/IO?)
{noformat}
{noformat}
Here are some examples:
{noformat}
2020-03-11 15:00:18.101 DEBUG (qtp820914198-32) [ x:agglogtrackitem]
o.a.s.u.p.LogUpdateProcessorFactory PRE_UPDATE
commit\{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
\{{params(commit=true),defaults(wt=json)}}
2020-03-11 15:00:29.111 TRACE (qtp820914198-121) [ x:agglogtrackitem]
o.a.s.u.UpdateLog TLOG: added id 2101702210439403924 to
tlog\{file=/ardome/solr/agglogtrackitem/data/tlog/tlog.0040378
refcount=1} LogPtr(62560436) map=27492440
2020-03-11 15:02:01.019 DEBUG (qtp820914198-101) [ x:agglogtrackitem]
o.a.s.u.p.LogUpdateProcessorFactory PRE_UPDATE
commit\{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
\{{params(commit=true),defaults(wt=json)}}
2020-03-11 15:02:06.583 TRACE (qtp820914198-28) [ x:agglogtrackitem]
o.a.s.u.UpdateLog TLOG: added id 2101802040421290224 to
tlog\{file=/ardome/solr/agglogtrackitem/data/tlog/tlog.0040552
refcount=1} LogPtr(5925467) map=2138772739
2020-03-11 15:02:06.584 DEBUG (qtp820914198-28) [ x:agglogtrackitem]
o.a.s.u.p.LogUpdateProcessorFactory PRE_UPDATE add\{,id=2101802040421395124}
\{{params(commit=true),defaults(wt=json)}}
2020-03-11 15:02:42.897 TRACE (qtp820914198-128) [ x:agglogtrackitem]
o.a.s.u.UpdateLog TLOG: added id 2101702240520633224 to
tlog\{file=/ardome/solr/agglogtrackitem/data/tlog/tlog.0040606
refcount=1} LogPtr(82150345) map=522043138
2020-03-11 15:02:42.897 DEBUG (qtp820914198-128) [ x:agglogtrackitem]
o.a.s.u.p.LogUpdateProcessorFactory PRE_UPDATE
commit\{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
\{{params(commit=true),defaults(wt=json)}}
2020-03-11 15:03:10.117 TRACE (qtp820914198-124) [ x:agglogtrackitem]
o.a.s.u.UpdateLog TLOG: added id 2101702170101660124 to
tlog\{file=/ardome/solr/agglogtrackitem/data/tlog/tlog.0040606
refcount=1} LogPtr(82154733) map=522043138
{noformat}
Client side start to timeout around this time, then time gap happens more
frequently.
{noformat}
2020-03-11 15:07:56.699 DEBUG (qtp820914198-1287) [ x:agglogtrackitem]
o.a.s.u.p.LogUpdateProcessorFactory PRE_UPDATE
commit\{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
{{params(commit=true),defaults(wt=
json)}}
2020-03-11 15:08:09.886 TRACE (qtp820914198-1409) [ x:agglogtrackitem]
o.a.s.u.UpdateLog TLOG: added id 2101703060206960524 to
tlog\{file=/ardome/solr/agglogtrackitem/data/tlog/tlog.0040713
refcount=1} LogPtr(50692808) map=35667164
{noformat}
Running solr with this command
{noformat}
java -verbose:gc -XX:+PrintHeapAtGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps
-XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution
-XX:+PrintGCApplicationStoppedTime -Xloggc:/var/ardendo/log/solr_gc.log
-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=9 -XX:GCLogFileSize=20M
-Xmx200G -DSTOP.PORT=8078 -DSTOP.KEY=ardsolrstop -Dsolr.solr.home=/ardome/solr
-Djetty.port=8983 -Dsolr.log.dir=/var/ardendo/log -jar start.jar --module=http
{noformat}
Here is the solr log and GC log, now sure how to check the GC pause you
mentioned above.
[^solrlog.tar.gz]
Any guidance to enable more log or some way forward would be very useful.
Thanks for the help!
> Solr does not response most of the update request some times
>
>
> Key: SOLR-14314
> URL: https://issues.apache.org/jira/browse/SOLR-14314
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Aaron Sun
>Priority: Critical
> Attachments: jstack_bad_state.log, solrlog.tar.gz
>
>
> Solr version:
> {noformat}
> solr-spec
> 8.4.1
> solr-impl
> 8.4.1 832bf13dd9187095831caf69783179d41059d013 - ishan - 2020-01-10 13:40:28
> lucene-spec
> 8.4.1
> lucene-impl
> 8.4.1 832bf13dd9187095831caf69783179d41059d013 - ishan - 2020-01-10 13:35:00
> {noformat}
>
> Java process:
> {noformat}
> java -Xms100G -Xmx200G -DSTOP.PORT=8078 -DSTOP.
[jira] [Updated] (SOLR-14314) Solr does not response most of the update request some times
[
https://issues.apache.org/jira/browse/SOLR-14314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Sun updated SOLR-14314:
-
Attachment: solrlog.tar.gz
> Solr does not response most of the update request some times
>
>
> Key: SOLR-14314
> URL: https://issues.apache.org/jira/browse/SOLR-14314
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Aaron Sun
>Priority: Critical
> Attachments: jstack_bad_state.log, solrlog.tar.gz
>
>
> Solr version:
> {noformat}
> solr-spec
> 8.4.1
> solr-impl
> 8.4.1 832bf13dd9187095831caf69783179d41059d013 - ishan - 2020-01-10 13:40:28
> lucene-spec
> 8.4.1
> lucene-impl
> 8.4.1 832bf13dd9187095831caf69783179d41059d013 - ishan - 2020-01-10 13:35:00
> {noformat}
>
> Java process:
> {noformat}
> java -Xms100G -Xmx200G -DSTOP.PORT=8078 -DSTOP.KEY=ardsolrstop
> -Dsolr.solr.home=/ardome/solr -Djetty.port=8983
> -Dsolr.log.dir=/var/ardendo/log -jar start.jar --module=http
> {noformat}
> Run on a powerful server with 32 cores, 265GB RAM.
> The problem is that time to time it start to get very slow to update solr
> documents, for example time out after 30 minutes.
> document size is around 20k~50K each, each http request send to /update is
> around 4MB~10MB.
> /update request is done by multi processes.
> Some of the update get response, but the differences between "QTime" and
> http response time is big, one example, qtime = 66s, http response time is
> 2304s.
> According to jstack for the thread state, lots of BLOCKED state.
> thread dump log is attached.
> Any hint would be appreciate, thanks!
>
>
>
>
>
>
>
>
>
>
>
>
>
--
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] Lyle-Wong opened a new pull request #1342: SOLR-14317: HttpClusterStateProvider throws exception when only one node down
Lyle-Wong opened a new pull request #1342: SOLR-14317: HttpClusterStateProvider throws exception when only one node down URL: https://github.com/apache/lucene-solr/pull/1342 # Description Catch SolrServerException as well since SolrServerException may throw from fetchLiveNodes(initialClient) # Solution Catch SolrServerException # Tests Provide solrUrls list with two nodes, and shutdown the first node in the list, CloudSolrClient can created successful. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `master` branch. - [x] I have run `ant precommit` and the appropriate test suite. - [X] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mocobeta commented on a change in pull request #1304: LUCENE-9242: generate javadocs by calling Ant javadoc task
mocobeta commented on a change in pull request #1304: LUCENE-9242: generate
javadocs by calling Ant javadoc task
URL: https://github.com/apache/lucene-solr/pull/1304#discussion_r391003594
##
File path: gradle/validation/missing-docs-check.gradle
##
@@ -34,8 +34,9 @@ allprojects {
':lucene:spatial3d',
]
-task checkMissingDocsDefault(type: CheckMissingDocsTask, dependsOn:
'javadoc') {
- dirs += [ project.javadoc.destinationDir ]
+task checkMissingDocsDefault(type: CheckMissingDocsTask, dependsOn:
'renderJavadoc') {
+ //dirs += [ project.javadoc.destinationDir ]
Review comment:
Yes, it was removed. Thank you.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
