Does the cached QueryWrapperFilter in CachedFilterBuilder help improve performance?
In CachedFilterBuilder, there are 1) (key=query, value=QueryWrapperFilter) 2) (key=filter, value = CachingWrapperFilter). For cached CachingWrapperFilter, I can understand how it caches since the underlying docIdSet is cached if it is cacheable, or is cloned if it is not cacheable. Thus, the performance can be improved. However, for QueryWrapperFilter, I am wondering how it can help performance. It does not cache the underlying docIdSet. Thus, each time its getDocIdSet is called, the entire scorer is built from scratch, right (except the underlying posting list are cached somehow)? Can anybody help me with this ? thanks! hao
[jira] [Updated] (LUCENE-5306) Add CompositeReader Support to DocumentExpressionDictionary
[ https://issues.apache.org/jira/browse/LUCENE-5306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Areek Zillur updated LUCENE-5306: - Attachment: LUCENE-5306.patch Patch (minor change): - additional check to ensure that the leave size of the reader is not zero. > Add CompositeReader Support to DocumentExpressionDictionary > --- > > Key: LUCENE-5306 > URL: https://issues.apache.org/jira/browse/LUCENE-5306 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Areek Zillur > Attachments: LUCENE-5306.patch, LUCENE-5306.patch > > > Currently the DocumentExpressionDictionary does not have support for > CompositeReader. It would be nice to add that support. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5399) Improve DebugComponent for distributed requests
[
https://issues.apache.org/jira/browse/SOLR-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomás Fernández Löbbe updated SOLR-5399:
Attachment: SOLR-5399.patch
Here is an raw patch with the idea. It still doesn't have any unit tests and I
haven't tested it much with SolrCloud
> Improve DebugComponent for distributed requests
> ---
>
> Key: SOLR-5399
> URL: https://issues.apache.org/jira/browse/SOLR-5399
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 5.0
>Reporter: Tomás Fernández Löbbe
> Attachments: SOLR-5399.patch
>
>
> I'm working on extending the DebugComponent for adding some useful
> information to be able to track distributed requests better. I'm adding two
> different things, first, the request can generate a "request ID" that will be
> printed in the logs for the main query and all the different internal
> requests to the different shards. This should make it easier to find the
> different parts of a single user request in the logs. It would also add the
> "purpose" of each internal request to the logs, like:
> RequestPurpose=GET_FIELDS,GET_DEBUG or RequestPurpose=GET_TOP_IDS.
> Also, I'm adding a "track" section to the debug info where to add information
> about the different phases of the distributed request (right now, I'm only
> including QTime, but could eventually include more information) like:
> {code:xml}
>
>
>
> QTime: 10
> QTime: 25
>
>
> QTime: 1
>
>
>
> {code}
> To get this, debugQuery must be set to true, or debug must include
> "debug=track". This information is only added to distributed requests. I
> would like to get feedback on this.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5399) Improve DebugComponent for distributed requests
Tomás Fernández Löbbe created SOLR-5399:
---
Summary: Improve DebugComponent for distributed requests
Key: SOLR-5399
URL: https://issues.apache.org/jira/browse/SOLR-5399
Project: Solr
Issue Type: Improvement
Affects Versions: 5.0
Reporter: Tomás Fernández Löbbe
I'm working on extending the DebugComponent for adding some useful information
to be able to track distributed requests better. I'm adding two different
things, first, the request can generate a "request ID" that will be printed in
the logs for the main query and all the different internal requests to the
different shards. This should make it easier to find the different parts of a
single user request in the logs. It would also add the "purpose" of each
internal request to the logs, like: RequestPurpose=GET_FIELDS,GET_DEBUG or
RequestPurpose=GET_TOP_IDS.
Also, I'm adding a "track" section to the debug info where to add information
about the different phases of the distributed request (right now, I'm only
including QTime, but could eventually include more information) like:
{code:xml}
QTime: 10
QTime: 25
QTime: 1
{code}
To get this, debugQuery must be set to true, or debug must include
"debug=track". This information is only added to distributed requests. I would
like to get feedback on this.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807568#comment-13807568 ] Robert Muir commented on LUCENE-4956: - unzip -O cp949 HANTEC-2.0.zip > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807567#comment-13807567 ] Benson Margulies commented on LUCENE-4956: -- Could you share the trick of unpacking the big tarball, locale-wise? I ended up with: [benson] /data/HANTEC-2.0 % ls relevance_file %B0%FA%C7б%E2%BC%FA%BAо%DF %C0%FCü which does not work so well. Did you set LOCALE to something before unpacking? > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: eval.patch, kr.analyzer.4x.tar, lucene-4956.patch, > lucene4956.patch, LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5354) Distributed sort is broken with CUSTOM FieldType
[
https://issues.apache.org/jira/browse/SOLR-5354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807457#comment-13807457
]
Steve Rowe edited comment on SOLR-5354 at 10/28/13 11:38 PM:
-
Patch fixing the problem.
{{QueryComponent.doFieldSortValues()}} delegates to new method
{{SortField.toExternal()}}, which serializes according to the sort field type,
in the CUSTOM case via new method {{FieldComparatorSource.toExternal()}}.
{{ShardFieldSortedHitQueue}} uses {{ShardComparator.sortVal()}}, which uses new
method {{SortField.toInternal()}} to convert the external value to the
appropriate object, in the CUSTOM case via new method
{{FieldComparatorSource.toInternal()}}.
was (Author: steve_rowe):
Patch fixing the problem.
{{QueryComponent.doFieldSortValues()}} delegates to new method
{{SortField.toExternal()}}, which serializes according to the sort field type.
{{ShardFieldSortedHitQueue}} uses {{ShardComparator.sortVal()}} to convert the
external value to the appropriate object, in the CUSTOM case via new method
{{SortField.toInternal()}}.
> Distributed sort is broken with CUSTOM FieldType
>
>
> Key: SOLR-5354
> URL: https://issues.apache.org/jira/browse/SOLR-5354
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other
>Affects Versions: 4.4, 4.5, 5.0
>Reporter: Jessica Cheng
>Assignee: Steve Rowe
> Labels: custom, query, sort
> Attachments: SOLR-5354.patch
>
>
> We added a custom field type to allow an indexed binary field type that
> supports search (exact match), prefix search, and sort as unsigned bytes
> lexicographical compare. For sort, BytesRef's UTF8SortedAsUnicodeComparator
> accomplishes what we want, and even though the name of the comparator
> mentions UTF8, it doesn't actually assume so and just does byte-level
> operation, so it's good. However, when we do this across different nodes, we
> run into an issue where in QueryComponent.doFieldSortValues:
> // Must do the same conversion when sorting by a
> // String field in Lucene, which returns the terms
> // data as BytesRef:
> if (val instanceof BytesRef) {
> UnicodeUtil.UTF8toUTF16((BytesRef)val, spare);
> field.setStringValue(spare.toString());
> val = ft.toObject(field);
> }
> UnicodeUtil.UTF8toUTF16 is called on our byte array,which isn't actually
> UTF8. I did a hack where I specified our own field comparator to be
> ByteBuffer based to get around that instanceof check, but then the field
> value gets transformed into BYTEARR in JavaBinCodec, and when it's
> unmarshalled, it gets turned into byte[]. Then, in QueryComponent.mergeIds, a
> ShardFieldSortedHitQueue is constructed with ShardDoc.getCachedComparator,
> which decides to give me comparatorNatural in the else of the TODO for
> CUSTOM, which barfs because byte[] are not Comparable...
> From Chris Hostetter:
> I'm not very familiar with the distributed sorting code, but based on your
> comments, and a quick skim of the functions you pointed to, it definitely
> seems like there are two problems here for people trying to implement
> custom sorting in custom FieldTypes...
> 1) QueryComponent.doFieldSortValues - this definitely seems like it should
> be based on the FieldType, not an "instanceof BytesRef" check (oddly: the
> comment event suggestsion that it should be using the FieldType's
> indexedToReadable() method -- but it doesn't do that. If it did, then
> this part of hte logic should work for you as long as your custom
> FieldType implemented indexedToReadable in a sane way.
> 2) QueryComponent.mergeIds - that TODO definitely looks like a gap that
> needs filled. I'm guessing the sanest thing to do in the CUSTOM case
> would be to ask the FieldComparatorSource (which should be coming from the
> SortField that the custom FieldType produced) to create a FieldComparator
> (via newComparator - the numHits & sortPos could be anything) and then
> wrap that up in a Comparator facade that delegates to
> FieldComparator.compareValues
> That way a custom FieldType could be in complete control of the sort
> comparisons (even when merging ids).
> ...But as i said: i may be missing something, i'm not super familia with
> that code. Please try it out and let us know if thta works -- either way
> please open a Jira pointing out the problems trying to implement
> distributed sorting in a custom FieldType.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5354) Distributed sort is broken with CUSTOM FieldType
[
https://issues.apache.org/jira/browse/SOLR-5354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-5354:
-
Attachment: SOLR-5354.patch
Patch fixing the problem.
{{QueryComponent.doFieldSortValues()}} delegates to new method
{{SortField.toExternal()}}, which serializes according to the sort field type.
{{ShardFieldSortedHitQueue}} uses {{ShardComparator.sortVal()}} to convert the
external value to the appropriate object, in the CUSTOM case via new method
{{SortField.toInternal()}}.
> Distributed sort is broken with CUSTOM FieldType
>
>
> Key: SOLR-5354
> URL: https://issues.apache.org/jira/browse/SOLR-5354
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other
>Affects Versions: 4.4, 4.5, 5.0
>Reporter: Jessica Cheng
> Labels: custom, query, sort
> Attachments: SOLR-5354.patch
>
>
> We added a custom field type to allow an indexed binary field type that
> supports search (exact match), prefix search, and sort as unsigned bytes
> lexicographical compare. For sort, BytesRef's UTF8SortedAsUnicodeComparator
> accomplishes what we want, and even though the name of the comparator
> mentions UTF8, it doesn't actually assume so and just does byte-level
> operation, so it's good. However, when we do this across different nodes, we
> run into an issue where in QueryComponent.doFieldSortValues:
> // Must do the same conversion when sorting by a
> // String field in Lucene, which returns the terms
> // data as BytesRef:
> if (val instanceof BytesRef) {
> UnicodeUtil.UTF8toUTF16((BytesRef)val, spare);
> field.setStringValue(spare.toString());
> val = ft.toObject(field);
> }
> UnicodeUtil.UTF8toUTF16 is called on our byte array,which isn't actually
> UTF8. I did a hack where I specified our own field comparator to be
> ByteBuffer based to get around that instanceof check, but then the field
> value gets transformed into BYTEARR in JavaBinCodec, and when it's
> unmarshalled, it gets turned into byte[]. Then, in QueryComponent.mergeIds, a
> ShardFieldSortedHitQueue is constructed with ShardDoc.getCachedComparator,
> which decides to give me comparatorNatural in the else of the TODO for
> CUSTOM, which barfs because byte[] are not Comparable...
> From Chris Hostetter:
> I'm not very familiar with the distributed sorting code, but based on your
> comments, and a quick skim of the functions you pointed to, it definitely
> seems like there are two problems here for people trying to implement
> custom sorting in custom FieldTypes...
> 1) QueryComponent.doFieldSortValues - this definitely seems like it should
> be based on the FieldType, not an "instanceof BytesRef" check (oddly: the
> comment event suggestsion that it should be using the FieldType's
> indexedToReadable() method -- but it doesn't do that. If it did, then
> this part of hte logic should work for you as long as your custom
> FieldType implemented indexedToReadable in a sane way.
> 2) QueryComponent.mergeIds - that TODO definitely looks like a gap that
> needs filled. I'm guessing the sanest thing to do in the CUSTOM case
> would be to ask the FieldComparatorSource (which should be coming from the
> SortField that the custom FieldType produced) to create a FieldComparator
> (via newComparator - the numHits & sortPos could be anything) and then
> wrap that up in a Comparator facade that delegates to
> FieldComparator.compareValues
> That way a custom FieldType could be in complete control of the sort
> comparisons (even when merging ids).
> ...But as i said: i may be missing something, i'm not super familia with
> that code. Please try it out and let us know if thta works -- either way
> please open a Jira pointing out the problems trying to implement
> distributed sorting in a custom FieldType.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-5354) Distributed sort is broken with CUSTOM FieldType
[
https://issues.apache.org/jira/browse/SOLR-5354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe reassigned SOLR-5354:
Assignee: Steve Rowe
> Distributed sort is broken with CUSTOM FieldType
>
>
> Key: SOLR-5354
> URL: https://issues.apache.org/jira/browse/SOLR-5354
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other
>Affects Versions: 4.4, 4.5, 5.0
>Reporter: Jessica Cheng
>Assignee: Steve Rowe
> Labels: custom, query, sort
> Attachments: SOLR-5354.patch
>
>
> We added a custom field type to allow an indexed binary field type that
> supports search (exact match), prefix search, and sort as unsigned bytes
> lexicographical compare. For sort, BytesRef's UTF8SortedAsUnicodeComparator
> accomplishes what we want, and even though the name of the comparator
> mentions UTF8, it doesn't actually assume so and just does byte-level
> operation, so it's good. However, when we do this across different nodes, we
> run into an issue where in QueryComponent.doFieldSortValues:
> // Must do the same conversion when sorting by a
> // String field in Lucene, which returns the terms
> // data as BytesRef:
> if (val instanceof BytesRef) {
> UnicodeUtil.UTF8toUTF16((BytesRef)val, spare);
> field.setStringValue(spare.toString());
> val = ft.toObject(field);
> }
> UnicodeUtil.UTF8toUTF16 is called on our byte array,which isn't actually
> UTF8. I did a hack where I specified our own field comparator to be
> ByteBuffer based to get around that instanceof check, but then the field
> value gets transformed into BYTEARR in JavaBinCodec, and when it's
> unmarshalled, it gets turned into byte[]. Then, in QueryComponent.mergeIds, a
> ShardFieldSortedHitQueue is constructed with ShardDoc.getCachedComparator,
> which decides to give me comparatorNatural in the else of the TODO for
> CUSTOM, which barfs because byte[] are not Comparable...
> From Chris Hostetter:
> I'm not very familiar with the distributed sorting code, but based on your
> comments, and a quick skim of the functions you pointed to, it definitely
> seems like there are two problems here for people trying to implement
> custom sorting in custom FieldTypes...
> 1) QueryComponent.doFieldSortValues - this definitely seems like it should
> be based on the FieldType, not an "instanceof BytesRef" check (oddly: the
> comment event suggestsion that it should be using the FieldType's
> indexedToReadable() method -- but it doesn't do that. If it did, then
> this part of hte logic should work for you as long as your custom
> FieldType implemented indexedToReadable in a sane way.
> 2) QueryComponent.mergeIds - that TODO definitely looks like a gap that
> needs filled. I'm guessing the sanest thing to do in the CUSTOM case
> would be to ask the FieldComparatorSource (which should be coming from the
> SortField that the custom FieldType produced) to create a FieldComparator
> (via newComparator - the numHits & sortPos could be anything) and then
> wrap that up in a Comparator facade that delegates to
> FieldComparator.compareValues
> That way a custom FieldType could be in complete control of the sort
> comparisons (even when merging ids).
> ...But as i said: i may be missing something, i'm not super familia with
> that code. Please try it out and let us know if thta works -- either way
> please open a Jira pointing out the problems trying to implement
> distributed sorting in a custom FieldType.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5374) Support user configured doc-centric versioning rules
[
https://issues.apache.org/jira/browse/SOLR-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-5374:
---
Attachment: SOLR-5374.patch
Here's a patch that includes implementation of multi-threaded fixes using
optimistic concurrency.
> Support user configured doc-centric versioning rules
>
>
> Key: SOLR-5374
> URL: https://issues.apache.org/jira/browse/SOLR-5374
> Project: Solr
> Issue Type: Improvement
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-5374.patch, SOLR-5374.patch, SOLR-5374.patch
>
>
> The existing optimistic concurrency features of Solr can be very handy for
> ensuring that you are only updating/replacing the version of the doc you
> think you are updating/replacing, w/o the risk of someone else
> adding/removing the doc in the mean time -- but I've recently encountered
> some situations where I really wanted to be able to let the client specify an
> arbitrary version, on a per document basis, (ie: generated by an external
> system, or perhaps a timestamp of when a file was last modified) and ensure
> that the corresponding document update was processed only if the "new"
> version is greater then the "old" version -- w/o needing to check exactly
> which version is currently in Solr. (ie: If a client wants to index version
> 101 of a doc, that update should fail if version 102 is already in the index,
> but succeed if the currently indexed version is 99 -- w/o the client needing
> to ask Solr what the current version)
> The idea Yonik brought up in SOLR-5298 (letting the client specify a
> {{\_new\_version\_}} that would be used by the existing optimistic
> concurrency code to control the assignment of the {{\_version\_}} field for
> documents) looked like a good direction to go -- but after digging into the
> way {{\_version\_}} is used internally I realized it requires a uniqueness
> constraint across all update commands, that would make it impossible to allow
> multiple independent documents to have the same {{\_version\_}}.
> So instead I've tackled the problem in a different way, using an
> UpdateProcessor that is configured with user defined field to track a
> "DocBasedVersion" and uses the RTG logic to figure out if the update is
> allowed.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5398) Global properties in new-style solr.xml doesn´t work anymore
[ https://issues.apache.org/jira/browse/SOLR-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergio Garcia Maroto updated SOLR-5398: --- Description: It is not possible to define global properties in Solr.xml as follow anymore. As result you have to copy properies in each core.properties file. If you have many cores you have to copy many times repeated properties. Don´t you think this is something should stay in new Solr versions? Link http://lucene.472066.n3.nabble.com/Global-User-defined-properties-solr-xml-from-Solr-4-4-to-Solr-4-5-td4097740.html Regards, Sergio was: It is not possible to define global properties in Solr.xml as follow anymore. As result you have to copy properies in each core.properties file. If you have many cores you have to copy many times repeated properties. Don´t you think this is something should stay in new Solr versions. Link http://lucene.472066.n3.nabble.com/Global-User-defined-properties-solr-xml-from-Solr-4-4-to-Solr-4-5-td4097740.html Regards, Sergio > Global properties in new-style solr.xml doesn´t work anymore > - > > Key: SOLR-5398 > URL: https://issues.apache.org/jira/browse/SOLR-5398 > Project: Solr > Issue Type: Bug > Components: multicore >Affects Versions: 4.5 >Reporter: Sergio Garcia Maroto > > It is not possible to define global properties in Solr.xml as follow anymore. > > > > As result you have to copy properies in each core.properties file. > If you have many cores you have to copy many times repeated properties. > Don´t you think this is something should stay in new Solr versions? > Link > http://lucene.472066.n3.nabble.com/Global-User-defined-properties-solr-xml-from-Solr-4-4-to-Solr-4-5-td4097740.html > Regards, > Sergio -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5398) Global properties in new-style solr.xml doesn´t work anymore
Sergio Garcia Maroto created SOLR-5398: -- Summary: Global properties in new-style solr.xml doesn´t work anymore Key: SOLR-5398 URL: https://issues.apache.org/jira/browse/SOLR-5398 Project: Solr Issue Type: Bug Components: multicore Affects Versions: 4.5 Reporter: Sergio Garcia Maroto It is not possible to define global properties in Solr.xml as follow anymore. As result you have to copy properies in each core.properties file. If you have many cores you have to copy many times repeated properties. Don´t you think this is something should stay in new Solr versions. Link http://lucene.472066.n3.nabble.com/Global-User-defined-properties-solr-xml-from-Solr-4-4-to-Solr-4-5-td4097740.html Regards, Sergio -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5397) Test fails for ChaosMonkeySafeLeaderTest on Apache Jenkins
[ https://issues.apache.org/jira/browse/SOLR-5397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807198#comment-13807198 ] ASF subversion and git services commented on SOLR-5397: --- Commit 1536513 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1536513 ] SOLR-5397: If a retry fails, *always* finish the rest of the retries > Test fails for ChaosMonkeySafeLeaderTest on Apache Jenkins > --- > > Key: SOLR-5397 > URL: https://issues.apache.org/jira/browse/SOLR-5397 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.6, 5.0 > > > Error Message: > shard3 is not consistent. Got 137 from > http://127.0.0.1:49317/collection1lastClient and got 125 from > http://127.0.0.1:39794/collection1 -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5397) Test fails for ChaosMonkeySafeLeaderTest on Apache Jenkins
[ https://issues.apache.org/jira/browse/SOLR-5397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807196#comment-13807196 ] ASF subversion and git services commented on SOLR-5397: --- Commit 1536511 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1536511 ] SOLR-5397: If a retry fails, *always* finish the rest of the retries > Test fails for ChaosMonkeySafeLeaderTest on Apache Jenkins > --- > > Key: SOLR-5397 > URL: https://issues.apache.org/jira/browse/SOLR-5397 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.6, 5.0 > > > Error Message: > shard3 is not consistent. Got 137 from > http://127.0.0.1:49317/collection1lastClient and got 125 from > http://127.0.0.1:39794/collection1 -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5397) Test fails for ChaosMonkeySafeLeaderTest on Apache Jenkins
[ https://issues.apache.org/jira/browse/SOLR-5397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807176#comment-13807176 ] ASF subversion and git services commented on SOLR-5397: --- Commit 1536499 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1536499 ] SOLR-5397: Move the call to obtain a ConcucrrentSolrServer into try catch block > Test fails for ChaosMonkeySafeLeaderTest on Apache Jenkins > --- > > Key: SOLR-5397 > URL: https://issues.apache.org/jira/browse/SOLR-5397 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.6, 5.0 > > > Error Message: > shard3 is not consistent. Got 137 from > http://127.0.0.1:49317/collection1lastClient and got 125 from > http://127.0.0.1:39794/collection1 -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5397) Test fails for ChaosMonkeySafeLeaderTest on Apache Jenkins
[ https://issues.apache.org/jira/browse/SOLR-5397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807178#comment-13807178 ] ASF subversion and git services commented on SOLR-5397: --- Commit 1536500 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1536500 ] SOLR-5397: Move the call to obtain a ConcucrrentSolrServer into try catch block > Test fails for ChaosMonkeySafeLeaderTest on Apache Jenkins > --- > > Key: SOLR-5397 > URL: https://issues.apache.org/jira/browse/SOLR-5397 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.6, 5.0 > > > Error Message: > shard3 is not consistent. Got 137 from > http://127.0.0.1:49317/collection1lastClient and got 125 from > http://127.0.0.1:39794/collection1 -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5397) Test fails for ChaosMonkeySafeLeaderTest on Apache Jenkins
[ https://issues.apache.org/jira/browse/SOLR-5397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807160#comment-13807160 ] Mark Miller commented on SOLR-5397: --- Seems to happen on runs when we don't even kill any servers or cause any connection disruption, etc. > Test fails for ChaosMonkeySafeLeaderTest on Apache Jenkins > --- > > Key: SOLR-5397 > URL: https://issues.apache.org/jira/browse/SOLR-5397 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.6, 5.0 > > > Error Message: > shard3 is not consistent. Got 137 from > http://127.0.0.1:49317/collection1lastClient and got 125 from > http://127.0.0.1:39794/collection1 -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5397) Test fails for ChaosMonkeySafeLeaderTest on Apache Jenkins
Mark Miller created SOLR-5397: - Summary: Test fails for ChaosMonkeySafeLeaderTest on Apache Jenkins Key: SOLR-5397 URL: https://issues.apache.org/jira/browse/SOLR-5397 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.6, 5.0 Error Message: shard3 is not consistent. Got 137 from http://127.0.0.1:49317/collection1lastClient and got 125 from http://127.0.0.1:39794/collection1 -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5027) Field Collapsing PostFilter
[
https://issues.apache.org/jira/browse/SOLR-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807136#comment-13807136
]
Shawn Heisey edited comment on SOLR-5027 at 10/28/13 7:21 PM:
--
Thanks [~steve_rowe]! [~er.shruti], if you edit solr/core/ivy.xml after the
merge, you can change the /com.carrotsearch/hppc property substitution to 0.5.2
and it should work properly. That was the version I found in branch_4x for the
hppc component.
I was trying to boil it down to a patch, but ran into some problems. Fixing
the one line manually is easier.
was (Author: elyograg):
Thanks [~steve_rowe]! [~er.shruti], if you edit solr/core/ivy.xml after the
merge, you can change the /com/carrotsearch/hppc property substitution to 0.5.2
and it should work properly. That was the version I found in branch_4x for the
hppc component.
I was trying to boil it down to a patch, but ran into some problems. Fixing
the one line manually is easier.
> Field Collapsing PostFilter
> ---
>
> Key: SOLR-5027
> URL: https://issues.apache.org/jira/browse/SOLR-5027
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 5.0
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 4.6, 5.0
>
> Attachments: SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch,
> SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch,
> SOLR-5027.patch, SOLR-5027.patch
>
>
> This ticket introduces the *CollapsingQParserPlugin*
> The *CollapsingQParserPlugin* is a PostFilter that performs field collapsing.
> This is a high performance alternative to standard Solr field collapsing
> (with *ngroups*) when the number of distinct groups in the result set is high.
> For example in one performance test, a search with 10 million full results
> and 1 million collapsed groups:
> Standard grouping with ngroups : 17 seconds.
> CollapsingQParserPlugin: 300 milli-seconds.
> Sample syntax:
> Collapse based on the highest scoring document:
> {code}
> fq=(!collapse field=}
> {code}
> Collapse based on the min value of a numeric field:
> {code}
> fq={!collapse field= min=}
> {code}
> Collapse based on the max value of a numeric field:
> {code}
> fq={!collapse field= max=}
> {code}
> Collapse with a null policy:
> {code}
> fq={!collapse field= nullPolicy=}
> {code}
> There are three null policies:
> ignore : removes docs with a null value in the collapse field (default).
> expand : treats each doc with a null value in the collapse field as a
> separate group.
> collapse : collapses all docs with a null value into a single group using
> either highest score, or min/max.
> The CollapsingQParserPlugin also fully supports the QueryElevationComponent
> *Note:* The July 16 patch also includes and ExpandComponent that expands the
> collapsed groups for the current search result page. This functionality will
> be moved to it's own ticket.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5027) Field Collapsing PostFilter
[
https://issues.apache.org/jira/browse/SOLR-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807136#comment-13807136
]
Shawn Heisey commented on SOLR-5027:
Thanks [~steve_rowe]! [~er.shruti], if you edit solr/core/ivy.xml after the
merge, you can change the /com/carrotsearch/hppc property substitution to 0.5.2
and it should work properly. That was the version I found in branch_4x for the
hppc component.
I was trying to boil it down to a patch, but ran into some problems. Fixing
the one line manually is easier.
> Field Collapsing PostFilter
> ---
>
> Key: SOLR-5027
> URL: https://issues.apache.org/jira/browse/SOLR-5027
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 5.0
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 4.6, 5.0
>
> Attachments: SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch,
> SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch,
> SOLR-5027.patch, SOLR-5027.patch
>
>
> This ticket introduces the *CollapsingQParserPlugin*
> The *CollapsingQParserPlugin* is a PostFilter that performs field collapsing.
> This is a high performance alternative to standard Solr field collapsing
> (with *ngroups*) when the number of distinct groups in the result set is high.
> For example in one performance test, a search with 10 million full results
> and 1 million collapsed groups:
> Standard grouping with ngroups : 17 seconds.
> CollapsingQParserPlugin: 300 milli-seconds.
> Sample syntax:
> Collapse based on the highest scoring document:
> {code}
> fq=(!collapse field=}
> {code}
> Collapse based on the min value of a numeric field:
> {code}
> fq={!collapse field= min=}
> {code}
> Collapse based on the max value of a numeric field:
> {code}
> fq={!collapse field= max=}
> {code}
> Collapse with a null policy:
> {code}
> fq={!collapse field= nullPolicy=}
> {code}
> There are three null policies:
> ignore : removes docs with a null value in the collapse field (default).
> expand : treats each doc with a null value in the collapse field as a
> separate group.
> collapse : collapses all docs with a null value into a single group using
> either highest score, or min/max.
> The CollapsingQParserPlugin also fully supports the QueryElevationComponent
> *Note:* The July 16 patch also includes and ExpandComponent that expands the
> collapsed groups for the current search result page. This functionality will
> be moved to it's own ticket.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5027) Field Collapsing PostFilter
[
https://issues.apache.org/jira/browse/SOLR-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807125#comment-13807125
]
Steve Rowe edited comment on SOLR-5027 at 10/28/13 7:12 PM:
[~er.shruti], the problem is that as of Lucene/Solr 4.6, all ivy.xml versions
are pulled from {{lucene/ivy-versions.properties}} - see LUCENE-5249 and
LUCENE-5257 - but not in the lucene_solr_4_5 branch.
You can look up the correct ivy.xml version to use in the 4.6 branch, rather
than the {{/com.carrotsearch/hppc}} thing that's on branch_4x.
was (Author: steve_rowe):
[~er.shruti], the problem is that as of Lucene/Solr 4.6, all ivy.xml versions
are pulled from {{lucene/ivy-versions.properties}} - see LUCENE-5249 and
LUCENE-5247 - but not in the lucene_solr_4_5 branch.
You can look up the correct ivy.xml version to use in the 4.6 branch, rather
than the {{/com.carrotsearch/hppc}} thing that's on branch_4x.
> Field Collapsing PostFilter
> ---
>
> Key: SOLR-5027
> URL: https://issues.apache.org/jira/browse/SOLR-5027
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 5.0
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 4.6, 5.0
>
> Attachments: SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch,
> SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch,
> SOLR-5027.patch, SOLR-5027.patch
>
>
> This ticket introduces the *CollapsingQParserPlugin*
> The *CollapsingQParserPlugin* is a PostFilter that performs field collapsing.
> This is a high performance alternative to standard Solr field collapsing
> (with *ngroups*) when the number of distinct groups in the result set is high.
> For example in one performance test, a search with 10 million full results
> and 1 million collapsed groups:
> Standard grouping with ngroups : 17 seconds.
> CollapsingQParserPlugin: 300 milli-seconds.
> Sample syntax:
> Collapse based on the highest scoring document:
> {code}
> fq=(!collapse field=}
> {code}
> Collapse based on the min value of a numeric field:
> {code}
> fq={!collapse field= min=}
> {code}
> Collapse based on the max value of a numeric field:
> {code}
> fq={!collapse field= max=}
> {code}
> Collapse with a null policy:
> {code}
> fq={!collapse field= nullPolicy=}
> {code}
> There are three null policies:
> ignore : removes docs with a null value in the collapse field (default).
> expand : treats each doc with a null value in the collapse field as a
> separate group.
> collapse : collapses all docs with a null value into a single group using
> either highest score, or min/max.
> The CollapsingQParserPlugin also fully supports the QueryElevationComponent
> *Note:* The July 16 patch also includes and ExpandComponent that expands the
> collapsed groups for the current search result page. This functionality will
> be moved to it's own ticket.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5157) Refactoring MultiDocValues.OrdinalMap to clarify API and internal structure.
[ https://issues.apache.org/jira/browse/LUCENE-5157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807127#comment-13807127 ] Robert Muir commented on LUCENE-5157: - I thought i gave a +1 above :) Not an objection just reiterating my previous hesitation: for example if I had that the time I would patch query-time join to use this class to support global ordinals across even different readers instead of huge hashmaps of terms, I think this would be much faster as its just an int<->int join. Then the segment number stuff might look wierd and the old API more intuitive, but this patch is fine for now! > Refactoring MultiDocValues.OrdinalMap to clarify API and internal structure. > > > Key: LUCENE-5157 > URL: https://issues.apache.org/jira/browse/LUCENE-5157 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Boaz Leskes >Assignee: Adrien Grand >Priority: Minor > Attachments: LUCENE-5157.patch > > > I refactored MultiDocValues.OrdinalMap, removing one unused parameter and > renaming some methods to more clearly communicate what they do. Also I > renamed subIndex references to segmentIndex. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5027) Field Collapsing PostFilter
[
https://issues.apache.org/jira/browse/SOLR-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807125#comment-13807125
]
Steve Rowe commented on SOLR-5027:
--
[~er.shruti], the problem is that as of Lucene/Solr 4.6, all ivy.xml versions
are pulled from {{lucene/ivy-versions.properties}} - see LUCENE-5249 and
LUCENE-5247 - but not in the lucene_solr_4_5 branch.
You can look up the correct ivy.xml version to use in the 4.6 branch, rather
than the {{/com.carrotsearch/hppc}} thing that's on branch_4x.
> Field Collapsing PostFilter
> ---
>
> Key: SOLR-5027
> URL: https://issues.apache.org/jira/browse/SOLR-5027
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 5.0
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 4.6, 5.0
>
> Attachments: SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch,
> SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch,
> SOLR-5027.patch, SOLR-5027.patch
>
>
> This ticket introduces the *CollapsingQParserPlugin*
> The *CollapsingQParserPlugin* is a PostFilter that performs field collapsing.
> This is a high performance alternative to standard Solr field collapsing
> (with *ngroups*) when the number of distinct groups in the result set is high.
> For example in one performance test, a search with 10 million full results
> and 1 million collapsed groups:
> Standard grouping with ngroups : 17 seconds.
> CollapsingQParserPlugin: 300 milli-seconds.
> Sample syntax:
> Collapse based on the highest scoring document:
> {code}
> fq=(!collapse field=}
> {code}
> Collapse based on the min value of a numeric field:
> {code}
> fq={!collapse field= min=}
> {code}
> Collapse based on the max value of a numeric field:
> {code}
> fq={!collapse field= max=}
> {code}
> Collapse with a null policy:
> {code}
> fq={!collapse field= nullPolicy=}
> {code}
> There are three null policies:
> ignore : removes docs with a null value in the collapse field (default).
> expand : treats each doc with a null value in the collapse field as a
> separate group.
> collapse : collapses all docs with a null value into a single group using
> either highest score, or min/max.
> The CollapsingQParserPlugin also fully supports the QueryElevationComponent
> *Note:* The July 16 patch also includes and ExpandComponent that expands the
> collapsed groups for the current search result page. This functionality will
> be moved to it's own ticket.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5027) Field Collapsing PostFilter
[
https://issues.apache.org/jira/browse/SOLR-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807110#comment-13807110
]
Shawn Heisey commented on SOLR-5027:
[~er.shruti] I see that happening too. I never had a chance to actually try
building it with the commits merged. I have no idea how to fix problems with
ivy.
The ivy.xml change for hppc that is not working is in branch_4x as well, and
that branch compiles. This problem is beyond my skills.
> Field Collapsing PostFilter
> ---
>
> Key: SOLR-5027
> URL: https://issues.apache.org/jira/browse/SOLR-5027
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 5.0
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 4.6, 5.0
>
> Attachments: SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch,
> SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch,
> SOLR-5027.patch, SOLR-5027.patch
>
>
> This ticket introduces the *CollapsingQParserPlugin*
> The *CollapsingQParserPlugin* is a PostFilter that performs field collapsing.
> This is a high performance alternative to standard Solr field collapsing
> (with *ngroups*) when the number of distinct groups in the result set is high.
> For example in one performance test, a search with 10 million full results
> and 1 million collapsed groups:
> Standard grouping with ngroups : 17 seconds.
> CollapsingQParserPlugin: 300 milli-seconds.
> Sample syntax:
> Collapse based on the highest scoring document:
> {code}
> fq=(!collapse field=}
> {code}
> Collapse based on the min value of a numeric field:
> {code}
> fq={!collapse field= min=}
> {code}
> Collapse based on the max value of a numeric field:
> {code}
> fq={!collapse field= max=}
> {code}
> Collapse with a null policy:
> {code}
> fq={!collapse field= nullPolicy=}
> {code}
> There are three null policies:
> ignore : removes docs with a null value in the collapse field (default).
> expand : treats each doc with a null value in the collapse field as a
> separate group.
> collapse : collapses all docs with a null value into a single group using
> either highest score, or min/max.
> The CollapsingQParserPlugin also fully supports the QueryElevationComponent
> *Note:* The July 16 patch also includes and ExpandComponent that expands the
> collapsed groups for the current search result page. This functionality will
> be moved to it's own ticket.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5157) Refactoring MultiDocValues.OrdinalMap to clarify API and internal structure.
[ https://issues.apache.org/jira/browse/LUCENE-5157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807060#comment-13807060 ] Adrien Grand commented on LUCENE-5157: -- This issue has been stalled for a few months now. Looking back at it, I think that the changes that Boaz proposes make the API easier to understand. It might be less general but this class is experimental so it will be possible to change the API again in the future is we want. I propose to commit the patch. If there are objections, I'll just close this issue as "Won't fix" and commit the suggested assertion in MultiOrdinals.getSegmentOrd. > Refactoring MultiDocValues.OrdinalMap to clarify API and internal structure. > > > Key: LUCENE-5157 > URL: https://issues.apache.org/jira/browse/LUCENE-5157 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Boaz Leskes >Assignee: Adrien Grand >Priority: Minor > Attachments: LUCENE-5157.patch > > > I refactored MultiDocValues.OrdinalMap, removing one unused parameter and > renaming some methods to more clearly communicate what they do. Also I > renamed subIndex references to segmentIndex. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5301) All PackedInts APIs should share a common interface for random-access reads
[
https://issues.apache.org/jira/browse/LUCENE-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand updated LUCENE-5301:
-
Attachment: LUCENE-5301.patch
New patch: PackedInts.Reader now only extends NumericDocValues.
> All PackedInts APIs should share a common interface for random-access reads
> ---
>
> Key: LUCENE-5301
> URL: https://issues.apache.org/jira/browse/LUCENE-5301
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-5301.patch, LUCENE-5301.patch
>
>
> It would be convenient if all PackedInts had a super-class with the {{long
> get(long index)}} method. Maybe this super-class could even be
> NumericDocValues so that doc values formats don't need to wrap eg.
> BlockPackedReader into this kind of construct:
> {code}
> final BlockPackedReader reader = new BlockPackedReader(data,
> entry.packedIntsVersion, entry.blockSize, entry.count, true);
> return new LongNumericDocValues() {
> @Override
> public long get(long id) {
> return reader.get(id);
> }
> };
> {code}
> Instead, they could just
> {code}
> return new BlockPackedReader(data, entry.packedIntsVersion,
> entry.blockSize, entry.count, true);
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5312) Block-join-friendly index sorting
[ https://issues.apache.org/jira/browse/LUCENE-5312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-5312: - Attachment: LUCENE-5312.patch Here is a patch that contains a new BlockJoinSorter abstract class, which allows for reordering documents without breaking index-time blocks. The order of parents and the order of children within the same parent can be configured separately. > Block-join-friendly index sorting > - > > Key: LUCENE-5312 > URL: https://issues.apache.org/jira/browse/LUCENE-5312 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/other >Reporter: Adrien Grand >Assignee: Adrien Grand >Priority: Minor > Attachments: LUCENE-5312.patch > > > It could be useful to have a block-join-friendly sorter implementation that > doesn't break index-time blocks: > - blocks must not interleave, > - parents must remain at the end of the blocks -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5310) Merge Threads unnecessarily block on SerialMergeScheduler
[ https://issues.apache.org/jira/browse/LUCENE-5310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806961#comment-13806961 ] Michael McCandless commented on LUCENE-5310: Hmm, I don't think we should do this. This blocking in SMS is by design: SMS stalls any indexing threads while merges are running; if you want concurrency you should use CMS? CMS, also, needs to see all threads, because it (by design) stalls incoming index threads when there are too many merges running. > Merge Threads unnecessarily block on SerialMergeScheduler > - > > Key: LUCENE-5310 > URL: https://issues.apache.org/jira/browse/LUCENE-5310 > Project: Lucene - Core > Issue Type: Improvement > Components: core/index >Affects Versions: 4.5, 5.0 >Reporter: Simon Willnauer >Priority: Minor > Fix For: 4.6, 5.0 > > Attachments: LUCENE-5310.patch, LUCENE-5310.patch > > > I have been working on a high level merge multiplexer that shares threads > across different IW instances and I came across the fact that > SerialMergeScheduler actually blocks incoming thread is a merge in going on. > Yet this blocks threads unnecessarily since we pull the merges in a loop > anyway. We should use a tryLock operation instead of syncing the entire > method? -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5312) Block-join-friendly index sorting
Adrien Grand created LUCENE-5312: Summary: Block-join-friendly index sorting Key: LUCENE-5312 URL: https://issues.apache.org/jira/browse/LUCENE-5312 Project: Lucene - Core Issue Type: Improvement Components: modules/other Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor It could be useful to have a block-join-friendly sorter implementation that doesn't break index-time blocks: - blocks must not interleave, - parents must remain at the end of the blocks -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5311) Make it possible to train / run classification over multiple fields
Tommaso Teofili created LUCENE-5311: --- Summary: Make it possible to train / run classification over multiple fields Key: LUCENE-5311 URL: https://issues.apache.org/jira/browse/LUCENE-5311 Project: Lucene - Core Issue Type: Improvement Components: modules/classification Reporter: Tommaso Teofili Assignee: Tommaso Teofili It'd be nice to be able to use multiple fields instead of just one for training / running each classifier. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5396) solr facet caught end of stream exception
eason chen created SOLR-5396: Summary: solr facet caught end of stream exception Key: SOLR-5396 URL: https://issues.apache.org/jira/browse/SOLR-5396 Project: Solr Issue Type: Bug Components: Build, multicore Affects Versions: 4.4 Environment: linux Reporter: eason chen I had a solrcloud with 3 shards on different servers. All the normal full text search are perfect. But when I try to facet the text stream field. I always got this error message: EndOfStreamException: Unable to read additional data from client sessionid 0x141ff828d5f0001, likely client has closed socket at org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:220) at org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:208) at java.lang.Thread.run(Thread.java:724) When I try to facet some fields like Gender which only has two options : m and f, it works perfectly fine. I have been stuck on this for a while, any one can help me out? Thanks in advance. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1604) Wildcards, ORs etc inside Phrase Queries
[ https://issues.apache.org/jira/browse/SOLR-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806798#comment-13806798 ] ettey siva commented on SOLR-1604: -- Hi Ahmet I have installed complexphrase parser and followed all instructions for installation... Everything is fine except getting NULL Pointer exception when I start JBOSS. 19:46:03,909 ERROR [SolrCore] java.lang.NullPointerException at org.apache.solr.schema.IndexSchema$DynamicReplacement$DynamicPattern$NameEndsWith.matches(IndexSchema.java:960) at org.apache.solr.schema.IndexSchema$DynamicReplacement.matches(IndexSchema.java:974) at org.apache.solr.schema.IndexSchema.getDynamicFieldType(IndexSchema.java:1221) at org.apache.solr.schema.IndexSchema$SolrQueryAnalyzer.getWrappedAnalyzer(IndexSchema.java:418) at org.apache.lucene.analysis.AnalyzerWrapper.initReader(AnalyzerWrapper.java:81) at org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:175) at org.apache.lucene.queryparser.classic.QueryParserBase.newFieldQuery(QueryParserBase.java:507) at org.apache.lucene.queryparser.classic.QueryParserBase.getFieldQuery(QueryParserBase.java:495) at org.apache.lucene.queryparser.classic.QueryParserBase.handleBareTokenQuery(QueryParserBase.java:1109) at org.apache.lucene.queryparser.classic.QueryParser.Term(QueryParser.java:358) at org.apache.lucene.queryparser.classic.QueryParser.Clause(QueryParser.java:257) at org.apache.lucene.queryparser.classic.QueryParser.Query(QueryParser.java:181) at org.apache.lucene.queryparser.classic.QueryParser.TopLevelQuery(QueryParser.java:170) at org.apache.lucene.queryparser.classic.QueryParserBase.parse(QueryParserBase.java:121) at org.apache.lucene.queryparser.classic.ComplexPhraseQueryParser.parse(ComplexPhraseQueryParser.java:107) at org.apache.solr.search.ComplexPhraseQParser.parse(ComplexPhraseQParserPlugin.java:108) at org.apache.solr.search.QParser.getQuery(QParser.java:142) at org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:142) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:187) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1904) at org.apache.solr.core.QuerySenderListener.newSearcher(QuerySenderListener.java:64) at org.apache.solr.core.SolrCore$5.call(SolrCore.java:1693) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Thanks in advance. > Wildcards, ORs etc inside Phrase Queries > > > Key: SOLR-1604 > URL: https://issues.apache.org/jira/browse/SOLR-1604 > Project: Solr > Issue Type: Improvement > Components: query parsers, search >Affects Versions: 1.4 >Reporter: Ahmet Arslan >Priority: Minor > Attachments: ASF.LICENSE.NOT.GRANTED--ComplexPhrase.zip, > ComplexPhrase-4.2.1.zip, ComplexPhraseQueryParser.java, > ComplexPhrase_solr_3.4.zip, ComplexPhrase.zip, ComplexPhrase.zip, > ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, > SOLR-1604-alternative.patch, SOLR-1604.patch, SOLR-1604.patch > > > Solr Plugin for ComplexPhraseQueryParser (LUCENE-1486) which supports > wildcards, ORs, ranges, fuzzies inside phrase queries. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5310) Merge Threads unnecessarily block on SerialMergeScheduler
[ https://issues.apache.org/jira/browse/LUCENE-5310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-5310: Attachment: LUCENE-5310.patch next iteration - I actually figured out that all of our MSC have this problem. I added a more general solution and implemented a slightly smarter solution for this in the MergeScheduler base class. > Merge Threads unnecessarily block on SerialMergeScheduler > - > > Key: LUCENE-5310 > URL: https://issues.apache.org/jira/browse/LUCENE-5310 > Project: Lucene - Core > Issue Type: Improvement > Components: core/index >Affects Versions: 4.5, 5.0 >Reporter: Simon Willnauer >Priority: Minor > Fix For: 4.6, 5.0 > > Attachments: LUCENE-5310.patch, LUCENE-5310.patch > > > I have been working on a high level merge multiplexer that shares threads > across different IW instances and I came across the fact that > SerialMergeScheduler actually blocks incoming thread is a merge in going on. > Yet this blocks threads unnecessarily since we pull the merges in a loop > anyway. We should use a tryLock operation instead of syncing the entire > method? -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5310) Merge Threads unnecessarily block on SerialMergeScheduler
[ https://issues.apache.org/jira/browse/LUCENE-5310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-5310: Attachment: LUCENE-5310.patch here is a patch > Merge Threads unnecessarily block on SerialMergeScheduler > - > > Key: LUCENE-5310 > URL: https://issues.apache.org/jira/browse/LUCENE-5310 > Project: Lucene - Core > Issue Type: Improvement > Components: core/index >Affects Versions: 4.5, 5.0 >Reporter: Simon Willnauer >Priority: Minor > Fix For: 4.6, 5.0 > > Attachments: LUCENE-5310.patch > > > I have been working on a high level merge multiplexer that shares threads > across different IW instances and I came across the fact that > SerialMergeScheduler actually blocks incoming thread is a merge in going on. > Yet this blocks threads unnecessarily since we pull the merges in a loop > anyway. We should use a tryLock operation instead of syncing the entire > method? -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5310) Merge Threads unnecessarily block on SerialMergeScheduler
Simon Willnauer created LUCENE-5310: --- Summary: Merge Threads unnecessarily block on SerialMergeScheduler Key: LUCENE-5310 URL: https://issues.apache.org/jira/browse/LUCENE-5310 Project: Lucene - Core Issue Type: Improvement Components: core/index Affects Versions: 4.5, 5.0 Reporter: Simon Willnauer Priority: Minor Fix For: 4.6, 5.0 I have been working on a high level merge multiplexer that shares threads across different IW instances and I came across the fact that SerialMergeScheduler actually blocks incoming thread is a merge in going on. Yet this blocks threads unnecessarily since we pull the merges in a loop anyway. We should use a tryLock operation instead of syncing the entire method? -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5395) allow some update processors to run on forwarded update
[ https://issues.apache.org/jira/browse/SOLR-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved SOLR-5395. Resolution: Fixed Fix Version/s: 5.0 4.6 > allow some update processors to run on forwarded update > --- > > Key: SOLR-5395 > URL: https://issues.apache.org/jira/browse/SOLR-5395 > Project: Solr > Issue Type: Improvement >Reporter: Yonik Seeley > Fix For: 4.6, 5.0 > > Attachments: SOLR-5395.patch > > > Update processors before the distributed update processor are dropped in > later distributed update phases. The log update processor is hard-coded to > get a pass, but we should make this more generic and allow other processors > to also run. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5395) allow some update processors to run on forwarded update
[ https://issues.apache.org/jira/browse/SOLR-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806744#comment-13806744 ] ASF subversion and git services commented on SOLR-5395: --- Commit 1536346 from [~yo...@apache.org] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1536346 ] SOLR-5395: add RunAlways marker interface for update processor facctories > allow some update processors to run on forwarded update > --- > > Key: SOLR-5395 > URL: https://issues.apache.org/jira/browse/SOLR-5395 > Project: Solr > Issue Type: Improvement >Reporter: Yonik Seeley > Attachments: SOLR-5395.patch > > > Update processors before the distributed update processor are dropped in > later distributed update phases. The log update processor is hard-coded to > get a pass, but we should make this more generic and allow other processors > to also run. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5395) allow some update processors to run on forwarded update
[ https://issues.apache.org/jira/browse/SOLR-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806742#comment-13806742 ] ASF subversion and git services commented on SOLR-5395: --- Commit 1536344 from [~yo...@apache.org] in branch 'dev/trunk' [ https://svn.apache.org/r1536344 ] SOLR-5395: add RunAlways marker interface for update processor facctories > allow some update processors to run on forwarded update > --- > > Key: SOLR-5395 > URL: https://issues.apache.org/jira/browse/SOLR-5395 > Project: Solr > Issue Type: Improvement >Reporter: Yonik Seeley > Attachments: SOLR-5395.patch > > > Update processors before the distributed update processor are dropped in > later distributed update phases. The log update processor is hard-coded to > get a pass, but we should make this more generic and allow other processors > to also run. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5395) allow some update processors to run on forwarded update
[ https://issues.apache.org/jira/browse/SOLR-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806738#comment-13806738 ] ASF subversion and git services commented on SOLR-5395: --- Commit 1536341 from [~yo...@apache.org] in branch 'dev/trunk' [ https://svn.apache.org/r1536341 ] SOLR-5395: add RunAlways marker interface for update processor facctories > allow some update processors to run on forwarded update > --- > > Key: SOLR-5395 > URL: https://issues.apache.org/jira/browse/SOLR-5395 > Project: Solr > Issue Type: Improvement >Reporter: Yonik Seeley > Attachments: SOLR-5395.patch > > > Update processors before the distributed update processor are dropped in > later distributed update phases. The log update processor is hard-coded to > get a pass, but we should make this more generic and allow other processors > to also run. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5027) Field Collapsing PostFilter
[
https://issues.apache.org/jira/browse/SOLR-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806605#comment-13806605
]
shruti suri commented on SOLR-5027:
---
Hi,
I implemented above solution and run following commands
cd lucene_solr_4_5_1/solr
ant dist
I again got some error.
[ivy:retrieve]
http://mirror.netcologne.de/maven2/com/carrotsearch/hppc/${/com.carrotsearch/hppc}/hppc-${/com.carrotsearch/hppc}.jar
[ivy:retrieve] ::
[ivy:retrieve] :: UNRESOLVED DEPENDENCIES ::
[ivy:retrieve] ::
[ivy:retrieve] :: com.carrotsearch#hppc;${/com.carrotsearch/hppc}: not
found
[ivy:retrieve] ::
[ivy:retrieve]
[ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
BUILD FAILED
/lucene_solr_4_5_1/solr/common-build.xml:354: The following error occurred
while executing this line:
/lucene_solr_4_5_1/solr/core/build.xml:55: impossible to resolve dependencies:
resolve failed - see output for details
Regards
shruti
> Field Collapsing PostFilter
> ---
>
> Key: SOLR-5027
> URL: https://issues.apache.org/jira/browse/SOLR-5027
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 5.0
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 4.6, 5.0
>
> Attachments: SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch,
> SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch,
> SOLR-5027.patch, SOLR-5027.patch
>
>
> This ticket introduces the *CollapsingQParserPlugin*
> The *CollapsingQParserPlugin* is a PostFilter that performs field collapsing.
> This is a high performance alternative to standard Solr field collapsing
> (with *ngroups*) when the number of distinct groups in the result set is high.
> For example in one performance test, a search with 10 million full results
> and 1 million collapsed groups:
> Standard grouping with ngroups : 17 seconds.
> CollapsingQParserPlugin: 300 milli-seconds.
> Sample syntax:
> Collapse based on the highest scoring document:
> {code}
> fq=(!collapse field=}
> {code}
> Collapse based on the min value of a numeric field:
> {code}
> fq={!collapse field= min=}
> {code}
> Collapse based on the max value of a numeric field:
> {code}
> fq={!collapse field= max=}
> {code}
> Collapse with a null policy:
> {code}
> fq={!collapse field= nullPolicy=}
> {code}
> There are three null policies:
> ignore : removes docs with a null value in the collapse field (default).
> expand : treats each doc with a null value in the collapse field as a
> separate group.
> collapse : collapses all docs with a null value into a single group using
> either highest score, or min/max.
> The CollapsingQParserPlugin also fully supports the QueryElevationComponent
> *Note:* The July 16 patch also includes and ExpandComponent that expands the
> collapsed groups for the current search result page. This functionality will
> be moved to it's own ticket.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
