[jira] [Resolved] (LUCENE-6537) Make NearSpansOrdered use lazy iteration
[ https://issues.apache.org/jira/browse/LUCENE-6537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward resolved LUCENE-6537. --- Resolution: Fixed Fix Version/s: 5.3 Assignee: Alan Woodward Turned out to be simpler to do this separately. Make NearSpansOrdered use lazy iteration Key: LUCENE-6537 URL: https://issues.apache.org/jira/browse/LUCENE-6537 Project: Lucene - Core Issue Type: Improvement Reporter: Alan Woodward Assignee: Alan Woodward Priority: Minor Fix For: 5.3 Attachments: LUCENE-6537.patch, LUCENE-6537.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6566) Handle crosses dateline cases in BKPointInPolygonQuery
Michael McCandless created LUCENE-6566: -- Summary: Handle crosses dateline cases in BKPointInPolygonQuery Key: LUCENE-6566 URL: https://issues.apache.org/jira/browse/LUCENE-6566 Project: Lucene - Core Issue Type: Bug Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 5.3, Trunk Just like LUCENE-6560, but we should also handle for the polygon case, which seems harder ... -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7344) Allow Jetty thread pool limits while still avoiding distributed deadlock.
[ https://issues.apache.org/jira/browse/SOLR-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14585781#comment-14585781 ] Ramkumar Aiyengar commented on SOLR-7344: - Yonik, I am curious as to why Streaming API has to have infinite recursion? Is it a necessity or a design choice to do this instead of having one federator issuing all requests? Having two levels (external, internal) is enough of a headache trying to come up with usage patterns and knowing what the optimal amount of parallelism is. I share Mark's concern that this patch or not, having the possibility of one query eating up all threads is scary.. Allow Jetty thread pool limits while still avoiding distributed deadlock. - Key: SOLR-7344 URL: https://issues.apache.org/jira/browse/SOLR-7344 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Attachments: SOLR-7344.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6539) Add DocValuesNumbersQuery, like DocValuesTermsQuery but works only with long values
[ https://issues.apache.org/jira/browse/LUCENE-6539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14585779#comment-14585779 ] ASF subversion and git services commented on LUCENE-6539: - Commit 1685540 from [~mikemccand] in branch 'dev/trunk' [ https://svn.apache.org/r1685540 ] LUCENE-6539: Add DocValuesNumbersQuery Add DocValuesNumbersQuery, like DocValuesTermsQuery but works only with long values --- Key: LUCENE-6539 URL: https://issues.apache.org/jira/browse/LUCENE-6539 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 5.3, Trunk Attachments: LUCENE-6539.patch, LUCENE-6539.patch This query accepts any document where any of the provided set of longs was indexed into the specified field as a numeric DV field (NumericDocValuesField or SortedNumericDocValuesField). You can use it instead of DocValuesTermsQuery when you have field values that can be represented as longs. Like DocValuesTermsQuery, this is slowish in general, since it doesn't use an inverted data structure, but in certain cases (many terms/numbers and fewish matching hits) it should be faster than using TermsQuery because it's done as a post filter when other (faster) query clauses are MUST'd with it. In such cases it should also be faster than DocValuesTermsQuery since it skips having to resolve terms - ords. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5886) Store the response in zk for async calls so that it can be returned by REQUESTSTATUS API
[ https://issues.apache.org/jira/browse/SOLR-5886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14585656#comment-14585656 ] Noble Paul commented on SOLR-5886: -- How many responses are being stored in ZK? Store the response in zk for async calls so that it can be returned by REQUESTSTATUS API Key: SOLR-5886 URL: https://issues.apache.org/jira/browse/SOLR-5886 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Anshum Gupta Assignee: Anshum Gupta Attachments: SOLR-5886.patch, SOLR-5886.patch, SOLR-5986-git.patch As of now, only the state of a pre-submitted tasks is returned in the response to the REQUESTSTATUS Collections API call. Pass more information, specially in case of a call erroring out. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6544) Geo3d cleanup: Regularize path and polygon construction, plus consider adding ellipsoid surface distance method
[ https://issues.apache.org/jira/browse/LUCENE-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14585812#comment-14585812 ] Karl Wright commented on LUCENE-6544: - [~dsmiley]: I'm done with this now; anytime you are ready... Geo3d cleanup: Regularize path and polygon construction, plus consider adding ellipsoid surface distance method --- Key: LUCENE-6544 URL: https://issues.apache.org/jira/browse/LUCENE-6544 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: Karl Wright Attachments: LUCENE-6544.patch Geo3d's way of constructing polygons and paths differs in that in one case you construct points and the other you feed lat/lon values directly to the builder. Probably both should be supported for both kinds of entity. Also it may be useful to have an accurate point-point ellipsoidal distance function. This is expensive and would be an addition to the arc distance we currently compute. It would probably be called surface distance. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7668) Port-base rule for shard placement causes NPE
[ https://issues.apache.org/jira/browse/SOLR-7668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14585822#comment-14585822 ] ASF subversion and git services commented on SOLR-7668: --- Commit 1685560 from [~noble.paul] in branch 'dev/trunk' [ https://svn.apache.org/r1685560 ] SOLR-7668: Add 'port' tag support in replica placement rules Port-base rule for shard placement causes NPE - Key: SOLR-7668 URL: https://issues.apache.org/jira/browse/SOLR-7668 Project: Solr Issue Type: Bug Affects Versions: 5.2 Reporter: Adam McElwee Assignee: Noble Paul Priority: Minor Attachments: SOLR-7668.patch, SOLR-7668.patch I was setting up some rule-based collections, and I hit an NPE whenever I try to include a port-based rule. It looks like the implementation was started, but not completed for ports. Patch coming in just a moment. I included a test, and I have no problems getting the test to pass when run by itself. However, when I run it w/ the other tests in RulesTest, it fails because of some ZK errors, but I often have those issues when running any of the distrib tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6560) Handle crosses dateline cases in BKDPointInBBoxQuery
[ https://issues.apache.org/jira/browse/LUCENE-6560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14585746#comment-14585746 ] ASF subversion and git services commented on LUCENE-6560: - Commit 1685527 from [~mikemccand] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1685527 ] LUCENE-6560: BKDPointInBBOxQuery now handles dateline crossing correctly Handle crosses dateline cases in BKDPointInBBoxQuery -- Key: LUCENE-6560 URL: https://issues.apache.org/jira/browse/LUCENE-6560 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 5.3, Trunk Attachments: LUCENE-6560.patch Just like LUCENE-6547 but for BKD bbox queries ... -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6560) Handle crosses dateline cases in BKDPointInBBoxQuery
[ https://issues.apache.org/jira/browse/LUCENE-6560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-6560. Resolution: Fixed I fixed the bbox query; I'll open a new issue for polygons... Handle crosses dateline cases in BKDPointInBBoxQuery -- Key: LUCENE-6560 URL: https://issues.apache.org/jira/browse/LUCENE-6560 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 5.3, Trunk Attachments: LUCENE-6560.patch Just like LUCENE-6547 but for BKD bbox queries ... -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6560) Handle crosses dateline cases in BKDPointInBBoxQuery
[ https://issues.apache.org/jira/browse/LUCENE-6560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14585745#comment-14585745 ] ASF subversion and git services commented on LUCENE-6560: - Commit 1685526 from [~mikemccand] in branch 'dev/trunk' [ https://svn.apache.org/r1685526 ] LUCENE-6560: BKDPointInBBOxQuery now handles dateline crossing correctly Handle crosses dateline cases in BKDPointInBBoxQuery -- Key: LUCENE-6560 URL: https://issues.apache.org/jira/browse/LUCENE-6560 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 5.3, Trunk Attachments: LUCENE-6560.patch Just like LUCENE-6547 but for BKD bbox queries ... -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6564) Normalize date format for IW in unit tests
[
https://issues.apache.org/jira/browse/LUCENE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14585810#comment-14585810
]
Uwe Schindler commented on LUCENE-6564:
---
There is also another possibility to get milliseconds without a date format:
[http://docs.oracle.com/javase/7/docs/api/java/nio/file/attribute/FileTime.html#toString()]:
{code:java}
FileTime.fromMillies(...).toString()
{code}
(this is new since Java 7 and somehow misuses the FileTime API, but it might
be useful here. It also uses UTC and uses the generic ISO8601 format!
The other possibility is using a ThreadLocal:
{code:java}
static final ThreadLocalDateFormat FORMAT = ThreadLocal.withInitial(() - new
SimpleDateFormat(..., Locale, Timezone));
{code}
Normalize date format for IW in unit tests
--
Key: LUCENE-6564
URL: https://issues.apache.org/jira/browse/LUCENE-6564
Project: Lucene - Core
Issue Type: Improvement
Components: general/test
Reporter: Ramkumar Aiyengar
Assignee: Ramkumar Aiyengar
Priority: Minor
Fix For: 5.3
Attachments: LUCENE-6564.patch, LUCENE-6564.patch
Noticed while debugging some IW output in an unit test that milliseconds were
not output in the date, changed this to reuse the date format used by
{{PrintStreamInfoStream}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5886) Store the response in zk for async calls so that it can be returned by REQUESTSTATUS API
[ https://issues.apache.org/jira/browse/SOLR-5886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-5886: --- Attachment: SOLR-5986-git.patch Updated patch but without the tests. Just running the tests, will upload the patch with tests in a bit. Store the response in zk for async calls so that it can be returned by REQUESTSTATUS API Key: SOLR-5886 URL: https://issues.apache.org/jira/browse/SOLR-5886 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Anshum Gupta Assignee: Anshum Gupta Attachments: SOLR-5886.patch, SOLR-5886.patch, SOLR-5986-git.patch As of now, only the state of a pre-submitted tasks is returned in the response to the REQUESTSTATUS Collections API call. Pass more information, specially in case of a call erroring out. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Release notes for Lucene/Solr 5.2.1
Thanks Shalin! Looks good to me. I've removed a few auto-created links that were created due to the CapitalizedWords from the Solr notes. On Sun, Jun 14, 2015 at 11:29 PM, Shalin Shekhar Mangar shalinman...@gmail.com wrote: A draft for the Lucene and Solr 5.2.1 release notes are available at the following URLs - please feel free to improve. Lucene: https://wiki.apache.org/lucene-java/ReleaseNote521 Solr: http://wiki.apache.org/solr/ReleaseNote521 -- Regards, Shalin Shekhar Mangar. -- Anshum Gupta
[jira] [Commented] (SOLR-5886) Store the response in zk for async calls so that it can be returned by REQUESTSTATUS API
[ https://issues.apache.org/jira/browse/SOLR-5886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14585665#comment-14585665 ] Anshum Gupta commented on SOLR-5886: Right now, there's no limit to that but users need to explicitly clean out the stored responses. Having a configurable limit would be a good idea and we could open a separate issue for that. Store the response in zk for async calls so that it can be returned by REQUESTSTATUS API Key: SOLR-5886 URL: https://issues.apache.org/jira/browse/SOLR-5886 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Anshum Gupta Assignee: Anshum Gupta Attachments: SOLR-5886.patch, SOLR-5886.patch, SOLR-5986-git.patch As of now, only the state of a pre-submitted tasks is returned in the response to the REQUESTSTATUS Collections API call. Pass more information, specially in case of a call erroring out. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6539) Add DocValuesNumbersQuery, like DocValuesTermsQuery but works only with long values
[ https://issues.apache.org/jira/browse/LUCENE-6539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14585710#comment-14585710 ] Adrien Grand commented on LUCENE-6539: -- +1 Add DocValuesNumbersQuery, like DocValuesTermsQuery but works only with long values --- Key: LUCENE-6539 URL: https://issues.apache.org/jira/browse/LUCENE-6539 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 5.3, Trunk Attachments: LUCENE-6539.patch, LUCENE-6539.patch This query accepts any document where any of the provided set of longs was indexed into the specified field as a numeric DV field (NumericDocValuesField or SortedNumericDocValuesField). You can use it instead of DocValuesTermsQuery when you have field values that can be represented as longs. Like DocValuesTermsQuery, this is slowish in general, since it doesn't use an inverted data structure, but in certain cases (many terms/numbers and fewish matching hits) it should be faster than using TermsQuery because it's done as a post filter when other (faster) query clauses are MUST'd with it. In such cases it should also be faster than DocValuesTermsQuery since it skips having to resolve terms - ords. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6466) Move SpanQuery.getSpans() to SpanWeight
[ https://issues.apache.org/jira/browse/LUCENE-6466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward resolved LUCENE-6466. --- Resolution: Fixed Move SpanQuery.getSpans() to SpanWeight --- Key: LUCENE-6466 URL: https://issues.apache.org/jira/browse/LUCENE-6466 Project: Lucene - Core Issue Type: Improvement Reporter: Alan Woodward Assignee: Alan Woodward Priority: Minor Fix For: 5.3, Trunk Attachments: LUCENE-6466-2.patch, LUCENE-6466-2.patch, LUCENE-6466-2.patch, LUCENE-6466-branch5x.patch, LUCENE-6466.patch, LUCENE-6466.patch, LUCENE-6466.patch, LUCENE-6466.patch, LUCENE-6466.patch SpanQuery.getSpans() should only be called on rewritten queries, so it seems to make more sense to have this being called from SpanWeight -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6466) Move SpanQuery.getSpans() to SpanWeight
[ https://issues.apache.org/jira/browse/LUCENE-6466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14585774#comment-14585774 ] ASF subversion and git services commented on LUCENE-6466: - Commit 1685538 from [~romseygeek] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1685538 ] LUCENE-6466: Move SpanQuery.getSpans() and .extractWeight() to SpanWeight Move SpanQuery.getSpans() to SpanWeight --- Key: LUCENE-6466 URL: https://issues.apache.org/jira/browse/LUCENE-6466 Project: Lucene - Core Issue Type: Improvement Reporter: Alan Woodward Assignee: Alan Woodward Priority: Minor Fix For: 5.3, Trunk Attachments: LUCENE-6466-2.patch, LUCENE-6466-2.patch, LUCENE-6466-2.patch, LUCENE-6466-branch5x.patch, LUCENE-6466.patch, LUCENE-6466.patch, LUCENE-6466.patch, LUCENE-6466.patch, LUCENE-6466.patch SpanQuery.getSpans() should only be called on rewritten queries, so it seems to make more sense to have this being called from SpanWeight -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6544) Geo3d cleanup: Regularize path and polygon construction, plus consider adding ellipsoid surface distance method
[ https://issues.apache.org/jira/browse/LUCENE-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated LUCENE-6544: Attachment: (was: LUCENE-6544.patch) Geo3d cleanup: Regularize path and polygon construction, plus consider adding ellipsoid surface distance method --- Key: LUCENE-6544 URL: https://issues.apache.org/jira/browse/LUCENE-6544 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: Karl Wright Attachments: LUCENE-6544.patch Geo3d's way of constructing polygons and paths differs in that in one case you construct points and the other you feed lat/lon values directly to the builder. Probably both should be supported for both kinds of entity. Also it may be useful to have an accurate point-point ellipsoidal distance function. This is expensive and would be an addition to the arc distance we currently compute. It would probably be called surface distance. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6544) Geo3d cleanup: Regularize path and polygon construction, plus consider adding ellipsoid surface distance method
[ https://issues.apache.org/jira/browse/LUCENE-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated LUCENE-6544: Attachment: LUCENE-6544.patch New patch including better math for circles. Circles are now always centered on their center point, no matter how significantly ellipsoid the planet is. Geo3d cleanup: Regularize path and polygon construction, plus consider adding ellipsoid surface distance method --- Key: LUCENE-6544 URL: https://issues.apache.org/jira/browse/LUCENE-6544 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: Karl Wright Attachments: LUCENE-6544.patch, LUCENE-6544.patch Geo3d's way of constructing polygons and paths differs in that in one case you construct points and the other you feed lat/lon values directly to the builder. Probably both should be supported for both kinds of entity. Also it may be useful to have an accurate point-point ellipsoidal distance function. This is expensive and would be an addition to the arc distance we currently compute. It would probably be called surface distance. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6466) Move SpanQuery.getSpans() to SpanWeight
[ https://issues.apache.org/jira/browse/LUCENE-6466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated LUCENE-6466: -- Attachment: LUCENE-6466-branch5x.patch Patch for branch 5x (before LUCENE-6371 is added) Move SpanQuery.getSpans() to SpanWeight --- Key: LUCENE-6466 URL: https://issues.apache.org/jira/browse/LUCENE-6466 Project: Lucene - Core Issue Type: Improvement Reporter: Alan Woodward Assignee: Alan Woodward Priority: Minor Fix For: 5.3, Trunk Attachments: LUCENE-6466-2.patch, LUCENE-6466-2.patch, LUCENE-6466-2.patch, LUCENE-6466-branch5x.patch, LUCENE-6466.patch, LUCENE-6466.patch, LUCENE-6466.patch, LUCENE-6466.patch, LUCENE-6466.patch SpanQuery.getSpans() should only be called on rewritten queries, so it seems to make more sense to have this being called from SpanWeight -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7596) Add possibility to specify port of embedded Zookeeper
[ https://issues.apache.org/jira/browse/SOLR-7596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14585764#comment-14585764 ] Arcadius Ahouansou commented on SOLR-7596: -- Hi [~hossman]. We are running external ZK quorum. This ticket is just for automated tests on Jenkins on random port. Thanks. Add possibility to specify port of embedded Zookeeper - Key: SOLR-7596 URL: https://issues.apache.org/jira/browse/SOLR-7596 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 5.1 Reporter: Arcadius Ahouansou Priority: Minor Currently, the startup script bin/solr accepts only '-p' for the solr port and there is no way to pass the embedded zookeeper port as a command line param (when using '-c' without '-z'). This ticket is to allow for '-P' or something similar that would be used as the port of the embedded ZK instead of the default solrPort+1000 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6565) Is it ok for IndexWriter.prepareCommit to be an NRT-visible change?
Adrien Grand created LUCENE-6565:
Summary: Is it ok for IndexWriter.prepareCommit to be an
NRT-visible change?
Key: LUCENE-6565
URL: https://issues.apache.org/jira/browse/LUCENE-6565
Project: Lucene - Core
Issue Type: Task
Reporter: Adrien Grand
Assignee: Michael McCandless
Because of LUCENE-6523, IndexWriter.prepareCommit is now an NRT-visible change.
For instance the following test would fail:
{code}
Directory dir = newDirectory();
IndexWriter w = new IndexWriter(dir, new IndexWriterConfig(new
MockAnalyzer(random(;
w.addDocument(new Document());
DirectoryReader reader = DirectoryReader.open(w, true);
assertNull(DirectoryReader.openIfChanged(reader)); // ok
w.prepareCommit();
assertNull(DirectoryReader.openIfChanged(reader)); // fails
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6564) Normalize date format for IW in unit tests
[
https://issues.apache.org/jira/browse/LUCENE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-6564:
---
Attachment: LUCENE-6564.patch
How about this? I just do elapsed time since the info stream was created,
using System.nanoTime, and I cutover to String.format.
Normalize date format for IW in unit tests
--
Key: LUCENE-6564
URL: https://issues.apache.org/jira/browse/LUCENE-6564
Project: Lucene - Core
Issue Type: Improvement
Components: general/test
Reporter: Ramkumar Aiyengar
Assignee: Ramkumar Aiyengar
Priority: Minor
Fix For: 5.3
Attachments: LUCENE-6564.patch, LUCENE-6564.patch
Noticed while debugging some IW output in an unit test that milliseconds were
not output in the date, changed this to reuse the date format used by
{{PrintStreamInfoStream}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-5.2 - Build # 19 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.2/19/
No tests ran.
Build Log:
[...truncated 52575 lines...]
prepare-release-no-sign:
[mkdir] Created dir:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.2/lucene/build/smokeTestRelease/dist
[copy] Copying 446 files to
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.2/lucene/build/smokeTestRelease/dist/lucene
[copy] Copying 245 files to
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.2/lucene/build/smokeTestRelease/dist/solr
[smoker] Java 1.7
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
[smoker] NOTE: output encoding is UTF-8
[smoker]
[smoker] Load release URL
file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.2/lucene/build/smokeTestRelease/dist/...
[smoker]
[smoker] Test Lucene...
[smoker] test basics...
[smoker] get KEYS
[smoker] 0.1 MB in 0.01 sec (13.0 MB/sec)
[smoker] check changes HTML...
[smoker] download lucene-5.2.1-src.tgz...
[smoker] 28.3 MB in 0.04 sec (783.8 MB/sec)
[smoker] verify md5/sha1 digests
[smoker] download lucene-5.2.1.tgz...
[smoker] 65.2 MB in 0.08 sec (828.7 MB/sec)
[smoker] verify md5/sha1 digests
[smoker] download lucene-5.2.1.zip...
[smoker] 75.1 MB in 0.09 sec (823.0 MB/sec)
[smoker] verify md5/sha1 digests
[smoker] unpack lucene-5.2.1.tgz...
[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
[smoker] test demo with 1.7...
[smoker] got 5885 hits for query lucene
[smoker] checkindex with 1.7...
[smoker] check Lucene's javadoc JAR
[smoker] unpack lucene-5.2.1.zip...
[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
[smoker] test demo with 1.7...
[smoker] got 5885 hits for query lucene
[smoker] checkindex with 1.7...
[smoker] check Lucene's javadoc JAR
[smoker] unpack lucene-5.2.1-src.tgz...
[smoker] make sure no JARs/WARs in src dist...
[smoker] run ant validate
[smoker] run tests w/ Java 7 and testArgs='-Dtests.slow=false'...
[smoker] test demo with 1.7...
[smoker] got 209 hits for query lucene
[smoker] checkindex with 1.7...
[smoker] generate javadocs w/ Java 7...
[smoker]
[smoker] Crawl/parse...
[smoker]
[smoker] Verify...
[smoker] confirm all releases have coverage in TestBackwardsCompatibility
[smoker] find all past Lucene releases...
[smoker] run TestBackwardsCompatibility..
[smoker] Releases that don't seem to be tested:
[smoker] 5.2.1
[smoker] Traceback (most recent call last):
[smoker] File
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.2/dev-tools/scripts/smokeTestRelease.py,
line 1535, in module
[smoker] main()
[smoker] File
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.2/dev-tools/scripts/smokeTestRelease.py,
line 1480, in main
[smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir,
c.is_signed, ' '.join(c.test_args))
[smoker] File
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.2/dev-tools/scripts/smokeTestRelease.py,
line 1518, in smokeTest
[smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' %
version, svnRevision, version, testArgs, baseURL)
[smoker] File
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.2/dev-tools/scripts/smokeTestRelease.py,
line 628, in unpackAndVerify
[smoker] verifyUnpacked(java, project, artifact, unpackPath,
svnRevision, version, testArgs, tmpDir, baseURL)
[smoker] File
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.2/dev-tools/scripts/smokeTestRelease.py,
line 809, in verifyUnpacked
[smoker] confirmAllReleasesAreTestedForBackCompat(unpackPath)
[smoker] File
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.2/dev-tools/scripts/smokeTestRelease.py,
line 1473, in confirmAllReleasesAreTestedForBackCompat
[smoker] raise RuntimeError('some releases are not tested by
TestBackwardsCompatibility?')
[smoker] RuntimeError: some releases are not tested by
TestBackwardsCompatibility?
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.2/build.xml:421:
exec returned: 1
Total time: 39 minutes 15 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure
Sending email for trigger: Failure
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6537) Make NearSpansOrdered use lazy iteration
[ https://issues.apache.org/jira/browse/LUCENE-6537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14585667#comment-14585667 ] ASF subversion and git services commented on LUCENE-6537: - Commit 1685517 from [~romseygeek] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1685517 ] LUCENE-6537: NearSpansOrdered should be lazy Make NearSpansOrdered use lazy iteration Key: LUCENE-6537 URL: https://issues.apache.org/jira/browse/LUCENE-6537 Project: Lucene - Core Issue Type: Improvement Reporter: Alan Woodward Priority: Minor Attachments: LUCENE-6537.patch, LUCENE-6537.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6564) Normalize date format for IW in unit tests
[
https://issues.apache.org/jira/browse/LUCENE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14585705#comment-14585705
]
Michael McCandless commented on LUCENE-6564:
Probably doesn't matter but the patch is against 5.x...
Normalize date format for IW in unit tests
--
Key: LUCENE-6564
URL: https://issues.apache.org/jira/browse/LUCENE-6564
Project: Lucene - Core
Issue Type: Improvement
Components: general/test
Reporter: Ramkumar Aiyengar
Assignee: Ramkumar Aiyengar
Priority: Minor
Fix For: 5.3
Attachments: LUCENE-6564.patch, LUCENE-6564.patch
Noticed while debugging some IW output in an unit test that milliseconds were
not output in the date, changed this to reuse the date format used by
{{PrintStreamInfoStream}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
[ https://issues.apache.org/jira/browse/SOLR-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14585858#comment-14585858 ] Stephan Lagraulet commented on SOLR-6246: - [~hossman] How would you add this ReloadHook? I was thinking of adding methods to SolrCoreAware but there's a significant impact as many classes uses this interface... Core fails to reload when AnalyzingInfixSuggester is used as a Suggester Key: SOLR-6246 URL: https://issues.apache.org/jira/browse/SOLR-6246 Project: Solr Issue Type: Sub-task Components: SearchComponents - other Affects Versions: 4.8, 4.8.1, 4.9 Reporter: Varun Thacker Fix For: 5.2, Trunk Attachments: SOLR-6246-test.patch, SOLR-6246-test.patch, SOLR-6246.patch LUCENE-5477 - added near-real-time suggest building to AnalyzingInfixSuggester. One of the changes that went in was a writer is persisted now to support real time updates via the add() and update() methods. When we call Solr's reload command, a new instance of AnalyzingInfixSuggester is created. When trying to create a new writer on the same Directory a lock cannot be obtained and Solr fails to reload the core. Also when AnalyzingInfixLookupFactory throws a RuntimeException we should pass along the original message. I am not sure what should be the approach to fix it. Should we have a reloadHook where we close the writer? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6371) Improve Spans payload collection
[ https://issues.apache.org/jira/browse/LUCENE-6371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14585895#comment-14585895 ] ASF subversion and git services commented on LUCENE-6371: - Commit 1685577 from [~romseygeek] in branch 'dev/trunk' [ https://svn.apache.org/r1685577 ] LUCENE-6371: Turn off test verbosity Improve Spans payload collection Key: LUCENE-6371 URL: https://issues.apache.org/jira/browse/LUCENE-6371 Project: Lucene - Core Issue Type: Improvement Reporter: Paul Elschot Assignee: Alan Woodward Priority: Minor Fix For: 5.3, Trunk Attachments: LUCENE-6371-5x.patch, LUCENE-6371-5x.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch Spin off from LUCENE-6308, see the comments there from around 23 March 2015. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-SmokeRelease-5.2 - Build # 19 - Failure
I'll fix this once I send out the release announcements.
On Mon, Jun 15, 2015 at 2:15 PM, Apache Jenkins Server
jenk...@builds.apache.org wrote:
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.2/19/
No tests ran.
Build Log:
[...truncated 52575 lines...]
prepare-release-no-sign:
[mkdir] Created dir:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.2/lucene/build/smokeTestRelease/dist
[copy] Copying 446 files to
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.2/lucene/build/smokeTestRelease/dist/lucene
[copy] Copying 245 files to
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.2/lucene/build/smokeTestRelease/dist/solr
[smoker] Java 1.7
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
[smoker] NOTE: output encoding is UTF-8
[smoker]
[smoker] Load release URL
file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.2/lucene/build/smokeTestRelease/dist/...
[smoker]
[smoker] Test Lucene...
[smoker] test basics...
[smoker] get KEYS
[smoker] 0.1 MB in 0.01 sec (13.0 MB/sec)
[smoker] check changes HTML...
[smoker] download lucene-5.2.1-src.tgz...
[smoker] 28.3 MB in 0.04 sec (783.8 MB/sec)
[smoker] verify md5/sha1 digests
[smoker] download lucene-5.2.1.tgz...
[smoker] 65.2 MB in 0.08 sec (828.7 MB/sec)
[smoker] verify md5/sha1 digests
[smoker] download lucene-5.2.1.zip...
[smoker] 75.1 MB in 0.09 sec (823.0 MB/sec)
[smoker] verify md5/sha1 digests
[smoker] unpack lucene-5.2.1.tgz...
[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
[smoker] test demo with 1.7...
[smoker] got 5885 hits for query lucene
[smoker] checkindex with 1.7...
[smoker] check Lucene's javadoc JAR
[smoker] unpack lucene-5.2.1.zip...
[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
[smoker] test demo with 1.7...
[smoker] got 5885 hits for query lucene
[smoker] checkindex with 1.7...
[smoker] check Lucene's javadoc JAR
[smoker] unpack lucene-5.2.1-src.tgz...
[smoker] make sure no JARs/WARs in src dist...
[smoker] run ant validate
[smoker] run tests w/ Java 7 and testArgs='-Dtests.slow=false'...
[smoker] test demo with 1.7...
[smoker] got 209 hits for query lucene
[smoker] checkindex with 1.7...
[smoker] generate javadocs w/ Java 7...
[smoker]
[smoker] Crawl/parse...
[smoker]
[smoker] Verify...
[smoker] confirm all releases have coverage in TestBackwardsCompatibility
[smoker] find all past Lucene releases...
[smoker] run TestBackwardsCompatibility..
[smoker] Releases that don't seem to be tested:
[smoker] 5.2.1
[smoker] Traceback (most recent call last):
[smoker] File
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.2/dev-tools/scripts/smokeTestRelease.py,
line 1535, in module
[smoker] main()
[smoker] File
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.2/dev-tools/scripts/smokeTestRelease.py,
line 1480, in main
[smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir,
c.is_signed, ' '.join(c.test_args))
[smoker] File
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.2/dev-tools/scripts/smokeTestRelease.py,
line 1518, in smokeTest
[smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' %
version, svnRevision, version, testArgs, baseURL)
[smoker] File
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.2/dev-tools/scripts/smokeTestRelease.py,
line 628, in unpackAndVerify
[smoker] verifyUnpacked(java, project, artifact, unpackPath,
svnRevision, version, testArgs, tmpDir, baseURL)
[smoker] File
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.2/dev-tools/scripts/smokeTestRelease.py,
line 809, in verifyUnpacked
[smoker] confirmAllReleasesAreTestedForBackCompat(unpackPath)
[smoker] File
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.2/dev-tools/scripts/smokeTestRelease.py,
line 1473, in confirmAllReleasesAreTestedForBackCompat
[smoker] raise RuntimeError('some releases are not tested by
TestBackwardsCompatibility?')
[smoker] RuntimeError: some releases are not tested by
TestBackwardsCompatibility?
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.2/build.xml:421:
exec returned: 1
Total time: 39 minutes 15 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure
Sending email for trigger: Failure
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail:
Re: Release notes for Lucene/Solr 5.2.1
Thanks Anshum. On Mon, Jun 15, 2015 at 2:27 PM, Anshum Gupta ans...@anshumgupta.net wrote: Thanks Shalin! Looks good to me. I've removed a few auto-created links that were created due to the CapitalizedWords from the Solr notes. On Sun, Jun 14, 2015 at 11:29 PM, Shalin Shekhar Mangar shalinman...@gmail.com wrote: A draft for the Lucene and Solr 5.2.1 release notes are available at the following URLs - please feel free to improve. Lucene: https://wiki.apache.org/lucene-java/ReleaseNote521 Solr: http://wiki.apache.org/solr/ReleaseNote521 -- Regards, Shalin Shekhar Mangar. -- Anshum Gupta -- Regards, Shalin Shekhar Mangar. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6567) No need for out-of-order payload checks in SpanPayloadCheckQuery
Alan Woodward created LUCENE-6567: - Summary: No need for out-of-order payload checks in SpanPayloadCheckQuery Key: LUCENE-6567 URL: https://issues.apache.org/jira/browse/LUCENE-6567 Project: Lucene - Core Issue Type: Improvement Reporter: Alan Woodward Priority: Minor Since LUCENE-6537, all composite Spans implementations collect their payloads in-order, so we don't need special logic for that case anymore. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6567) No need for out-of-order payload checks in SpanPayloadCheckQuery
[ https://issues.apache.org/jira/browse/LUCENE-6567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated LUCENE-6567: -- Attachment: LUCENE-6567.patch Patch. No need for out-of-order payload checks in SpanPayloadCheckQuery Key: LUCENE-6567 URL: https://issues.apache.org/jira/browse/LUCENE-6567 Project: Lucene - Core Issue Type: Improvement Reporter: Alan Woodward Priority: Minor Attachments: LUCENE-6567.patch Since LUCENE-6537, all composite Spans implementations collect their payloads in-order, so we don't need special logic for that case anymore. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7344) Allow Jetty thread pool limits while still avoiding distributed deadlock.
[ https://issues.apache.org/jira/browse/SOLR-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586072#comment-14586072 ] Yonik Seeley commented on SOLR-7344: bq. Yonik, I am curious as to why Streaming API has to have infinite recursion? It's not infinite, and it shouldn't even be high. It's just that you don't know ahead of time what the upper bound will be because it's expressed in the request. Even 3 levels would mess us up if the majority of the traffic consisted of those types of requests and we didn't have this high-limit queue (it would essentially be back to the situation we have today with normal distributed search queries and one queue. If the queue calls itself, it needs to have a high limit.) Allow Jetty thread pool limits while still avoiding distributed deadlock. - Key: SOLR-7344 URL: https://issues.apache.org/jira/browse/SOLR-7344 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Attachments: SOLR-7344.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6371) Improve Spans payload collection
[ https://issues.apache.org/jira/browse/LUCENE-6371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14585905#comment-14585905 ] ASF subversion and git services commented on LUCENE-6371: - Commit 1685578 from [~romseygeek] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1685578 ] LUCENE-6371: Add SpanCollector Improve Spans payload collection Key: LUCENE-6371 URL: https://issues.apache.org/jira/browse/LUCENE-6371 Project: Lucene - Core Issue Type: Improvement Reporter: Paul Elschot Assignee: Alan Woodward Priority: Minor Fix For: 5.3, Trunk Attachments: LUCENE-6371-5x.patch, LUCENE-6371-5x.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch Spin off from LUCENE-6308, see the comments there from around 23 March 2015. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[ANNOUNCE] Apache Lucene 5.2.1 released
15 June 2015, Apache Lucene™ 5.2.1 available The Lucene PMC is pleased to announce the release of Apache Lucene 5.2.1 Apache Lucene is a high-performance, full-featured text search engine library written entirely in Java. It is a technology suitable for nearly any application that requires full-text search, especially cross-platform. This release contains various bug fixes and optimizations since the 5.2.0 release. The release is available for immediate download at: http://lucene.apache.org/core/mirrors-core-latest-redir.html Please read CHANGES.txt for a full list of new features and changes: https://lucene.apache.org/core/5_2_1/changes/Changes.html Lucene 5.2.1 includes 3 bug fixes: * Fix class loading deadlock relating to Codec initialization, default codec and SPI discovery. * NRT readers now reflect a new commit even if there is no change to the commit user data * Queries now get a dummy Similarity when scores are not needed in order to not load unnecessary information like norms Please report any feedback to the mailing lists (http://lucene.apache.org/core/discussion.html) Note: The Apache Software Foundation uses an extensive mirroring network for distributing releases. It is possible that the mirror you are using may not have replicated the release yet. If that is the case, please try another mirror. This also goes for Maven access. Happy searching! -- Shalin Shekhar Mangar on behalf of the Lucene PMC. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6561) Add a TermContextCache to IndexSearcher
[ https://issues.apache.org/jira/browse/LUCENE-6561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586048#comment-14586048 ] Alan Woodward commented on LUCENE-6561: --- bq. I don't think we should even encourage caching of this? Well at the moment we don't even make caching possible - TermContext.build() is a static method, so there's no way to do what Mike suggests and build an external cache. I agree that IndexSearcher is the wrong place to expose it though. And a package-private method wouldn't work, because SpanTermQuery is in a different package. The concurrency problems arise because of sharing the cache between multiple queries, maybe what's really needed is a QueryContext that's passed to createWeight() that holds this kind of info? Add a TermContextCache to IndexSearcher --- Key: LUCENE-6561 URL: https://issues.apache.org/jira/browse/LUCENE-6561 Project: Lucene - Core Issue Type: Improvement Reporter: Alan Woodward Attachments: LUCENE-6561.patch, LUCENE-6561.patch TermContexts can be quite expensive to build, and if you have fairly complex queries that re-use the same terms you can end up spending a lot of time re-building the same ones over and over again. It would be nice to be able to cache them on an IndexSearcher, so that they can be re-used. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6371) Improve Spans payload collection
[ https://issues.apache.org/jira/browse/LUCENE-6371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated LUCENE-6371: -- Attachment: LUCENE-6371-5x.patch Smaller patch, after LUCENE-6466 and LUCENE-6537 Improve Spans payload collection Key: LUCENE-6371 URL: https://issues.apache.org/jira/browse/LUCENE-6371 Project: Lucene - Core Issue Type: Improvement Reporter: Paul Elschot Assignee: Alan Woodward Priority: Minor Fix For: 5.3, Trunk Attachments: LUCENE-6371-5x.patch, LUCENE-6371-5x.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch Spin off from LUCENE-6308, see the comments there from around 23 March 2015. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7667) If more cores are loaded at startup than the transient core size, cores become unavailable.
[
https://issues.apache.org/jira/browse/SOLR-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey updated SOLR-7667:
---
Attachment: SOLR-7667-with-CoreAdmin-create-fail.patch
I made a slight adjustment to the patch where CoreAdmin fails to create a core
when the number of cores with loadOnStartup would exceed transientCacheSize.
This patch does cause one test failure that I've seen so far -- here's the
point in the test run where it logs the warning before throwing the exception:
{noformat}
[junit4] 2 80803 WARN
(TEST-TestLazyCores.testCreateTransientFromAdmin-seed#[63584E21E9EC83F]) [
x:core2] o.a.s.h.a.CoreAdminHandler 4 cores already marked to load on startup,
with a transient cache size of 4. Raise transientCacheSize in solr.xml.
{noformat}
Here's the exception:
{noformat}
[junit4] ERROR 0.24s J0 | TestLazyCores.testCreateTransientFromAdmin
[junit4] Throwable #1: org.apache.solr.common.SolrException: Core
creation failed. Number of cores marked to load on startup would exceed
transient cache size. Raise transientCacheSize in solr.xml and try again.
{noformat}
If more cores are loaded at startup than the transient core size, cores
become unavailable.
---
Key: SOLR-7667
URL: https://issues.apache.org/jira/browse/SOLR-7667
Project: Solr
Issue Type: Bug
Affects Versions: 5.2.1, Trunk
Reporter: Erick Erickson
Assignee: Erick Erickson
Attachments: CoreContainer.java,
SOLR-7667-with-CoreAdmin-create-fail.patch,
SOLR-7667-with-CoreAdmin-create-fail.patch, SOLR-7667.patch, SOLR-7667.patch
Edwin Lee from the user's list caught this, the original post is titled
loadOnStartup transientCoreSize BUG Report on CoreContainer.java
Nice catch Edwin!
More details to follow:
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6371) Improve Spans payload collection
[ https://issues.apache.org/jira/browse/LUCENE-6371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward resolved LUCENE-6371. --- Resolution: Fixed Thanks everyone! Improve Spans payload collection Key: LUCENE-6371 URL: https://issues.apache.org/jira/browse/LUCENE-6371 Project: Lucene - Core Issue Type: Improvement Reporter: Paul Elschot Assignee: Alan Woodward Priority: Minor Fix For: 5.3, Trunk Attachments: LUCENE-6371-5x.patch, LUCENE-6371-5x.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch Spin off from LUCENE-6308, see the comments there from around 23 March 2015. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6539) Add DocValuesNumbersQuery, like DocValuesTermsQuery but works only with long values
[ https://issues.apache.org/jira/browse/LUCENE-6539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586084#comment-14586084 ] ASF subversion and git services commented on LUCENE-6539: - Commit 1685585 from [~mikemccand] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1685585 ] LUCENE-6539: Add DocValuesNumbersQuery Add DocValuesNumbersQuery, like DocValuesTermsQuery but works only with long values --- Key: LUCENE-6539 URL: https://issues.apache.org/jira/browse/LUCENE-6539 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 5.3, Trunk Attachments: LUCENE-6539.patch, LUCENE-6539.patch This query accepts any document where any of the provided set of longs was indexed into the specified field as a numeric DV field (NumericDocValuesField or SortedNumericDocValuesField). You can use it instead of DocValuesTermsQuery when you have field values that can be represented as longs. Like DocValuesTermsQuery, this is slowish in general, since it doesn't use an inverted data structure, but in certain cases (many terms/numbers and fewish matching hits) it should be faster than using TermsQuery because it's done as a post filter when other (faster) query clauses are MUST'd with it. In such cases it should also be faster than DocValuesTermsQuery since it skips having to resolve terms - ords. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7662) Refactor the DocList writing to a common class
[ https://issues.apache.org/jira/browse/SOLR-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-7662: - Attachment: SOLR-7662_5X.patch Refactor the DocList writing to a common class -- Key: SOLR-7662 URL: https://issues.apache.org/jira/browse/SOLR-7662 Project: Solr Issue Type: Sub-task Reporter: Noble Paul Assignee: Noble Paul Attachments: SOLR-7662.patch, SOLR-7662_5X.patch The code for streaming DocList is replicated in many response writers . Refactor it into a single place and re-use everywhere -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6544) Geo3d cleanup: Regularize path and polygon construction, plus consider adding ellipsoid surface distance method
[ https://issues.apache.org/jira/browse/LUCENE-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586081#comment-14586081 ] David Smiley commented on LUCENE-6544: -- I like the changes Karl. Some feedback: * GeoPath: I think the done() methods should throw an IllegalStateException if it is called after it has already been called (edgePoints is already defined)? And likewise, addPoint could throw if edgePoints is already defined. * PlanetModel: I think the surfaceDistance() method should include javadocs to mention that it's intended for non-spherical PlanetModel; for sphere use GeoPoint.arcDistance. And for that matter, GeoPoint.arcDistance could mention it's computation is surface of a sphere, and that for accurate ellipsoidal, use PlanetModel.surfaceDistance(). The issue of thread-safety came to mind as I saw the lazy-evaluation of the latitude longitude. There should be some docs/language somewhere so that people can understand that Geo3D generally isn't necessarily threadsafe, and GeoPoint in particular isn't. Lazy BBox calculation of Geo3dShape is another reason. This isn't necessarily a big deal but at least should be documented for these two classes, indicating how to construct them such that they are thread-safe. Come to think of it, even if an app knows to call getLatitude/Longitude on GeoPoint so that it's fully constructed, it has no way to do so on any use of GeoPoint embedded within other Geo3d shapes (such as GeoDegenerateHorizontalLine). What do you think? Geo3d cleanup: Regularize path and polygon construction, plus consider adding ellipsoid surface distance method --- Key: LUCENE-6544 URL: https://issues.apache.org/jira/browse/LUCENE-6544 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: Karl Wright Attachments: LUCENE-6544.patch Geo3d's way of constructing polygons and paths differs in that in one case you construct points and the other you feed lat/lon values directly to the builder. Probably both should be supported for both kinds of entity. Also it may be useful to have an accurate point-point ellipsoidal distance function. This is expensive and would be an addition to the arc distance we currently compute. It would probably be called surface distance. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7668) Port-base rule for shard placement causes NPE
[ https://issues.apache.org/jira/browse/SOLR-7668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14585861#comment-14585861 ] ASF subversion and git services commented on SOLR-7668: --- Commit 1685572 from [~noble.paul] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1685572 ] SOLR-7668: Add 'port' tag support in replica placement rules Port-base rule for shard placement causes NPE - Key: SOLR-7668 URL: https://issues.apache.org/jira/browse/SOLR-7668 Project: Solr Issue Type: Bug Affects Versions: 5.2 Reporter: Adam McElwee Assignee: Noble Paul Priority: Minor Attachments: SOLR-7668.patch, SOLR-7668.patch I was setting up some rule-based collections, and I hit an NPE whenever I try to include a port-based rule. It looks like the implementation was started, but not completed for ports. Patch coming in just a moment. I included a test, and I have no problems getting the test to pass when run by itself. However, when I run it w/ the other tests in RulesTest, it fails because of some ZK errors, but I often have those issues when running any of the distrib tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6539) Add DocValuesNumbersQuery, like DocValuesTermsQuery but works only with long values
[ https://issues.apache.org/jira/browse/LUCENE-6539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-6539. Resolution: Fixed Add DocValuesNumbersQuery, like DocValuesTermsQuery but works only with long values --- Key: LUCENE-6539 URL: https://issues.apache.org/jira/browse/LUCENE-6539 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 5.3, Trunk Attachments: LUCENE-6539.patch, LUCENE-6539.patch This query accepts any document where any of the provided set of longs was indexed into the specified field as a numeric DV field (NumericDocValuesField or SortedNumericDocValuesField). You can use it instead of DocValuesTermsQuery when you have field values that can be represented as longs. Like DocValuesTermsQuery, this is slowish in general, since it doesn't use an inverted data structure, but in certain cases (many terms/numbers and fewish matching hits) it should be faster than using TermsQuery because it's done as a post filter when other (faster) query clauses are MUST'd with it. In such cases it should also be faster than DocValuesTermsQuery since it skips having to resolve terms - ords. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[ANNOUNCE] Apache Solr 5.2.1 released
15 June 2015, Apache Solr™ 5.2.1 available The Lucene PMC is pleased to announce the release of Apache Solr 5.2.1 Solr is the popular, blazing fast, open source NoSQL search platform from the Apache Lucene project. Its major features include powerful full-text search, hit highlighting, faceted search, dynamic clustering, database integration, rich document (e.g., Word, PDF) handling, and geospatial search. Solr is highly scalable, providing fault tolerant distributed search and indexing, and powers the search and navigation features of many of the world's largest internet sites. This release contains various bug fixes and optimizations since the 5.2.0 release. The release is available for immediate download at: http://lucene.apache.org/solr/mirrors-solr-latest-redir.html Please read CHANGES.txt for a full list of new features and changes: https://lucene.apache.org/solr/5_2_1/changes/Changes.html Solr 5.2.1 includes 8 bug fixes and 2 other changes. Release Highlights: * Fix javascript bug introduced by SOLR-7409 that breaks the dataimport screen in the admin UI * Faceting on a numeric field with a unique() subfacet function on another numeric field can result in incorrect results or an exception * New Facet Module should respect shards.tolerant and process all non-failing shards instead of throwing an exception * A request with a json content type but no body caused a null pointer exception * SolrOutputFormat creates an invalid solr.xml in the solr home zip for MapReduceIndexerTool * Fix new (Angular-based) admin UI Cloud pane * The DefaultSolrHighlighter since 5.0 was determining if payloads were present in a way that was slow, especially when lots of fields were highlighted. It's now fast * Requests aren't distributed evenly if the collection isn't present locally See the CHANGES.txt file included with the release for a full list of changes and further details. Please report any feedback to the mailing lists (http://lucene.apache.org/solr/discussion.html) Note: The Apache Software Foundation uses an extensive mirroring network for distributing releases. It is possible that the mirror you are using may not have replicated the release yet. If that is the case, please try another mirror. This also goes for Maven access. Happy searching! -- Shalin Shekhar Mangar on behalf of the Lucene PMC. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7596) Add possibility to specify port of embedded Zookeeper
[ https://issues.apache.org/jira/browse/SOLR-7596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586143#comment-14586143 ] Mark Miller commented on SOLR-7596: --- Worth supporting the feature anyway. We support an embedded zk mode. We can support picking the port I think. Add possibility to specify port of embedded Zookeeper - Key: SOLR-7596 URL: https://issues.apache.org/jira/browse/SOLR-7596 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 5.1 Reporter: Arcadius Ahouansou Priority: Minor Currently, the startup script bin/solr accepts only '-p' for the solr port and there is no way to pass the embedded zookeeper port as a command line param (when using '-c' without '-z'). This ticket is to allow for '-P' or something similar that would be used as the port of the embedded ZK instead of the default solrPort+1000 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6473) Make Spans an interface
[ https://issues.apache.org/jira/browse/LUCENE-6473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward resolved LUCENE-6473. --- Resolution: Won't Fix This isn't necessary due to LUCENE-6371 Make Spans an interface --- Key: LUCENE-6473 URL: https://issues.apache.org/jira/browse/LUCENE-6473 Project: Lucene - Core Issue Type: Improvement Reporter: Alan Woodward Attachments: LUCENE-6473.patch Spans is currently an abstract class, extending DocIdSetIterator. This restricts what we can do with implementations of Spans. For example, in LUCENE-6371, it would be useful to have PayloadSpan classes that extend existing Spans implementations, but that also implement a PayloadSpans interface that extends Spans. This isn't possible if Spans is not an interface itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7458) Expose HDFS Block Locality Metrics
[ https://issues.apache.org/jira/browse/SOLR-7458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586232#comment-14586232 ] Mike Drob commented on SOLR-7458: - New JIRA or just attach to this one? Expose HDFS Block Locality Metrics -- Key: SOLR-7458 URL: https://issues.apache.org/jira/browse/SOLR-7458 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mike Drob Assignee: Mark Miller Labels: metrics Fix For: 5.3, Trunk Attachments: Data Locality.png, SOLR-7458.patch, SOLR-7458.patch, SOLR-7458.patch, SOLR-7458.patch, SOLR-7458.patch We should publish block locality metrics when using HDFS. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7662) Refactor the DocList writing to a common class
[ https://issues.apache.org/jira/browse/SOLR-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-7662: - Attachment: SOLR-7662_5X.patch all tests pass Refactor the DocList writing to a common class -- Key: SOLR-7662 URL: https://issues.apache.org/jira/browse/SOLR-7662 Project: Solr Issue Type: Sub-task Reporter: Noble Paul Assignee: Noble Paul Attachments: SOLR-7662.patch, SOLR-7662_5X.patch, SOLR-7662_5X.patch The code for streaming DocList is replicated in many response writers . Refactor it into a single place and re-use everywhere -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7458) Expose HDFS Block Locality Metrics
[ https://issues.apache.org/jira/browse/SOLR-7458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586175#comment-14586175 ] Mike Drob commented on SOLR-7458: - Strange. I tried running the suggested ant command and was unable to reproduce locally. The command output on Jenkins isn't terribly useful either. I can submit a patch to add error messages to the asserts if we think that will help long term maintainability. The failure looks like the test runner on Jenkins is able to count the written blocks as local despite no hostname having been set. Maybe something in the environment affects how MiniDfsCluster operates. We could set an explicit bogus hostname to ensure that the data is not local. I'm not sure how the test will interact with 127.0.0.1 (the next assert) on Jenkins though. Expose HDFS Block Locality Metrics -- Key: SOLR-7458 URL: https://issues.apache.org/jira/browse/SOLR-7458 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mike Drob Assignee: Mark Miller Labels: metrics Fix For: 5.3, Trunk Attachments: Data Locality.png, SOLR-7458.patch, SOLR-7458.patch, SOLR-7458.patch, SOLR-7458.patch, SOLR-7458.patch We should publish block locality metrics when using HDFS. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7668) Port-base rule for shard placement causes NPE
[ https://issues.apache.org/jira/browse/SOLR-7668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586131#comment-14586131 ] Noble Paul commented on SOLR-7668: -- It was committed as is . I had to edit some of it. That is why I used a comma instead of 'via' Port-base rule for shard placement causes NPE - Key: SOLR-7668 URL: https://issues.apache.org/jira/browse/SOLR-7668 Project: Solr Issue Type: Bug Affects Versions: 5.2 Reporter: Adam McElwee Assignee: Noble Paul Priority: Minor Attachments: SOLR-7668.patch, SOLR-7668.patch I was setting up some rule-based collections, and I hit an NPE whenever I try to include a port-based rule. It looks like the implementation was started, but not completed for ports. Patch coming in just a moment. I included a test, and I have no problems getting the test to pass when run by itself. However, when I run it w/ the other tests in RulesTest, it fails because of some ZK errors, but I often have those issues when running any of the distrib tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6564) Normalize date format for IW in unit tests
[
https://issues.apache.org/jira/browse/LUCENE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586140#comment-14586140
]
Mark Miller commented on LUCENE-6564:
-
bq. The other possibility is using a ThreadLocal:
That seems to be a fairly std practice for SimpleDateFormat usage - kind of
silly though.
Normalize date format for IW in unit tests
--
Key: LUCENE-6564
URL: https://issues.apache.org/jira/browse/LUCENE-6564
Project: Lucene - Core
Issue Type: Improvement
Components: general/test
Reporter: Ramkumar Aiyengar
Assignee: Ramkumar Aiyengar
Priority: Minor
Fix For: 5.3
Attachments: LUCENE-6564.patch, LUCENE-6564.patch
Noticed while debugging some IW output in an unit test that milliseconds were
not output in the date, changed this to reuse the date format used by
{{PrintStreamInfoStream}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6539) Add DocValuesNumbersQuery, like DocValuesTermsQuery but works only with long values
[ https://issues.apache.org/jira/browse/LUCENE-6539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586193#comment-14586193 ] ASF subversion and git services commented on LUCENE-6539: - Commit 1685597 from [~steve_rowe] in branch 'dev/trunk' [ https://svn.apache.org/r1685597 ] LUCENE-6539: Intellij config: add sandbox module dependency to solr-core and solr-analysis-extras modules Add DocValuesNumbersQuery, like DocValuesTermsQuery but works only with long values --- Key: LUCENE-6539 URL: https://issues.apache.org/jira/browse/LUCENE-6539 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 5.3, Trunk Attachments: LUCENE-6539.patch, LUCENE-6539.patch This query accepts any document where any of the provided set of longs was indexed into the specified field as a numeric DV field (NumericDocValuesField or SortedNumericDocValuesField). You can use it instead of DocValuesTermsQuery when you have field values that can be represented as longs. Like DocValuesTermsQuery, this is slowish in general, since it doesn't use an inverted data structure, but in certain cases (many terms/numbers and fewish matching hits) it should be faster than using TermsQuery because it's done as a post filter when other (faster) query clauses are MUST'd with it. In such cases it should also be faster than DocValuesTermsQuery since it skips having to resolve terms - ords. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6547) Add dateline crossing support to GeoPointInBBox and GeoPointDistance Queries
[ https://issues.apache.org/jira/browse/LUCENE-6547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586191#comment-14586191 ] Nicholas Knize edited comment on LUCENE-6547 at 6/15/15 3:36 PM: - Updated patch to include review feedback from [~mikemccand]: * Added back validation check for lat/lons passed to GeoPointInBBoxQuery. * Reverted changes made to GeoPointInPolygonQuery. * Changed GeoPointTermsEnum.min/maxLat back to final * Changed dateline split logic for GeoPointInBBox and GeoPointDistance query to rewrite using BQ SHOULD. * Keeping circleToPoly utility method, for now, for testing PointInPolygon query performance (this can maybe go away later?) * Updated GeoPointDistanceQuery javadocs bq. Can we fix the random test to more strongly separate out the cases its testing? Will get this in either the next iteration, or maybe a separate 'improve GeoPointField Testing' issue? was (Author: nknize): Updated patch to include review feedback from [~mikemccand]: * Added back validation check for lat/lons passed to GeoPointInBBoxQuery. * Reverted changes made to GeoPointInPolygonQuery. * Changed GeoPointTermsEnum.min/maxLat back to final * Changed dateline split logic for GeoPointInBBox and GeoPointDistance query to rewrite using BQ SHOULD. * Keeping circleToPoly utility method, for now, for testing PointInPolygon query performance (this can maybe go away later?) * Updated GeoPointDistanceQuery javadocs bq. Can we fix the random test to more strongly separate out the cases its testing? Will get this in either the next iteration, or maybe a separate 'improve GeoPointField Testing' issue? Add dateline crossing support to GeoPointInBBox and GeoPointDistance Queries Key: LUCENE-6547 URL: https://issues.apache.org/jira/browse/LUCENE-6547 Project: Lucene - Core Issue Type: Improvement Components: core/search Reporter: Nicholas Knize Attachments: LUCENE-6547.patch, LUCENE-6547.patch, LUCENE-6547.patch, LUCENE-6547.patch The current GeoPointInBBoxQuery only supports bounding boxes that are within the standard -180:180 longitudinal bounds. While its perfectly fine to require users to split dateline crossing bounding boxes in two, GeoPointDistanceQuery should support distance queries that cross the dateline. Since morton encoding doesn't support unwinding this issue will add dateline crossing to GeoPointInBBoxQuery and GeoPointDistanceQuery classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7458) Expose HDFS Block Locality Metrics
[ https://issues.apache.org/jira/browse/SOLR-7458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586242#comment-14586242 ] Mark Miller commented on SOLR-7458: --- This one is fine since we are just improving the test messages. Expose HDFS Block Locality Metrics -- Key: SOLR-7458 URL: https://issues.apache.org/jira/browse/SOLR-7458 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mike Drob Assignee: Mark Miller Labels: metrics Fix For: 5.3, Trunk Attachments: Data Locality.png, SOLR-7458.patch, SOLR-7458.patch, SOLR-7458.patch, SOLR-7458.patch, SOLR-7458.patch We should publish block locality metrics when using HDFS. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7668) Port-base rule for shard placement causes NPE
[ https://issues.apache.org/jira/browse/SOLR-7668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586110#comment-14586110 ] Mark Miller commented on SOLR-7668: --- When you essentially simply commit someone else patch, the correct credit is: bq. Adam McElwee via Noble Paul. Port-base rule for shard placement causes NPE - Key: SOLR-7668 URL: https://issues.apache.org/jira/browse/SOLR-7668 Project: Solr Issue Type: Bug Affects Versions: 5.2 Reporter: Adam McElwee Assignee: Noble Paul Priority: Minor Attachments: SOLR-7668.patch, SOLR-7668.patch I was setting up some rule-based collections, and I hit an NPE whenever I try to include a port-based rule. It looks like the implementation was started, but not completed for ports. Patch coming in just a moment. I included a test, and I have no problems getting the test to pass when run by itself. However, when I run it w/ the other tests in RulesTest, it fails because of some ZK errors, but I often have those issues when running any of the distrib tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_45) - Build #12782 - Failure!
Hit this a while ago, simply cleaned up and it went away...
On Sun, Jun 14, 2015 at 9:34 PM Noble Paul noble.p...@gmail.com wrote:
This is a problem still.
I made some changes to my trunk and I get this error always
java.lang.NoSuchFieldError: totalTermCount
This gives a false alarm and we waste time. We need to get to the
bottom of this
On Tue, May 26, 2015 at 8:58 PM, Erick Erickson erickerick...@gmail.com
wrote:
Yep. I found this while trying to deal with CDCR, which is only in trunk.
On Mon, May 25, 2015 at 11:51 PM, Noble Paul noble.p...@gmail.com
wrote:
Do you mean in trunk ?
On Mon, May 25, 2015 at 9:53 PM, Erick Erickson
erickerick...@gmail.com wrote:
The problem went away for me. I took sledgehammer approach and deleted
the entire tree locally and checked out the tree fresh.
On Mon, May 25, 2015 at 4:37 AM, Noble Paul noble.p...@gmail.com
wrote:
I'v edone a clean checkout I still see these errors
meta http-equiv=Content-Type content=text/html; charset=UTF-8/
titleError 500 Server Error/title
/head
bodyh2HTTP ERROR 500/h2
pProblem accessing /solr/.system_shard1_replica2/update. Reason:
preServer Error/pre/ph3Caused
by:/h3prejava.lang.NoSuchFieldError: totalTermCount
at
org.apache.lucene.index.BufferedUpdatesStream.applyDeletesAndUpdates(BufferedUpdatesStream.java:277)
at
org.apache.lucene.index.IndexWriter.applyAllDeletesAndUpdates(IndexWriter.java:3032)
at
org.apache.lucene.index.IndexWriter.maybeApplyDeletes(IndexWriter.java:3018)
at
org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2707)
at
org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2852)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2819)
at
org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:586)
On Sat, May 23, 2015 at 11:52 AM, Erick Erickson
erickerick...@gmail.com wrote:
thanks! I'll give it a whirl. It's particularly weird b/c my pro runs
everything just fine, my laptop fails all the time.
On Fri, May 22, 2015 at 10:10 PM, Ishan Chattopadhyaya
ichattopadhy...@gmail.com wrote:
Not sure if it is related or helpful, but while debugging tests for
SOLR-7468 yesterday, I encountered this
java.lang.NoSuchFieldError:
totalTermCount
few times, I had to forcefully clean at root of the project and it
worked. I
remember Anshum had to do that clean thing more than once to make
it work
and he remarked don't ask why.
Sent from my Windows Phone
From: Erick Erickson
Sent: 5/23/2015 6:15 AM
To: dev@lucene.apache.org
Subject: Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_45)
- Build
#12782 - Failure!
OK, this is somewhat weird. I still have the original tree that I
checked in from which was up to date before I committed the code and
the tests run from there fine. But a current trunk fails every time.
Now, the machine it works on is my Mac Pro, and the failures are on
my
MacBook so there may be something going on there.
I've got to leave for a while, I'll copy the tree that works on the
Pro, update the copy and see if this test fails when I get back. If
they fail, I can diff the trees to see what changed and see if I can
make any sense out of this.
I can always @Ignore this test to cut down on the noise, probably do
that tonight if I don't have any revelations.
I see this stack trace which makes no sense to me whatsoever (see
the
lines with lots of * in front). I looked at where the code
originates (BufferedUpdatesStream[277]) and it looks like this:
if (coalescedUpdates != null coalescedUpdates.totalTermCount !=
0) {
And it's telling me there's no such field? Wha
Which is freaking me out since I don't see how this would trigger
the
exception. Is this a red herring? And, of course, this doesn't fail
in
IntelliJ but it does fail every time from the shell. Shhh.
Of course if this were something fundamental to Lucene, it seems
like
this would be failing all over the place so I assume it's something
to
do with CDCR... But what do I know?
1:56434/source_collection_shard2_replica1/commit_end_point=truewt=javabinversion=2expungeDeletes=false}
status=0 QTime=8
* [junit4] 2 143699 T370 n:127.0.0.1:56443_
c:source_collection s:shard1 r:core_node3
x:source_collection_shard1_replica1 C122 oasc.SolrException.log
ERROR
null:java.lang.RuntimeException: java.lang.NoSuchFieldError:
totalTermCount
[junit4] 2 at
org.apache.solr.servlet.HttpSolrCall.sendError(HttpSolrCall.java:579)
[junit4] 2 at
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:451)
[junit4] 2 at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
[junit4] 2 at
[jira] [Commented] (LUCENE-6564) Normalize date format for IW in unit tests
[
https://issues.apache.org/jira/browse/LUCENE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586247#comment-14586247
]
Uwe Schindler commented on LUCENE-6564:
---
Because of this, I would suggest to keep everything like it is and just
misuse {{java.nio.file.attribute.FileTime}} for formatting as IS-8601
timestamp. So patch is quite easy...
Normalize date format for IW in unit tests
--
Key: LUCENE-6564
URL: https://issues.apache.org/jira/browse/LUCENE-6564
Project: Lucene - Core
Issue Type: Improvement
Components: general/test
Reporter: Ramkumar Aiyengar
Assignee: Ramkumar Aiyengar
Priority: Minor
Fix For: 5.3
Attachments: LUCENE-6564.patch, LUCENE-6564.patch
Noticed while debugging some IW output in an unit test that milliseconds were
not output in the date, changed this to reuse the date format used by
{{PrintStreamInfoStream}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6544) Geo3d cleanup: Regularize path and polygon construction, plus consider adding ellipsoid surface distance method
[ https://issues.apache.org/jira/browse/LUCENE-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586120#comment-14586120 ] Karl Wright commented on LUCENE-6544: - I'm fine with the GeoPath and PlanetModel suggestions. Thread safety is easier than you think, because all classes with lazy members are in fact immutable *except* for those lazy members, and they are based only other (immutable) characteristics of the classes in question. So the worst that can happen if more than one thread attempts to fill in one of these values is that it will be computed twice -- one time unnecessarily. I suspect that therefore the only thing we really need to do is mention this in the javadoc for the lazy variable(s), and maybe (could be wrong about this) declare those variables to be volatile. Thoughts? Geo3d cleanup: Regularize path and polygon construction, plus consider adding ellipsoid surface distance method --- Key: LUCENE-6544 URL: https://issues.apache.org/jira/browse/LUCENE-6544 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: Karl Wright Attachments: LUCENE-6544.patch Geo3d's way of constructing polygons and paths differs in that in one case you construct points and the other you feed lat/lon values directly to the builder. Probably both should be supported for both kinds of entity. Also it may be useful to have an accurate point-point ellipsoidal distance function. This is expensive and would be an addition to the arc distance we currently compute. It would probably be called surface distance. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-7668) Port-base rule for shard placement causes NPE
[ https://issues.apache.org/jira/browse/SOLR-7668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586131#comment-14586131 ] Noble Paul edited comment on SOLR-7668 at 6/15/15 2:47 PM: --- It was not committed as is . I had to edit some of it. That is why I used a comma instead of 'via' was (Author: noble.paul): It was committed as is . I had to edit some of it. That is why I used a comma instead of 'via' Port-base rule for shard placement causes NPE - Key: SOLR-7668 URL: https://issues.apache.org/jira/browse/SOLR-7668 Project: Solr Issue Type: Bug Affects Versions: 5.2 Reporter: Adam McElwee Assignee: Noble Paul Priority: Minor Attachments: SOLR-7668.patch, SOLR-7668.patch I was setting up some rule-based collections, and I hit an NPE whenever I try to include a port-based rule. It looks like the implementation was started, but not completed for ports. Patch coming in just a moment. I included a test, and I have no problems getting the test to pass when run by itself. However, when I run it w/ the other tests in RulesTest, it fails because of some ZK errors, but I often have those issues when running any of the distrib tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6544) Geo3d cleanup: Regularize path and polygon construction, plus consider adding ellipsoid surface distance method
[ https://issues.apache.org/jira/browse/LUCENE-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586178#comment-14586178 ] Karl Wright commented on LUCENE-6544: - [~mikemccand]: Do I have the Java contract right? For a situation as described above, is volatile necessary? Geo3d cleanup: Regularize path and polygon construction, plus consider adding ellipsoid surface distance method --- Key: LUCENE-6544 URL: https://issues.apache.org/jira/browse/LUCENE-6544 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: Karl Wright Attachments: LUCENE-6544.patch Geo3d's way of constructing polygons and paths differs in that in one case you construct points and the other you feed lat/lon values directly to the builder. Probably both should be supported for both kinds of entity. Also it may be useful to have an accurate point-point ellipsoidal distance function. This is expensive and would be an addition to the arc distance we currently compute. It would probably be called surface distance. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6539) Add DocValuesNumbersQuery, like DocValuesTermsQuery but works only with long values
[ https://issues.apache.org/jira/browse/LUCENE-6539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586197#comment-14586197 ] ASF subversion and git services commented on LUCENE-6539: - Commit 1685598 from [~steve_rowe] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1685598 ] LUCENE-6539: Intellij config: add sandbox module dependency to solr-core and solr-analysis-extras modules (merged trunk r1685597) Add DocValuesNumbersQuery, like DocValuesTermsQuery but works only with long values --- Key: LUCENE-6539 URL: https://issues.apache.org/jira/browse/LUCENE-6539 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 5.3, Trunk Attachments: LUCENE-6539.patch, LUCENE-6539.patch This query accepts any document where any of the provided set of longs was indexed into the specified field as a numeric DV field (NumericDocValuesField or SortedNumericDocValuesField). You can use it instead of DocValuesTermsQuery when you have field values that can be represented as longs. Like DocValuesTermsQuery, this is slowish in general, since it doesn't use an inverted data structure, but in certain cases (many terms/numbers and fewish matching hits) it should be faster than using TermsQuery because it's done as a post filter when other (faster) query clauses are MUST'd with it. In such cases it should also be faster than DocValuesTermsQuery since it skips having to resolve terms - ords. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6547) Add dateline crossing support to GeoPointInBBox and GeoPointDistance Queries
[ https://issues.apache.org/jira/browse/LUCENE-6547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-6547: --- Attachment: LUCENE-6547.patch Updated patch to include review feedback from [~mikemccand]: * Added back validation check for lat/lons passed to GeoPointInBBoxQuery. * Reverted changes made to GeoPointInPolygonQuery. * Changed GeoPointTermsEnum.min/maxLat back to final * Changed dateline split logic for GeoPointInBBox and GeoPointDistance query to rewrite using BQ SHOULD. * Keeping circleToPoly utility method, for now, for testing PointInPolygon query performance (this can maybe go away later?) * Updated GeoPointDistanceQuery javadocs bq. Can we fix the random test to more strongly separate out the cases its testing? Will get this in either the next iteration, or maybe a separate 'improve GeoPointField Testing' issue? Add dateline crossing support to GeoPointInBBox and GeoPointDistance Queries Key: LUCENE-6547 URL: https://issues.apache.org/jira/browse/LUCENE-6547 Project: Lucene - Core Issue Type: Improvement Components: core/search Reporter: Nicholas Knize Attachments: LUCENE-6547.patch, LUCENE-6547.patch, LUCENE-6547.patch, LUCENE-6547.patch The current GeoPointInBBoxQuery only supports bounding boxes that are within the standard -180:180 longitudinal bounds. While its perfectly fine to require users to split dateline crossing bounding boxes in two, GeoPointDistanceQuery should support distance queries that cross the dateline. Since morton encoding doesn't support unwinding this issue will add dateline crossing to GeoPointInBBoxQuery and GeoPointDistanceQuery classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7458) Expose HDFS Block Locality Metrics
[ https://issues.apache.org/jira/browse/SOLR-7458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586221#comment-14586221 ] Mark Miller commented on SOLR-7458: --- bq. I can submit a patch to add error messages to the asserts if we think that will help long term maintainability. +1 Expose HDFS Block Locality Metrics -- Key: SOLR-7458 URL: https://issues.apache.org/jira/browse/SOLR-7458 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mike Drob Assignee: Mark Miller Labels: metrics Fix For: 5.3, Trunk Attachments: Data Locality.png, SOLR-7458.patch, SOLR-7458.patch, SOLR-7458.patch, SOLR-7458.patch, SOLR-7458.patch We should publish block locality metrics when using HDFS. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Release notes for Lucene/Solr 5.2.1
A draft for the Lucene and Solr 5.2.1 release notes are available at the following URLs - please feel free to improve. Lucene: https://wiki.apache.org/lucene-java/ReleaseNote521 Solr: http://wiki.apache.org/solr/ReleaseNote521 -- Regards, Shalin Shekhar Mangar.
[jira] [Commented] (SOLR-7688) JettyConfig cannot be used with extra filters
[ https://issues.apache.org/jira/browse/SOLR-7688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14587264#comment-14587264 ] Gregory Chanan commented on SOLR-7688: -- My patch changes it to a LinkedHashMap, adds a test, and also fixes up some params. The double initialization issue looks interesting, thanks for pointing that out. Assuming that is the case, though, the debugFilter is also double initialized and should be handled in a similar way? Seems like that should be handled in a separate issue. JettyConfig cannot be used with extra filters - Key: SOLR-7688 URL: https://issues.apache.org/jira/browse/SOLR-7688 Project: Solr Issue Type: Improvement Affects Versions: 5.1 Reporter: Gregory Chanan Assignee: Gregory Chanan Attachments: SOLR-7688.patch, SOLR-7688.patch Before SOLR-7166, users could create a MiniSolrCloudCluster with extra filters by specifying their own SortedMap and comparator (since Class? extends Filter is not comparable). JettyConfigs allow you to specify filter classes to add, but they don't work because JettyConfigs manages its own filter map using TreeMap. Thus, there is no way to specify a comparator and it fails at runtime with Class cannot be cast to java.lang.comparable. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-5.2 - Build # 19 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.2/19/ 1 tests failed. FAILED: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=1061, name=collection3, state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=1061, name=collection3, state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest] Caused by: java.lang.RuntimeException: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[http://127.0.0.1:35721/ruz, http://127.0.0.1:55216/ruz, http://127.0.0.1:36118/ruz, http://127.0.0.1:50645/ruz, http://127.0.0.1:49043/ruz] at __randomizedtesting.SeedInfo.seed([807B256ACD339729]:0) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:887) Caused by: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[http://127.0.0.1:35721/ruz, http://127.0.0.1:55216/ruz, http://127.0.0.1:36118/ruz, http://127.0.0.1:50645/ruz, http://127.0.0.1:49043/ruz] at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:355) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:884) Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:55216/ruz: KeeperErrorCode = Session expired for /overseer/collection-queue-work/qn- at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:235) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:227) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328) ... 5 more Build Log: [...truncated 10216 lines...] [junit4] Suite: org.apache.solr.cloud.CollectionsAPIDistributedZkTest [junit4] 2 Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.2/solr/build/solr-core/test/J1/temp/solr.cloud.CollectionsAPIDistributedZkTest_807B256ACD339729-001/init-core-data-001 [junit4] 2 183523 T765 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl (false) and clientAuth (false) [junit4] 2 183523 T765 oas.BaseDistributedSearchTestCase.initHostContext Setting hostContext system property: /ruz/ [junit4] 2 183529 T765 oasc.ZkTestServer.run STARTING ZK TEST SERVER [junit4] 2 183530 T766 oasc.ZkTestServer$2$1.setClientPort client port:0.0.0.0/0.0.0.0:0 [junit4] 2 183530 T766 oasc.ZkTestServer$ZKServerMain.runFromConfig Starting server [junit4] 2 183630 T765 oasc.ZkTestServer.run start zk server on port:36178 [junit4] 2 183630 T765 oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default ZkCredentialsProvider [junit4] 2 183632 T765 oascc.ConnectionManager.waitForConnected Waiting for client to connect to ZooKeeper [junit4] 2 183635 T773 oascc.ConnectionManager.process Watcher org.apache.solr.common.cloud.ConnectionManager@2f3c95f8 name:ZooKeeperConnection Watcher:127.0.0.1:36178 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2 183636 T765 oascc.ConnectionManager.waitForConnected Client is connected to ZooKeeper [junit4] 2 183636 T765 oascc.SolrZkClient.createZkACLProvider Using default ZkACLProvider [junit4] 2 183637 T765 oascc.SolrZkClient.makePath makePath: /solr [junit4] 2 183646 T765 oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default ZkCredentialsProvider [junit4] 2 183646 T765 oascc.ConnectionManager.waitForConnected Waiting for client to connect to ZooKeeper [junit4] 2 183648 T776 oascc.ConnectionManager.process Watcher org.apache.solr.common.cloud.ConnectionManager@103fecbf name:ZooKeeperConnection Watcher:127.0.0.1:36178/solr got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2 183648 T765 oascc.ConnectionManager.waitForConnected Client is connected to ZooKeeper [junit4] 2 183649 T765 oascc.SolrZkClient.createZkACLProvider Using default ZkACLProvider [junit4] 2 183649 T765
[CI] Lucene 5x Linux 64 Test Only - Build # 51480 - Failure!
BUILD FAILURE Build URLhttp://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/51480/ Project:lucene_linux_java8_64_test_only Randomization: JDKEA8,local,heap[1024m],-server +UseG1GC +UseCompressedOops,sec manager on Date of build:Tue, 16 Jun 2015 07:37:32 +0200 Build duration:2 min 37 sec CHANGES No Changes BUILD ARTIFACTS checkout/lucene/build/core/test/temp/junit4-J0-20150616_073751_832.events checkout/lucene/build/core/test/temp/junit4-J1-20150616_073751_824.events checkout/lucene/build/core/test/temp/junit4-J2-20150616_073751_824.events checkout/lucene/build/core/test/temp/junit4-J3-20150616_073751_824.events checkout/lucene/build/core/test/temp/junit4-J4-20150616_073751_824.events checkout/lucene/build/core/test/temp/junit4-J5-20150616_073751_832.events checkout/lucene/build/core/test/temp/junit4-J6-20150616_073751_833.events checkout/lucene/build/core/test/temp/junit4-J7-20150616_073751_834.events FAILED JUNIT TESTS Name: org.apache.lucene.search Failed: 1 test(s), Passed: 781 test(s), Skipped: 2 test(s), Total: 784 test(s) Failed: org.apache.lucene.search.TestTimeLimitingCollector.testModifyResolution CONSOLE OUTPUT [...truncated 1770 lines...] [junit4] Tests with failures: [junit4] - org.apache.lucene.search.TestTimeLimitingCollector.testModifyResolution [junit4] [junit4] [junit4] JVM J0: 0.93 .. 124.25 = 123.32s [junit4] JVM J1: 0.93 .. 127.53 = 126.60s [junit4] JVM J2: 0.93 .. 137.49 = 136.56s [junit4] JVM J3: 0.69 .. 127.80 = 127.11s [junit4] JVM J4: 0.92 .. 124.82 = 123.90s [junit4] JVM J5: 0.93 .. 124.15 = 123.22s [junit4] JVM J6: 0.93 .. 124.43 = 123.49s [junit4] JVM J7: 0.95 .. 124.13 = 123.18s [junit4] Execution time total: 2 minutes 17 seconds [junit4] Tests summary: 401 suites, 3247 tests, 1 failure, 48 ignored (44 assumptions) BUILD FAILED /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:50: The following error occurred while executing this line: /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1444: The following error occurred while executing this line: /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:999: There were test failures: 401 suites, 3247 tests, 1 failure, 48 ignored (44 assumptions) Total time: 2 minutes 25 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results [description-setter] Description set: JDKEA8,local,heap[1024m],-server +UseG1GC +UseCompressedOops,sec manager on Email was triggered for: Failure - 1st Trigger Failure - Any was overridden by another trigger and will not send an email. Trigger Failure - Still was overridden by another trigger and will not send an email. Sending email for trigger: Failure - 1st - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6569) MultiFunction.anyExists - creating FunctionValues[] objects for every document
[
https://issues.apache.org/jira/browse/LUCENE-6569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved LUCENE-6569.
--
Resolution: Fixed
Fix Version/s: Trunk
5.3
Thanks!
MultiFunction.anyExists - creating FunctionValues[] objects for every document
--
Key: LUCENE-6569
URL: https://issues.apache.org/jira/browse/LUCENE-6569
Project: Lucene - Core
Issue Type: Improvement
Reporter: Jacob Graves
Assignee: Hoss Man
Priority: Minor
Labels: easyfix, newbie, patch, performance
Fix For: 5.3, Trunk
Attachments: SOLR-7618.patch, SOLR-7618.patch
Original Estimate: 2h
Remaining Estimate: 2h
In the class org.apache.lucene.queries.function.valuesource.MultiFunction
there is the following method signature (line 52)
public static boolean allExists(int doc, FunctionValues... values)
this method is called from the class
org.apache.lucene.queries.function.valuesource.DualFloatFunction (line 68)
public boolean exists(int doc) {
return MultiFunction.allExists(doc, aVals, bVals);
}
Because MultiFunction.allExists uses Java varargs syntax (...) a new
FunctionValues[] object will be created every time this call takes place.
The problem is that the call takes place in a document level function, which
means that it will create new objects in the heap for every document in the
query results.
for example if you use the following boost function (where ds and dc1 are
both TrieDateField)
bf=min(ms(ds,dc1),60480)
You will get extra objects created for each document in the result set, which
has a big impact on performance and memory usage if you are searching a large
result set.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6544) Geo3d cleanup: Regularize path and polygon construction, plus consider adding ellipsoid surface distance method
[ https://issues.apache.org/jira/browse/LUCENE-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14587432#comment-14587432 ] David Smiley commented on LUCENE-6544: -- FYI I did further edits and am now using ReviewBoard to share / collaborate: https://reviews.apache.org/r/35487/ Geo3d cleanup: Regularize path and polygon construction, plus consider adding ellipsoid surface distance method --- Key: LUCENE-6544 URL: https://issues.apache.org/jira/browse/LUCENE-6544 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: Karl Wright Attachments: LUCENE-6544.patch Geo3d's way of constructing polygons and paths differs in that in one case you construct points and the other you feed lat/lon values directly to the builder. Probably both should be supported for both kinds of entity. Also it may be useful to have an accurate point-point ellipsoidal distance function. This is expensive and would be an addition to the arc distance we currently compute. It would probably be called surface distance. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7688) JettyConfig cannot be used with extra filters
[ https://issues.apache.org/jira/browse/SOLR-7688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14587245#comment-14587245 ] Ishan Chattopadhyaya commented on SOLR-7688: I hit this issue during SOLR-7274, when I was trying out the authentication layer as a separate filter. Here's the patch which I put out then that fixed this issue, but I had abandoned this approach and folded in the extra servlet into the SDF CoreContainer: https://issues.apache.org/jira/secure/attachment/12733512/SOLR-7274.patch (JettySolrRunner and JettyConfig) Essentially, I changed the SortedMap to TreeMap. Also, I had to put in a hack to avoid double initialization of the extra filter that was added. JettyConfig cannot be used with extra filters - Key: SOLR-7688 URL: https://issues.apache.org/jira/browse/SOLR-7688 Project: Solr Issue Type: Improvement Affects Versions: 5.1 Reporter: Gregory Chanan Assignee: Gregory Chanan Attachments: SOLR-7688.patch, SOLR-7688.patch Before SOLR-7166, users could create a MiniSolrCloudCluster with extra filters by specifying their own SortedMap and comparator (since Class? extends Filter is not comparable). JettyConfigs allow you to specify filter classes to add, but they don't work because JettyConfigs manages its own filter map using TreeMap. Thus, there is no way to specify a comparator and it fails at runtime with Class cannot be cast to java.lang.comparable. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 876 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/876/ 3 tests failed. REGRESSION: org.apache.solr.handler.TestReplicationHandler.doTestReplicateAfterCoreReload Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([C4309B00FAFA99C5]:0) FAILED: junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandler Error Message: Suite timeout exceeded (= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (= 720 msec). at __randomizedtesting.SeedInfo.seed([C4309B00FAFA99C5]:0) FAILED: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=12608, name=collection3, state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=12608, name=collection3, state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest] Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:40461: collection already exists: awholynewstresscollection_collection3_1 at __randomizedtesting.SeedInfo.seed([C4309B00FAFA99C5]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:235) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:227) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1570) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1591) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:895) Build Log: [...truncated 10885 lines...] [junit4] Suite: org.apache.solr.cloud.CollectionsAPIDistributedZkTest [junit4] 2 Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/solr/build/solr-core/test/J0/temp/solr.cloud.CollectionsAPIDistributedZkTest_C4309B00FAFA99C5-001/init-core-data-001 [junit4] 2 1093796 INFO (SUITE-CollectionsAPIDistributedZkTest-seed#[C4309B00FAFA99C5]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) [junit4] 2 1093797 INFO (SUITE-CollectionsAPIDistributedZkTest-seed#[C4309B00FAFA99C5]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: / [junit4] 2 1093801 INFO (TEST-CollectionsAPIDistributedZkTest.test-seed#[C4309B00FAFA99C5]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2 1093801 INFO (Thread-8528) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2 1093801 INFO (Thread-8528) [] o.a.s.c.ZkTestServer Starting server [junit4] 2 1093901 INFO (TEST-CollectionsAPIDistributedZkTest.test-seed#[C4309B00FAFA99C5]) [] o.a.s.c.ZkTestServer start zk server on port:49440 [junit4] 2 1093901 INFO (TEST-CollectionsAPIDistributedZkTest.test-seed#[C4309B00FAFA99C5]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2 1093902 INFO (TEST-CollectionsAPIDistributedZkTest.test-seed#[C4309B00FAFA99C5]) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2 1093904 INFO (zkCallback-688-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@16f0eb2e name:ZooKeeperConnection Watcher:127.0.0.1:49440 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2 1093905 INFO (TEST-CollectionsAPIDistributedZkTest.test-seed#[C4309B00FAFA99C5]) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2 1093905 INFO (TEST-CollectionsAPIDistributedZkTest.test-seed#[C4309B00FAFA99C5]) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2 1093905 INFO (TEST-CollectionsAPIDistributedZkTest.test-seed#[C4309B00FAFA99C5]) [] o.a.s.c.c.SolrZkClient makePath: /solr [junit4] 2 1093908 WARN
[jira] [Commented] (LUCENE-6569) MultiFunction.anyExists - creating FunctionValues[] objects for every document
[
https://issues.apache.org/jira/browse/LUCENE-6569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14587268#comment-14587268
]
ASF subversion and git services commented on LUCENE-6569:
-
Commit 1685689 from hoss...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1685689 ]
LUCENE-6569: Optimize MultiFunction.anyExists and allExists to eliminate
excessive array creation in common 2 argument usage (merge r1685687)
MultiFunction.anyExists - creating FunctionValues[] objects for every document
--
Key: LUCENE-6569
URL: https://issues.apache.org/jira/browse/LUCENE-6569
Project: Lucene - Core
Issue Type: Improvement
Reporter: Jacob Graves
Assignee: Hoss Man
Priority: Minor
Labels: easyfix, newbie, patch, performance
Attachments: SOLR-7618.patch, SOLR-7618.patch
Original Estimate: 2h
Remaining Estimate: 2h
In the class org.apache.lucene.queries.function.valuesource.MultiFunction
there is the following method signature (line 52)
public static boolean allExists(int doc, FunctionValues... values)
this method is called from the class
org.apache.lucene.queries.function.valuesource.DualFloatFunction (line 68)
public boolean exists(int doc) {
return MultiFunction.allExists(doc, aVals, bVals);
}
Because MultiFunction.allExists uses Java varargs syntax (...) a new
FunctionValues[] object will be created every time this call takes place.
The problem is that the call takes place in a document level function, which
means that it will create new objects in the heap for every document in the
query results.
for example if you use the following boost function (where ds and dc1 are
both TrieDateField)
bf=min(ms(ds,dc1),60480)
You will get extra objects created for each document in the result set, which
has a big impact on performance and memory usage if you are searching a large
result set.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7667) If more cores are loaded at startup than the transient core size, cores become unavailable.
[ https://issues.apache.org/jira/browse/SOLR-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-7667: - Attachment: SOLR-7667-test-fails.patch Failure for this on 4.10.3. Test case succeeds on 5.x and trunk If more cores are loaded at startup than the transient core size, cores become unavailable. --- Key: SOLR-7667 URL: https://issues.apache.org/jira/browse/SOLR-7667 Project: Solr Issue Type: Bug Affects Versions: 5.2.1, Trunk Reporter: Erick Erickson Assignee: Erick Erickson Attachments: CoreContainer.java, SOLR-7667-test-fails.patch, SOLR-7667-with-CoreAdmin-create-fail.patch, SOLR-7667-with-CoreAdmin-create-fail.patch, SOLR-7667.patch, SOLR-7667.patch Edwin Lee from the user's list caught this, the original post is titled loadOnStartup transientCoreSize BUG Report on CoreContainer.java Nice catch Edwin! More details to follow: -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7667) If more cores are loaded at startup than the transient core size, cores become unavailable.
[ https://issues.apache.org/jira/browse/SOLR-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14587488#comment-14587488 ] Erick Erickson commented on SOLR-7667: -- I can reproduce this on 4.10, but not on 5x or trunk. Part of deprecating the old solr.xml format where cores were defined in solr.xml involved lots of simplification in the whole core loading/discovery process. I suspect that this problem went away with that simplification, although I also think this was serendipitous. I'll attached a test case that fails in 4.10 and succeeds in both 5x and trunk and I'll change the affected versions to 4.10.3 (I suspect this has been around forever so probably affects releases much earlier than 4.10). The failure mode in these tests is it hangs forever, which is what I believe you're reporting. There are really no plans to release any new 4.10 versions at present, and this the first report of this. So I'm afraid there's little chance of releasing a fix specifically for 4.10 and it's unnecessary (apparently) for 5.x+ So if you really need this, I think you'll have to patch it locally I'm afraid. If more cores are loaded at startup than the transient core size, cores become unavailable. --- Key: SOLR-7667 URL: https://issues.apache.org/jira/browse/SOLR-7667 Project: Solr Issue Type: Bug Affects Versions: 5.2.1, Trunk Reporter: Erick Erickson Assignee: Erick Erickson Attachments: CoreContainer.java, SOLR-7667-with-CoreAdmin-create-fail.patch, SOLR-7667-with-CoreAdmin-create-fail.patch, SOLR-7667.patch, SOLR-7667.patch Edwin Lee from the user's list caught this, the original post is titled loadOnStartup transientCoreSize BUG Report on CoreContainer.java Nice catch Edwin! More details to follow: -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-7667) If more cores are loaded at startup than the transient core size, cores become unavailable.
[ https://issues.apache.org/jira/browse/SOLR-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14587488#comment-14587488 ] Erick Erickson edited comment on SOLR-7667 at 6/16/15 5:10 AM: --- I can reproduce this on 4.10, but not on 5x or trunk. Part of deprecating the old solr.xml format where cores were defined in solr.xml involved lots of simplification in the whole core loading/discovery process. I suspect that this problem went away with that simplification, although I also think this was serendipitous. I'll attached a test case that fails in 4.10 and succeeds in both 5x and trunk and I'll change the affected versions to 4.10.3 (I suspect this has been around forever so probably affects releases much earlier than 4.10). The failure mode in these tests is it hangs forever, which is what I believe you're reporting. There are really no plans to release any new 4.10 versions at present, and this the first report of this. So I'm afraid there's little chance of releasing a fix specifically for 4.10 and it's unnecessary (apparently) for 5.x+ So if you really need this, I think you'll have to patch it locally I'm afraid, unless we can show it happening on 5.+. was (Author: erickerickson): I can reproduce this on 4.10, but not on 5x or trunk. Part of deprecating the old solr.xml format where cores were defined in solr.xml involved lots of simplification in the whole core loading/discovery process. I suspect that this problem went away with that simplification, although I also think this was serendipitous. I'll attached a test case that fails in 4.10 and succeeds in both 5x and trunk and I'll change the affected versions to 4.10.3 (I suspect this has been around forever so probably affects releases much earlier than 4.10). The failure mode in these tests is it hangs forever, which is what I believe you're reporting. There are really no plans to release any new 4.10 versions at present, and this the first report of this. So I'm afraid there's little chance of releasing a fix specifically for 4.10 and it's unnecessary (apparently) for 5.x+ So if you really need this, I think you'll have to patch it locally I'm afraid. If more cores are loaded at startup than the transient core size, cores become unavailable. --- Key: SOLR-7667 URL: https://issues.apache.org/jira/browse/SOLR-7667 Project: Solr Issue Type: Bug Affects Versions: 5.2.1, Trunk Reporter: Erick Erickson Assignee: Erick Erickson Attachments: CoreContainer.java, SOLR-7667-with-CoreAdmin-create-fail.patch, SOLR-7667-with-CoreAdmin-create-fail.patch, SOLR-7667.patch, SOLR-7667.patch Edwin Lee from the user's list caught this, the original post is titled loadOnStartup transientCoreSize BUG Report on CoreContainer.java Nice catch Edwin! More details to follow: -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-7688) JettyConfig cannot be used with extra filters
[ https://issues.apache.org/jira/browse/SOLR-7688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14587245#comment-14587245 ] Ishan Chattopadhyaya edited comment on SOLR-7688 at 6/16/15 12:56 AM: -- I hit this issue during SOLR-7274, when I was trying out the authentication layer as a separate filter, but I had abandoned this approach and folded in the extra servlet into the SDF CoreContainer. Here's the patch which I put out then that fixed this issue: https://issues.apache.org/jira/secure/attachment/12733512/SOLR-7274.patch (JettySolrRunner and JettyConfig) Essentially, I changed the SortedMap to LinkedHashMap. Also, I had to put in a hack to avoid double initialization of the extra filter that was added. was (Author: ichattopadhyaya): I hit this issue during SOLR-7274, when I was trying out the authentication layer as a separate filter. Here's the patch which I put out then that fixed this issue, but I had abandoned this approach and folded in the extra servlet into the SDF CoreContainer: https://issues.apache.org/jira/secure/attachment/12733512/SOLR-7274.patch (JettySolrRunner and JettyConfig) Essentially, I changed the SortedMap to LinkedHashMap. Also, I had to put in a hack to avoid double initialization of the extra filter that was added. JettyConfig cannot be used with extra filters - Key: SOLR-7688 URL: https://issues.apache.org/jira/browse/SOLR-7688 Project: Solr Issue Type: Improvement Affects Versions: 5.1 Reporter: Gregory Chanan Assignee: Gregory Chanan Attachments: SOLR-7688.patch, SOLR-7688.patch Before SOLR-7166, users could create a MiniSolrCloudCluster with extra filters by specifying their own SortedMap and comparator (since Class? extends Filter is not comparable). JettyConfigs allow you to specify filter classes to add, but they don't work because JettyConfigs manages its own filter map using TreeMap. Thus, there is no way to specify a comparator and it fails at runtime with Class cannot be cast to java.lang.comparable. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7688) JettyConfig cannot be used with extra filters
[ https://issues.apache.org/jira/browse/SOLR-7688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14587270#comment-14587270 ] Ishan Chattopadhyaya commented on SOLR-7688: bq. My patch changes it to a LinkedHashMap, adds a test, and also fixes up some params. +1 bq. The double initialization issue looks interesting, thanks for pointing that out. Assuming that is the case, though, the debugFilter is also double initialized and should be handled in a similar way? Seems like that should be handled in a separate issue. Sure, that makes sense. I'll try to reproduce again and open a new issue for that. JettyConfig cannot be used with extra filters - Key: SOLR-7688 URL: https://issues.apache.org/jira/browse/SOLR-7688 Project: Solr Issue Type: Improvement Affects Versions: 5.1 Reporter: Gregory Chanan Assignee: Gregory Chanan Attachments: SOLR-7688.patch, SOLR-7688.patch Before SOLR-7166, users could create a MiniSolrCloudCluster with extra filters by specifying their own SortedMap and comparator (since Class? extends Filter is not comparable). JettyConfigs allow you to specify filter classes to add, but they don't work because JettyConfigs manages its own filter map using TreeMap. Thus, there is no way to specify a comparator and it fails at runtime with Class cannot be cast to java.lang.comparable. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7667) If more cores are loaded at startup than the transient core size, cores become unavailable.
[ https://issues.apache.org/jira/browse/SOLR-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-7667: - Assignee: (was: Erick Erickson) If more cores are loaded at startup than the transient core size, cores become unavailable. --- Key: SOLR-7667 URL: https://issues.apache.org/jira/browse/SOLR-7667 Project: Solr Issue Type: Bug Affects Versions: 4.10.3 Reporter: Erick Erickson Attachments: CoreContainer.java, SOLR-7667-test-fails.patch, SOLR-7667-with-CoreAdmin-create-fail.patch, SOLR-7667-with-CoreAdmin-create-fail.patch, SOLR-7667.patch, SOLR-7667.patch Edwin Lee from the user's list caught this, the original post is titled loadOnStartup transientCoreSize BUG Report on CoreContainer.java Nice catch Edwin! More details to follow: -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7667) If more cores are loaded at startup than the transient core size, cores become unavailable.
[ https://issues.apache.org/jira/browse/SOLR-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-7667: - Affects Version/s: (was: 5.2.1) (was: Trunk) 4.10.3 If more cores are loaded at startup than the transient core size, cores become unavailable. --- Key: SOLR-7667 URL: https://issues.apache.org/jira/browse/SOLR-7667 Project: Solr Issue Type: Bug Affects Versions: 4.10.3 Reporter: Erick Erickson Attachments: CoreContainer.java, SOLR-7667-test-fails.patch, SOLR-7667-with-CoreAdmin-create-fail.patch, SOLR-7667-with-CoreAdmin-create-fail.patch, SOLR-7667.patch, SOLR-7667.patch Edwin Lee from the user's list caught this, the original post is titled loadOnStartup transientCoreSize BUG Report on CoreContainer.java Nice catch Edwin! More details to follow: -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-7667) If more cores are loaded at startup than the transient core size, cores become unavailable.
[ https://issues.apache.org/jira/browse/SOLR-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14587488#comment-14587488 ] Erick Erickson edited comment on SOLR-7667 at 6/16/15 5:13 AM: --- I can reproduce this on 4.10, but not on 5x or trunk. Part of deprecating the old solr.xml format where cores were defined in solr.xml involved lots of simplification in the whole core loading/discovery process. I suspect that this problem went away with that simplification, although I also think this was serendipitous. I'll attached a test case that fails in 4.10 and succeeds in both 5x and trunk and I'll change the affected versions to 4.10.3 (I suspect this has been around forever so probably affects releases much earlier than 4.10). The failure mode in these tests is it hangs forever, which is what I believe you're reporting. There are really no plans to release any new 4.10 versions at present, and this the first report of this. So I'm afraid there's little chance of releasing a fix specifically for 4.10 and it's unnecessary (apparently) for 5.x+ So if you really need this, I think you'll have to patch it locally I'm afraid, unless we can show it happening on 5.x+. was (Author: erickerickson): I can reproduce this on 4.10, but not on 5x or trunk. Part of deprecating the old solr.xml format where cores were defined in solr.xml involved lots of simplification in the whole core loading/discovery process. I suspect that this problem went away with that simplification, although I also think this was serendipitous. I'll attached a test case that fails in 4.10 and succeeds in both 5x and trunk and I'll change the affected versions to 4.10.3 (I suspect this has been around forever so probably affects releases much earlier than 4.10). The failure mode in these tests is it hangs forever, which is what I believe you're reporting. There are really no plans to release any new 4.10 versions at present, and this the first report of this. So I'm afraid there's little chance of releasing a fix specifically for 4.10 and it's unnecessary (apparently) for 5.x+ So if you really need this, I think you'll have to patch it locally I'm afraid, unless we can show it happening on 5.+. If more cores are loaded at startup than the transient core size, cores become unavailable. --- Key: SOLR-7667 URL: https://issues.apache.org/jira/browse/SOLR-7667 Project: Solr Issue Type: Bug Affects Versions: 4.10.3 Reporter: Erick Erickson Attachments: CoreContainer.java, SOLR-7667-test-fails.patch, SOLR-7667-with-CoreAdmin-create-fail.patch, SOLR-7667-with-CoreAdmin-create-fail.patch, SOLR-7667.patch, SOLR-7667.patch Edwin Lee from the user's list caught this, the original post is titled loadOnStartup transientCoreSize BUG Report on CoreContainer.java Nice catch Edwin! More details to follow: -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6564) Normalize date format for IW in unit tests
[
https://issues.apache.org/jira/browse/LUCENE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586247#comment-14586247
]
Uwe Schindler edited comment on LUCENE-6564 at 6/15/15 4:09 PM:
Because of this, I would suggest to keep everything like it is and just
misuse {{java.nio.file.attribute.FileTime}} for formatting as ISO-8601
timestamp. So patch is quite easy...
was (Author: thetaphi):
Because of this, I would suggest to keep everything like it is and just
misuse {{java.nio.file.attribute.FileTime}} for formatting as IS-8601
timestamp. So patch is quite easy...
Normalize date format for IW in unit tests
--
Key: LUCENE-6564
URL: https://issues.apache.org/jira/browse/LUCENE-6564
Project: Lucene - Core
Issue Type: Improvement
Components: general/test
Reporter: Ramkumar Aiyengar
Assignee: Ramkumar Aiyengar
Priority: Minor
Fix For: 5.3
Attachments: LUCENE-6564.patch, LUCENE-6564.patch
Noticed while debugging some IW output in an unit test that milliseconds were
not output in the date, changed this to reuse the date format used by
{{PrintStreamInfoStream}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7344) Allow Jetty thread pool limits while still avoiding distributed deadlock.
[ https://issues.apache.org/jira/browse/SOLR-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586314#comment-14586314 ] Hrishikesh Gadre commented on SOLR-7344: The current implementation of distributed querying is to block the thread handling top-level request until all the sub requests are complete. Have we thought about using fork-join framework (along with servlet 3 api) for this? At high-level, the idea would be to start an async servlet context and submit a scatter-gather task to an internal thread-pool (defined in HttpShardHandlerFactory). The gather phase would merge the results and reply back to the client (i.e. it will complete the async request). Because the gather phase is executed after all the sub-requests are complete (either success/failure), it will not occupy the thread for while the sub-requests are in progress. I think this will ensure to avoid the deadlock scenarios as well. If distributed querying is the main cause of deadlocks, I wonder if this will fix the problem more directly? Allow Jetty thread pool limits while still avoiding distributed deadlock. - Key: SOLR-7344 URL: https://issues.apache.org/jira/browse/SOLR-7344 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Attachments: SOLR-7344.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7344) Allow Jetty thread pool limits while still avoiding distributed deadlock.
[ https://issues.apache.org/jira/browse/SOLR-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586331#comment-14586331 ] Yonik Seeley commented on SOLR-7344: bq. Right, rather than having a solution which solves this issue for N levels (N 2), I am curious if it's too restrictive to say that solutions should try to work with N = 2? I think that's antithetical to streaming (i.e. it requires a multi-step thing be done in batches). Allow Jetty thread pool limits while still avoiding distributed deadlock. - Key: SOLR-7344 URL: https://issues.apache.org/jira/browse/SOLR-7344 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Attachments: SOLR-7344.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-7344) Allow Jetty thread pool limits while still avoiding distributed deadlock.
[ https://issues.apache.org/jira/browse/SOLR-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586324#comment-14586324 ] Yonik Seeley edited comment on SOLR-7344 at 6/15/15 5:17 PM: - Dude (mark), you're just being obstinate now. Relying on timeouts to break distributed deadlock is horrible and will cause random unrelated requests to also fail. We need a *separate* queue with a high limit (or a higher limit) for types of requests that can cause another request to be fired off. was (Author: ysee...@gmail.com): Dude, you're just being obstinate now. Relying on timeouts to break distributed deadlock is horrible and will cause random unrelated requests to also fail. We need a *separate* queue with a high limit (or a higher limit) for types of requests that can cause another request to be fired off. Allow Jetty thread pool limits while still avoiding distributed deadlock. - Key: SOLR-7344 URL: https://issues.apache.org/jira/browse/SOLR-7344 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Attachments: SOLR-7344.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6564) Normalize date format for IW in unit tests
[
https://issues.apache.org/jira/browse/LUCENE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586352#comment-14586352
]
Uwe Schindler commented on LUCENE-6564:
---
By the way: In Lucene Trunk we can use the new Java 8 Datetime API (Jodatime
fork) to get an ISO datestamp without misusing an API. We should maybe use the
new API in Java 8 to implement getTimeStamp():
{{LocalDateTime.now().toString()}} (in local time), or by giving a timezone.
Normalize date format for IW in unit tests
--
Key: LUCENE-6564
URL: https://issues.apache.org/jira/browse/LUCENE-6564
Project: Lucene - Core
Issue Type: Improvement
Components: general/test
Reporter: Ramkumar Aiyengar
Assignee: Ramkumar Aiyengar
Priority: Minor
Fix For: 5.3
Attachments: LUCENE-6564.patch, LUCENE-6564.patch, LUCENE-6564.patch
Noticed while debugging some IW output in an unit test that milliseconds were
not output in the date, changed this to reuse the date format used by
{{PrintStreamInfoStream}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7344) Allow Jetty thread pool limits while still avoiding distributed deadlock.
[ https://issues.apache.org/jira/browse/SOLR-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586357#comment-14586357 ] Ramkumar Aiyengar commented on SOLR-7344: - May be if the concern is that Streaming fails in an unpredictable manner, is there a way to restrict the amount of recursion possible? That way, the user will be forced to decide the amount of recursion and crank up the number of threads (or make both unbounded if they don't care). Then the defaults for both the number of threads and the number of levels of recursion can be low.. Allow Jetty thread pool limits while still avoiding distributed deadlock. - Key: SOLR-7344 URL: https://issues.apache.org/jira/browse/SOLR-7344 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Attachments: SOLR-7344.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7344) Allow Jetty thread pool limits while still avoiding distributed deadlock.
[ https://issues.apache.org/jira/browse/SOLR-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586375#comment-14586375 ] Mark Miller commented on SOLR-7344: --- bq. . That must be a different queue than the queue that can be called recursively. I never said this should not be a different queue or that it couldn't have a higher limit than the other queues. I'm not sure you read what I wrote. Allow Jetty thread pool limits while still avoiding distributed deadlock. - Key: SOLR-7344 URL: https://issues.apache.org/jira/browse/SOLR-7344 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Attachments: SOLR-7344.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6564) Normalize date format for IW in unit tests
[
https://issues.apache.org/jira/browse/LUCENE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586421#comment-14586421
]
Michael McCandless commented on LUCENE-6564:
+1 to [~thetaphi]'s patch! But can you add a comment explaining why we abuse
the FileTime API?
Separately it's kinda cool that TestIndexWriter makes at least 108 IW
instances...
Normalize date format for IW in unit tests
--
Key: LUCENE-6564
URL: https://issues.apache.org/jira/browse/LUCENE-6564
Project: Lucene - Core
Issue Type: Improvement
Components: general/test
Reporter: Ramkumar Aiyengar
Assignee: Ramkumar Aiyengar
Priority: Minor
Fix For: 5.3
Attachments: LUCENE-6564.patch, LUCENE-6564.patch, LUCENE-6564.patch
Noticed while debugging some IW output in an unit test that milliseconds were
not output in the date, changed this to reuse the date format used by
{{PrintStreamInfoStream}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6234) Scoring modes for query time join
[
https://issues.apache.org/jira/browse/SOLR-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586428#comment-14586428
]
Neeraj Lajpal commented on SOLR-6234:
-
Thanks a lot Ryan.
This solved my problem.
But, needed to change a couple of things, enclose the value of _query_ in
double quotes and remove jq.
Without these changes it was not showing any result.
I executed this query:
important_category:322^4 _query_:{!scorejoin from=_root_ to=id score=avg
multiVals=false}(brandid:1398^4 OR brandid:237^4.5)
debug: {
rawquerystring: important_cat:322^4 _query_:\{!scorejoin from=_root_
to=id score=avg multiVals=false}(brandid:1398^4 OR brandid:237^4.5)\,
querystring: important_cat:322^4 _query_:\{!scorejoin from=_root_ to=id
score=avg multiVals=false}(brandid:1398^4 OR brandid:237^4.5)\,
parsedquery: important_cat:322^4.0 SameCoreJoinQuery(SameCoreJoinQuery
[fromQuery=brandid:1398^4.0 brandid:237^4.5, fromField=_root_, toField=id,
scoreMode=Avg, boost=1.0, multiVals=false])
}
Everything looks fine.
Thanks again.
Scoring modes for query time join
--
Key: SOLR-6234
URL: https://issues.apache.org/jira/browse/SOLR-6234
Project: Solr
Issue Type: New Feature
Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
Labels: features, patch, test
Fix For: 5.3
Attachments: SOLR-6234.patch, SOLR-6234.patch
it adds {{scorejoin}} query parser which calls Lucene's JoinUtil underneath.
It supports:
- {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
- {{score=none}} is *default*, eg if you *omit* this localparam
- supports {{b=100}} param to pass {{Query.setBoost()}}.
- {{multiVals=true|false}} is introduced
- there is a test coverage for cross core join case.
- so far it joins string and multivalue string fields (Sorted, SortedSet,
Binary), but not Numerics DVs. follow-up LUCENE-5868
-there was a bug in cross core join, however there is a workaround for it-
it's fixed in Dec'14 patch.
Note: the development of this patch was sponsored by an anonymous contributor
and approved for release under Apache License.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6564) Normalize date format for IW in unit tests
[
https://issues.apache.org/jira/browse/LUCENE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-6564:
--
Attachment: LUCENE-6564-trunk.patch
LUCENE-6564-5x.patch
Here patch for 5.x and trunk. In trunk I use the Java 8 Datetime API with
Instant.now().toString(), in 5.x I added a comment why misusing FileTime.
Please have in mind that the output is always in UTC. In Java 8 we could use
local time, too, but this would make it identical for both cases. In addition,
while running tests, we randomize the timezone, so the local date is bit
useless...
Any comments?
Normalize date format for IW in unit tests
--
Key: LUCENE-6564
URL: https://issues.apache.org/jira/browse/LUCENE-6564
Project: Lucene - Core
Issue Type: Improvement
Components: general/test
Reporter: Ramkumar Aiyengar
Assignee: Ramkumar Aiyengar
Priority: Minor
Fix For: 5.3
Attachments: LUCENE-6564-5x.patch, LUCENE-6564-trunk.patch,
LUCENE-6564.patch, LUCENE-6564.patch, LUCENE-6564.patch
Noticed while debugging some IW output in an unit test that milliseconds were
not output in the date, changed this to reuse the date format used by
{{PrintStreamInfoStream}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5302) Analytics Component
[ https://issues.apache.org/jira/browse/SOLR-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586504#comment-14586504 ] Levi Page commented on SOLR-5302: - Does anyone have copies or access to the extended documentation that is referenced to the PDF? The PDF points to several links on the Bloomberg CMS site that are no longer active. I am trying to use this component and would love to get my hands on it. Analytics Component --- Key: SOLR-5302 URL: https://issues.apache.org/jira/browse/SOLR-5302 Project: Solr Issue Type: New Feature Reporter: Steven Bower Assignee: Erick Erickson Fix For: 5.0, Trunk Attachments: SOLR-5302.patch, SOLR-5302.patch, SOLR-5302.patch, SOLR-5302.patch, SOLR-5302_contrib.patch, Search Analytics Component.pdf, Statistical Expressions.pdf, solr_analytics-2013.10.04-2.patch This ticket is to track a replacement for the StatsComponent. The AnalyticsComponent supports the following features: * All functionality of StatsComponent (SOLR-4499) * Field Faceting (SOLR-3435) ** Support for limit ** Sorting (bucket name or any stat in the bucket ** Support for offset * Range Faceting ** Supports all options of standard range faceting * Query Faceting (SOLR-2925) * Ability to use overall/field facet statistics as input to range/query faceting (ie calc min/max date and then facet over that range * Support for more complex aggregate/mapping operations (SOLR-1622) ** Aggregations: min, max, sum, sum-of-square, count, missing, stddev, mean, median, percentiles ** Operations: negation, abs, add, multiply, divide, power, log, date math, string reversal, string concat ** Easily pluggable framework to add additional operations * New / cleaner output format Outstanding Issues: * Multi-value field support for stats (supported for faceting) * Multi-shard support (may not be possible for some operations, eg median) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7685) Enable the partitioning logic with appropriate defaults
Hrishikesh Gadre created SOLR-7685: -- Summary: Enable the partitioning logic with appropriate defaults Key: SOLR-7685 URL: https://issues.apache.org/jira/browse/SOLR-7685 Project: Solr Issue Type: Sub-task Reporter: Hrishikesh Gadre This task tracks the performance testing this feature and to figure out appropriate default configuration parameters for Jetty thread-pool. Once these defaults are identified, this feature should be enabled. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7683) Introduce support to identify Solr internal request types
[ https://issues.apache.org/jira/browse/SOLR-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586474#comment-14586474 ] Yonik Seeley commented on SOLR-7683: One TL;DR upshot of the discussion in SOLR-7344 is that we need a queue other than Internal_Querying for the Streaming API and friends (Expressions, parallel SQL) since they can have 2 or more levels of requests instead of the standard 2 for distributed search. Introduce support to identify Solr internal request types - Key: SOLR-7683 URL: https://issues.apache.org/jira/browse/SOLR-7683 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Hrishikesh Gadre SOLR-7344 is introducing support to partition the Jetty worker pool to enforce the number of concurrent requests for various types (e.g. Internal_Querying, Internal_Indexing, External etc.). For this we need to identify requests sent between Solr servers and their types (i.e. Querying/Indexing etc.). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6564) Normalize date format for IW in unit tests
[
https://issues.apache.org/jira/browse/LUCENE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586397#comment-14586397
]
Mark Miller commented on LUCENE-6564:
-
I would love to calculate the developer time / cost ratio of this ticket :)
Gotta love Open Source.
Normalize date format for IW in unit tests
--
Key: LUCENE-6564
URL: https://issues.apache.org/jira/browse/LUCENE-6564
Project: Lucene - Core
Issue Type: Improvement
Components: general/test
Reporter: Ramkumar Aiyengar
Assignee: Ramkumar Aiyengar
Priority: Minor
Fix For: 5.3
Attachments: LUCENE-6564.patch, LUCENE-6564.patch, LUCENE-6564.patch
Noticed while debugging some IW output in an unit test that milliseconds were
not output in the date, changed this to reuse the date format used by
{{PrintStreamInfoStream}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7344) Allow Jetty thread pool limits while still avoiding distributed deadlock.
[ https://issues.apache.org/jira/browse/SOLR-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586409#comment-14586409 ] Mark Miller commented on SOLR-7344: --- bq. veto later if necessary to prevent a bad default from being committed. We will toil under your veto threat and see if you end up approving of the consensus defaults we eventually work out. Nice 'dude'. Allow Jetty thread pool limits while still avoiding distributed deadlock. - Key: SOLR-7344 URL: https://issues.apache.org/jira/browse/SOLR-7344 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Attachments: SOLR-7344.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7344) Allow Jetty thread pool limits while still avoiding distributed deadlock.
[ https://issues.apache.org/jira/browse/SOLR-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586416#comment-14586416 ] Yonik Seeley commented on SOLR-7344: I was going to respond to your It's not the same trouble as today!, but it's just another nit. Instead of acknowledging how it fundamentally is the same issue, you find something a nit to disagree with to keep up the argument. Too much argument for me... I'm done. Allow Jetty thread pool limits while still avoiding distributed deadlock. - Key: SOLR-7344 URL: https://issues.apache.org/jira/browse/SOLR-7344 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Attachments: SOLR-7344.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7684) Introduce Jetty thread-pool partitioning logic for Solr
Hrishikesh Gadre created SOLR-7684: -- Summary: Introduce Jetty thread-pool partitioning logic for Solr Key: SOLR-7684 URL: https://issues.apache.org/jira/browse/SOLR-7684 Project: Solr Issue Type: Sub-task Reporter: Hrishikesh Gadre This issue is to track the development of - Servlet 3 Filter implementation for thread-pool partitioning - Solr specific policy implementing the partitioning logic -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6234) Scoring modes for query time join
[
https://issues.apache.org/jira/browse/SOLR-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586427#comment-14586427
]
Neeraj Lajpal commented on SOLR-6234:
-
Thanks a lot Ryan.
This solved my problem.
But, needed to change a couple of things, enclose the value of _query_ in
double quotes and remove jq.
Without these changes it was not showing any result.
I executed this query:
important_category:322^4 _query_:{!scorejoin from=_root_ to=id score=avg
multiVals=false}(brandid:1398^4 OR brandid:237^4.5)
debug: {
rawquerystring: important_cat:322^4 _query_:\{!scorejoin from=_root_
to=id score=avg multiVals=false}(brandid:1398^4 OR brandid:237^4.5)\,
querystring: important_cat:322^4 _query_:\{!scorejoin from=_root_ to=id
score=avg multiVals=false}(brandid:1398^4 OR brandid:237^4.5)\,
parsedquery: important_cat:322^4.0 SameCoreJoinQuery(SameCoreJoinQuery
[fromQuery=brandid:1398^4.0 brandid:237^4.5, fromField=_root_, toField=id,
scoreMode=Avg, boost=1.0, multiVals=false])
}
Everything looks fine.
Thanks again.
Scoring modes for query time join
--
Key: SOLR-6234
URL: https://issues.apache.org/jira/browse/SOLR-6234
Project: Solr
Issue Type: New Feature
Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
Labels: features, patch, test
Fix For: 5.3
Attachments: SOLR-6234.patch, SOLR-6234.patch
it adds {{scorejoin}} query parser which calls Lucene's JoinUtil underneath.
It supports:
- {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
- {{score=none}} is *default*, eg if you *omit* this localparam
- supports {{b=100}} param to pass {{Query.setBoost()}}.
- {{multiVals=true|false}} is introduced
- there is a test coverage for cross core join case.
- so far it joins string and multivalue string fields (Sorted, SortedSet,
Binary), but not Numerics DVs. follow-up LUCENE-5868
-there was a bug in cross core join, however there is a workaround for it-
it's fixed in Dec'14 patch.
Note: the development of this patch was sponsored by an anonymous contributor
and approved for release under Apache License.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7344) Allow Jetty thread pool limits while still avoiding distributed deadlock.
[ https://issues.apache.org/jira/browse/SOLR-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586424#comment-14586424 ] Mark Miller commented on SOLR-7344: --- Good! Perhaps we can get a patch before you veto it then. The point is it is all nits! The strategy works, the numbers can be worked out, I don't agree they have to be so high, it's all pretty simple. You are good at making some of these issues very hard to get off the ground. Allow Jetty thread pool limits while still avoiding distributed deadlock. - Key: SOLR-7344 URL: https://issues.apache.org/jira/browse/SOLR-7344 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Attachments: SOLR-7344.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
