[jira] [Updated] (LUCENE-5930) IntelliJ config: drop resource-only modules, add module groups, and add module for lucene/backward-codecs

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated LUCENE-5930:
---
Attachment: LUCENE-5930.patch

The module groups look good, I didn't change them in this version of the patch.

I refactored the patch a bit so that the {{dev-tools/\*\*/\*.iml}} files are 
svn move'd - that way their history stays intact and I can view diffs for them 
in IntelliJ.  Run the following svn commands before applying the patch:

{noformat}
svn mv dev-tools/idea/lucene/core/src/java/lucene-core.iml 
dev-tools/idea/lucene/core/src/
svn mv dev-tools/idea/lucene/codecs/src/java/codecs.iml 
dev-tools/idea/lucene/codecs/src/
svn mv dev-tools/idea/solr/core/src/test/solr-core-tests.iml 
dev-tools/idea/solr/core/src/
svn mv dev-tools/idea/solr/solrj/src/test/solrj-tests.iml 
dev-tools/idea/solr/solrj/src/
{noformat}

I also fixed up several other issues I found after running all the predefined 
whole-module JUnit run configurations.

The main things I changed:

* Added {{lucene-core}} as a TEST dependency to {{solrj-tests.iml}}, so that 
tests that need lucene utility class(es) will compile - I think this is the 
problem you saw, Ryan.
* Reordered {{.idea/modules.xml}} by module group and then alphabetically, and 
put the {{group}} attribute first in the XML tags.
* Added an {{@Ignore}} annotation to backward-codec module's 
{{CreateBackwardsCompatibilityIndex}} so that IntelliJ won't run it.
* Removed the test output directory from {{lucene-core.iml}}, so that it 
wouldn't be included in {{analysis-common}}'s test classpath; otherwise, 
{{TestAllAnalyzersHaveFactories}} complains that 
{{TrivialLookaheadTokenFilter}}, a Lucene core test class, can't be loaded via 
SPI.  (I also did the same thing in {{codecs.iml}} even though it isn't causing 
a problem at this point, since test output only happens in the corresponding 
test module.)
* Added {{src/resources/}} to {{sandbox.iml}} so that 
{{IDVersionPostingsFormat}} is loadable via SPI.
* Added the Solr core test library to {{map-reduce.iml}} so that class 
{{org.mortbay.jetty.Connector}} is loadable (from {{jetty-.jar}}, 
which is only located in {{solr/core/test-lib/}}).

I started getting OOM Permgen errors half-way through the solr core JUnit 
module run configuration (around 1,000/1,833 tests, all passing up to that 
point), not sure how to configure that, so I didn't change that.

> IntelliJ config: drop resource-only modules, add module groups, and add 
> module for lucene/backward-codecs
> -
>
> Key: LUCENE-5930
> URL: https://issues.apache.org/jira/browse/LUCENE-5930
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ryan Ernst
> Attachments: LUCENE-5930.patch, LUCENE-5930.patch, LUCENE-5930.patch
>
>
> The number of intellij modules is getting out of hand.  Intellij supports 
> marking subdirectories within a module as 
> source/resources/tests/test-resources.  I think we should consolidate these 
> modules so we have just one per lucene module.  Is there some reason I'm 
> missing that this was not done in the first place?



--
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-5930) IntelliJ config: drop resource-only modules, add module groups, and add module for lucene/backward-codecs

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated LUCENE-5930:
---
Summary: IntelliJ config: drop resource-only modules, add module groups, 
and add module for lucene/backward-codecs  (was: Change intellij setup to have 
1 module per lucene module instead of 3)

> IntelliJ config: drop resource-only modules, add module groups, and add 
> module for lucene/backward-codecs
> -
>
> Key: LUCENE-5930
> URL: https://issues.apache.org/jira/browse/LUCENE-5930
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ryan Ernst
> Attachments: LUCENE-5930.patch, LUCENE-5930.patch
>
>
> The number of intellij modules is getting out of hand.  Intellij supports 
> marking subdirectories within a module as 
> source/resources/tests/test-resources.  I think we should consolidate these 
> modules so we have just one per lucene module.  Is there some reason I'm 
> missing that this was not done in the first place?



--
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-5933) Add FilterSpans to allow easily wrapping a Spans impl

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129654#comment-14129654
 ] 

David Smiley commented on LUCENE-5933:
--

Not plural; existing span queries are "...Span...".  I guess I like 
SpanQueryWrapper.  "Wrapper" appears often in our classes.

> Add FilterSpans to allow easily wrapping a Spans impl
> -
>
> Key: LUCENE-5933
> URL: https://issues.apache.org/jira/browse/LUCENE-5933
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Shai Erera
>Assignee: Shai Erera
> Attachments: LUCNE-5933.patch
>
>
> I found this useful while working with spans recently. It's simple and 
> straightforward. I'll add a patch shortly.



--
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-6326) ExternalFileFieldReloader and commits

[Ramana (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129648#comment-14129648
 ] 

Ramana commented on SOLR-6326:
--

Hi,
I am trying to replicate the issue. I have configure below in schema.xml

In the "solrconfig.xml",  I added below listeners.

 
 




In my SOLR data directory, I created a file "external_testField"

After server start up, I am able to see the values using below URL:

 http://localhost:8983/solr/select?q={!func}testField&fl=id,score

But, when i changed the values.while the server is up and when refreshed the 
above URL..I am not able to see updated values.

I tried adding below request handler and invoked reload cache with URL 
http://localhost:8983/solr/reloadCache



I have also tried commit with below:
  http://localhost:8983/solr/update?commit=true

Still, I am not able to see the updated values. Please let me know how to 
reload the values when the server is up.

Thanks,
Ramana.


> ExternalFileFieldReloader and commits
> -
>
> Key: SOLR-6326
> URL: https://issues.apache.org/jira/browse/SOLR-6326
> Project: Solr
>  Issue Type: Bug
>Reporter: Peter Keegan
>  Labels: difficulty-medium, externalfilefield, impact-medium
>
> When there are multiple 'external file field' files available, Solr will 
> reload the last one (lexicographically) with a commit, but only if changes 
> were made to the index. Otherwise, it skips the reload and logs: "No 
> uncommitted changes. Skipping IW.commit." 
> IndexWriter.hasUncommittedChanges() returns false, but new external files 
> should be reloaded with commits.



--
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-5930) Change intellij setup to have 1 module per lucene module instead of 3

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129642#comment-14129642
 ] 

David Smiley commented on LUCENE-5930:
--

Nice; I'm looking forward to this!  The lengthy modules were getting out of 
hand.

> Change intellij setup to have 1 module per lucene module instead of 3
> -
>
> Key: LUCENE-5930
> URL: https://issues.apache.org/jira/browse/LUCENE-5930
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ryan Ernst
> Attachments: LUCENE-5930.patch, LUCENE-5930.patch
>
>
> The number of intellij modules is getting out of hand.  Intellij supports 
> marking subdirectories within a module as 
> source/resources/tests/test-resources.  I think we should consolidate these 
> modules so we have just one per lucene module.  Is there some reason I'm 
> missing that this was not done in the first place?



--
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] (SOLR-6497) Solr 4.10 returning SolrDocument instances with empty map when dynamic fields are requested

[Constantin Mitocaru (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-6497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Constantin Mitocaru resolved SOLR-6497.
---
Resolution: Duplicate

Duplicate of SOLR-6501

> Solr 4.10 returning SolrDocument instances with empty map when dynamic fields 
> are requested
> ---
>
> Key: SOLR-6497
> URL: https://issues.apache.org/jira/browse/SOLR-6497
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 4.10
> Environment: Windows 7, JDK8u11
>Reporter: Constantin Mitocaru
>Priority: Critical
>  Labels: patch
>
> I recently upgraded from Solr 4.9 to 4.10. At some point in the code I want 
> to return the values for some dynamic fields. If I do this:
> {code}
> SolrQuery query = new SolrQuery();
> query.addField("code");
> query.addField("name");
> {code}
> it returns the right values in the fields {{code}} and {{name}}.
> If I do this:
> {code}
> SolrQuery query = new SolrQuery();
> query.addField("code");
> query.addField("name");
> query.addField("*_prop");
> {code}
> all the fields ,including {{code}} and {{name}}, are {{null}}.



--
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-6497) Solr 4.10 returning SolrDocument instances with empty map when dynamic fields are requested

[Constantin Mitocaru (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129636#comment-14129636
 ] 

Constantin Mitocaru commented on SOLR-6497:
---

Yes, it's true. The thing is SOLR-6501 did not exist when I created this.

> Solr 4.10 returning SolrDocument instances with empty map when dynamic fields 
> are requested
> ---
>
> Key: SOLR-6497
> URL: https://issues.apache.org/jira/browse/SOLR-6497
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 4.10
> Environment: Windows 7, JDK8u11
>Reporter: Constantin Mitocaru
>Priority: Critical
>  Labels: patch
>
> I recently upgraded from Solr 4.9 to 4.10. At some point in the code I want 
> to return the values for some dynamic fields. If I do this:
> {code}
> SolrQuery query = new SolrQuery();
> query.addField("code");
> query.addField("name");
> {code}
> it returns the right values in the fields {{code}} and {{name}}.
> If I do this:
> {code}
> SolrQuery query = new SolrQuery();
> query.addField("code");
> query.addField("name");
> query.addField("*_prop");
> {code}
> all the fields ,including {{code}} and {{name}}, are {{null}}.



--
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-5925) Use rename instead of segments_N fallback / segments.gen etc

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129621#comment-14129621
 ] 

ASF subversion and git services commented on LUCENE-5925:
-

Commit 1624194 from [~rcmuir] in branch 'dev/trunk'
[ https://svn.apache.org/r1624194 ]

LUCENE-5925: use rename instead of segments_N fallback/segments.gen

> Use rename instead of segments_N fallback / segments.gen etc
> 
>
> Key: LUCENE-5925
> URL: https://issues.apache.org/jira/browse/LUCENE-5925
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index, core/store
>Reporter: Robert Muir
>  Labels: Java7
> Attachments: LUCENE-5925.patch, LUCENE-5925.patch
>
>
> Our commit logic is strange, we write corrupted commit points and only on the 
> last phase of commit do we "correct them".
> This means the logic to get the latest commit is always scary and awkward, 
> since it must deal with partial commits, and try to determine if it should 
> fall back to segments_N-1 or actually relay an exception. 
> This logic is incomplete/sheisty as we, e.g. i think we only fall back so far 
> (at most one).
> If we somehow screw up in all this logic do the wrong thing, then we lose 
> data (e.g. LUCENE-4870 wiped entire index because of TooManyOpenFiles).
> We now require java 7, i think we should expore instead writing 
> {{pending_segments_N}} and then in finishCommit() doing an atomic rename to 
> {{segments_N}}. 
> We could then remove all the complex fallback logic completely, since we no 
> longer have to deal with "ignoring partial commits", instead simply 
> delivering any exception we get when trying to read the commit and sleep 
> better at night.
> In java 7, we have the apis for this (ATOMIC_MOVE).



--
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-6441) MoreLikeThis support for stopwords as in Lucene

[Ramana (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-6441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ramana updated SOLR-6441:
-
Attachment: SOLR-6441.patch

Attached is the path. Now, MoreLikeThisHandler implements SolrCoreAware 
interface and in the inform method, loading the existing stopwords_en file and 
converting to set of stopwords. For each mlt request, setting the stopwords to 
Lucene "MoreLikeThis" API. With this, In the "addTermFrequencies" method of 
"MoreLikeThis" all the stop words will be ignored while building the 
termFreqMap.

> MoreLikeThis support for stopwords as in Lucene
> ---
>
> Key: SOLR-6441
> URL: https://issues.apache.org/jira/browse/SOLR-6441
> Project: Solr
>  Issue Type: Improvement
>  Components: MoreLikeThis
>Affects Versions: 4.9
>Reporter: Jeroen Steggink
>Priority: Minor
>  Labels: difficulty-easy, impact-low, workaround-exists
> Fix For: 4.10, 4.11
>
> Attachments: SOLR-6441.patch
>
>
> In the Lucene implementation of MoreLikeThis, it's possible to add a list of 
> stopwords which are considered "uninteresting" and are ignored.
> It would be a great addition to the MoreLikeThisHandler to be able to specify 
> a list of stopwords.



--
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] [Closed] (SOLR-6505) UnsupportedClassVersionError 51.0 when using Solr 4.7.2 and DataImportHandler

[Rafael Brizola (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-6505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Brizola closed SOLR-6505.

Resolution: Invalid

> UnsupportedClassVersionError 51.0 when using Solr 4.7.2 and DataImportHandler
> -
>
> Key: SOLR-6505
> URL: https://issues.apache.org/jira/browse/SOLR-6505
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.7.2
> Environment: RHEL5, java version "1.6.0_24"
>Reporter: Rafael Brizola
>
> Hi. We are restrict to use java 6 in our servers. When I start Solr 4.7.2, it 
> starts without any problem. However, when I configure the DataImportHandler 
> in solrconfig.xml I got the error:
> ... 10 more
> Caused by: java.lang.UnsupportedClassVersionError: 
> org/apache/solr/handler/dataimport/DataImportHandler : Unsupported 
> major.minor version 51.0
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
> at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
> at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
> at java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java:627)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:247)
> at 
> org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:454)
> at 
> org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:401)
> at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:531)
> at 
> org.apache.solr.core.SolrCore.createRequestHandler(SolrCore.java:604)
> at 
> org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:153)
> at org.apache.solr.core.SolrCore.(SolrCore.java:774)
> ... 13 more
> In the solr documentation page 
> (http://archive.apache.org/dist/lucene/solr/4.7.2/changes/Changes.html) is 
> written that it works with java 6.
> Thanks.



--
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] (SOLR-6499) Log warning about multiple update request handlers

[Noble Paul (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Noble Paul resolved SOLR-6499.
--
   Resolution: Fixed
Fix Version/s: 5.0
   4.11

> Log warning about multiple update request handlers
> --
>
> Key: SOLR-6499
> URL: https://issues.apache.org/jira/browse/SOLR-6499
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10
>Reporter: Andreas Hubold
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 4.11, 5.0
>
> Attachments: SOLR-6499.patch
>
>
> Solr 4.10.0 logs the following warning upon startup:
> {noformat}
> WARN  - 2014-09-09 17:49:11.455; org.apache.solr.core.RequestHandlers; 
> Multiple requestHandler registered to the same name: /update ignoring: 
> org.apache.solr.handler.UpdateRequestHandler
> {noformat}
> I've just started the Solr example with {{bin/solr start}} to get this 
> warning in {{example/logs/solr.log}}
> I don't know if this indicates a real problem but it seems everything works 
> fine despite the warning.



--
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-6499) Log warning about multiple update request handlers

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129531#comment-14129531
 ] 

ASF subversion and git services commented on SOLR-6499:
---

Commit 1624183 from [~noble.paul] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1624183 ]

SOLR-6499

> Log warning about multiple update request handlers
> --
>
> Key: SOLR-6499
> URL: https://issues.apache.org/jira/browse/SOLR-6499
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10
>Reporter: Andreas Hubold
>Assignee: Noble Paul
>Priority: Minor
> Attachments: SOLR-6499.patch
>
>
> Solr 4.10.0 logs the following warning upon startup:
> {noformat}
> WARN  - 2014-09-09 17:49:11.455; org.apache.solr.core.RequestHandlers; 
> Multiple requestHandler registered to the same name: /update ignoring: 
> org.apache.solr.handler.UpdateRequestHandler
> {noformat}
> I've just started the Solr example with {{bin/solr start}} to get this 
> warning in {{example/logs/solr.log}}
> I don't know if this indicates a real problem but it seems everything works 
> fine despite the warning.



--
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-6499) Log warning about multiple update request handlers

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129529#comment-14129529
 ] 

ASF subversion and git services commented on SOLR-6499:
---

Commit 1624182 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1624182 ]

SOLR-6499

> Log warning about multiple update request handlers
> --
>
> Key: SOLR-6499
> URL: https://issues.apache.org/jira/browse/SOLR-6499
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10
>Reporter: Andreas Hubold
>Assignee: Noble Paul
>Priority: Minor
> Attachments: SOLR-6499.patch
>
>
> Solr 4.10.0 logs the following warning upon startup:
> {noformat}
> WARN  - 2014-09-09 17:49:11.455; org.apache.solr.core.RequestHandlers; 
> Multiple requestHandler registered to the same name: /update ignoring: 
> org.apache.solr.handler.UpdateRequestHandler
> {noformat}
> I've just started the Solr example with {{bin/solr start}} to get this 
> warning in {{example/logs/solr.log}}
> I don't know if this indicates a real problem but it seems everything works 
> fine despite the warning.



--
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-6505) UnsupportedClassVersionError 51.0 when using Solr 4.7.2 and DataImportHandler

[Rafael Brizola (JIRA)]

Rafael Brizola created SOLR-6505:


 Summary: UnsupportedClassVersionError 51.0 when using Solr 4.7.2 
and DataImportHandler
 Key: SOLR-6505
 URL: https://issues.apache.org/jira/browse/SOLR-6505
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.7.2
 Environment: RHEL5, java version "1.6.0_24"
Reporter: Rafael Brizola


Hi. We are restrict to use java 6 in our servers. When I start Solr 4.7.2, it 
starts without any problem. However, when I configure the DataImportHandler in 
solrconfig.xml I got the error:

... 10 more
Caused by: java.lang.UnsupportedClassVersionError: 
org/apache/solr/handler/dataimport/DataImportHandler : Unsupported major.minor 
version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java:627)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at 
org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:454)
at 
org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:401)
at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:531)
at org.apache.solr.core.SolrCore.createRequestHandler(SolrCore.java:604)
at 
org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:153)
at org.apache.solr.core.SolrCore.(SolrCore.java:774)
... 13 more

In the solr documentation page 
(http://archive.apache.org/dist/lucene/solr/4.7.2/changes/Changes.html) is 
written that it works with java 6.

Thanks.



--
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-6499) Log warning about multiple update request handlers

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129519#comment-14129519
 ] 

ASF subversion and git services commented on SOLR-6499:
---

Commit 1624181 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1624181 ]

SOLR-6499

> Log warning about multiple update request handlers
> --
>
> Key: SOLR-6499
> URL: https://issues.apache.org/jira/browse/SOLR-6499
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10
>Reporter: Andreas Hubold
>Assignee: Noble Paul
>Priority: Minor
> Attachments: SOLR-6499.patch
>
>
> Solr 4.10.0 logs the following warning upon startup:
> {noformat}
> WARN  - 2014-09-09 17:49:11.455; org.apache.solr.core.RequestHandlers; 
> Multiple requestHandler registered to the same name: /update ignoring: 
> org.apache.solr.handler.UpdateRequestHandler
> {noformat}
> I've just started the Solr example with {{bin/solr start}} to get this 
> warning in {{example/logs/solr.log}}
> I don't know if this indicates a real problem but it seems everything works 
> fine despite the warning.



--
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

4.10.1

[Robert Muir]

I plan on spinning an RC for
https://issues.apache.org/jira/browse/LUCENE-5934 tomorrow.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-6499) Log warning about multiple update request handlers

[Noble Paul (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Noble Paul updated SOLR-6499:
-
Attachment: SOLR-6499.patch

> Log warning about multiple update request handlers
> --
>
> Key: SOLR-6499
> URL: https://issues.apache.org/jira/browse/SOLR-6499
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10
>Reporter: Andreas Hubold
>Assignee: Noble Paul
>Priority: Minor
> Attachments: SOLR-6499.patch
>
>
> Solr 4.10.0 logs the following warning upon startup:
> {noformat}
> WARN  - 2014-09-09 17:49:11.455; org.apache.solr.core.RequestHandlers; 
> Multiple requestHandler registered to the same name: /update ignoring: 
> org.apache.solr.handler.UpdateRequestHandler
> {noformat}
> I've just started the Solr example with {{bin/solr start}} to get this 
> warning in {{example/logs/solr.log}}
> I don't know if this indicates a real problem but it seems everything works 
> fine despite the warning.



--
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-6499) Log warning about multiple update request handlers

[Noble Paul (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129473#comment-14129473
 ] 

Noble Paul commented on SOLR-6499:
--

I shall fix this right away

> Log warning about multiple update request handlers
> --
>
> Key: SOLR-6499
> URL: https://issues.apache.org/jira/browse/SOLR-6499
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10
>Reporter: Andreas Hubold
>Assignee: Noble Paul
>Priority: Minor
>
> Solr 4.10.0 logs the following warning upon startup:
> {noformat}
> WARN  - 2014-09-09 17:49:11.455; org.apache.solr.core.RequestHandlers; 
> Multiple requestHandler registered to the same name: /update ignoring: 
> org.apache.solr.handler.UpdateRequestHandler
> {noformat}
> I've just started the Solr example with {{bin/solr start}} to get this 
> warning in {{example/logs/solr.log}}
> I don't know if this indicates a real problem but it seems everything works 
> fine despite the warning.



--
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-5931) DirectoryReader.openIfChanged(oldReader, commit) incorrectly assumes given commit point has deletes/field updates

[Robert Muir (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir updated LUCENE-5931:

Attachment: LUCENE-5931.patch

Patch: I think the use-case is cool and it should be supported: its just adding 
an 'if' and removing the current exception (which is geared at protecting some 
user who manually rm -rf's files from their index.)

I improved the test a bit to ensure that cores are shared and also tested the 
dv updates case.

> DirectoryReader.openIfChanged(oldReader, commit) incorrectly assumes given 
> commit point has deletes/field updates
> -
>
> Key: LUCENE-5931
> URL: https://issues.apache.org/jira/browse/LUCENE-5931
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 4.6.1
>Reporter: Vitaly Funstein
>Assignee: Michael McCandless
>Priority: Critical
> Attachments: CommitReuseTest.java, LUCENE-5931.patch, 
> LUCENE-5931.patch
>
>
> {{StandardDirectoryReader}} assumes that the segments from commit point have 
> deletes, when they may not, yet the original SegmentReader for the segment 
> that we are trying to reuse does. This is evident when running attached JUnit 
> test case with asserts enabled (default): 
> {noformat}
> java.lang.AssertionError
>   at 
> org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:188)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:326)
>   at 
> org.apache.lucene.index.StandardDirectoryReader$2.doBody(StandardDirectoryReader.java:320)
>   at 
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:702)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenFromCommit(StandardDirectoryReader.java:315)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenNoWriter(StandardDirectoryReader.java:311)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:262)
>   at 
> org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:183)
> {noformat}
> or, if asserts are disabled then it falls through into NPE:
> {noformat}
> java.lang.NullPointerException
>   at java.io.File.(File.java:305)
>   at 
> org.apache.lucene.store.NIOFSDirectory.openInput(NIOFSDirectory.java:80)
>   at 
> org.apache.lucene.codecs.lucene40.BitVector.(BitVector.java:327)
>   at 
> org.apache.lucene.codecs.lucene40.Lucene40LiveDocsFormat.readLiveDocs(Lucene40LiveDocsFormat.java:90)
>   at org.apache.lucene.index.SegmentReader.(SegmentReader.java:131)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:194)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:326)
>   at 
> org.apache.lucene.index.StandardDirectoryReader$2.doBody(StandardDirectoryReader.java:320)
>   at 
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:702)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenFromCommit(StandardDirectoryReader.java:315)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenNoWriter(StandardDirectoryReader.java:311)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:262)
>   at 
> org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:183)
> {noformat}



--
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-trunk-Linux (64bit/jdk1.8.0_40-ea-b04) - Build # 11220 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11220/
Java: 64bit/jdk1.8.0_40-ea-b04 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  org.apache.lucene.index.TestIndexWriter.testThreadInterruptDeadlock

Error Message:
Captured an uncaught exception in thread: Thread[id=812, name=Thread-601, 
state=RUNNABLE, group=TGRP-TestIndexWriter]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=812, name=Thread-601, state=RUNNABLE, 
group=TGRP-TestIndexWriter]
at 
__randomizedtesting.SeedInfo.seed([A1F99B49A36545D4:EF57CB33C9F5AED8]:0)
Caused by: java.lang.OutOfMemoryError: Java heap space
at __randomizedtesting.SeedInfo.seed([A1F99B49A36545D4]:0)
at java.util.Arrays.copyOf(Arrays.java:3236)
at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:113)
at 
java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:140)
at java.io.PrintStream.write(PrintStream.java:480)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
at java.io.PrintStream.write(PrintStream.java:527)
at java.io.PrintStream.print(PrintStream.java:669)
at java.io.PrintStream.println(PrintStream.java:806)
at 
org.apache.lucene.index.TestIndexWriter$IndexerThreadInterrupt.listIndexFiles(TestIndexWriter.java:1229)
at 
org.apache.lucene.index.TestIndexWriter$IndexerThreadInterrupt.run(TestIndexWriter.java:1171)


FAILED:  org.apache.lucene.index.TestIndexWriter.testTwoThreadsInterruptDeadlock

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space




Build Log:
[...truncated 724 lines...]
   [junit4] Suite: org.apache.lucene.index.TestIndexWriter
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestIndexWriter 
-Dtests.method=testThreadInterruptDeadlock -Dtests.seed=A1F99B49A36545D4 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=mk 
-Dtests.timezone=America/Bogota -Dtests.file.encoding=UTF-8
   [junit4] ERROR   6.44s J1 | TestIndexWriter.testThreadInterruptDeadlock <<<
   [junit4]> Throwable #1: 
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=812, name=Thread-601, state=RUNNABLE, 
group=TGRP-TestIndexWriter]
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([A1F99B49A36545D4:EF57CB33C9F5AED8]:0)
   [junit4]> Caused by: java.lang.OutOfMemoryError: Java heap space
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([A1F99B49A36545D4]:0)
   [junit4]>at java.util.Arrays.copyOf(Arrays.java:3236)
   [junit4]>at 
java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:113)
   [junit4]>at 
java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
   [junit4]>at 
java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:140)
   [junit4]>at java.io.PrintStream.write(PrintStream.java:480)
   [junit4]>at 
sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
   [junit4]>at 
sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
   [junit4]>at 
sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
   [junit4]>at 
java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
   [junit4]>at java.io.PrintStream.write(PrintStream.java:527)
   [junit4]>at java.io.PrintStream.print(PrintStream.java:669)
   [junit4]>at java.io.PrintStream.println(PrintStream.java:806)
   [junit4]>at 
org.apache.lucene.index.TestIndexWriter$IndexerThreadInterrupt.listIndexFiles(TestIndexWriter.java:1229)
   [junit4]>at 
org.apache.lucene.index.TestIndexWriter$IndexerThreadInterrupt.run(TestIndexWriter.java:1171)
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestIndexWriter 
-Dtests.method=testTwoThreadsInterruptDeadlock -Dtests.seed=A1F99B49A36545D4 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=mk 
-Dtests.timezone=America/Bogota -Dtests.file.encoding=UTF-8
   [junit4] ERROR   7.57s J1 | TestIndexWriter.testTwoThreadsInterruptDeadlock 
<<<
   [junit4]> Throwable #1: java.lang.OutOfMemoryError: Java heap 
spaceThrowable #2: com.carrotsearch.randomizedtesting.UncaughtExceptionError: 
Captured an uncaught exception in thread: Thread[id=822, name=Thread-611, 
state=RUNNABLE, group=TGRP-TestIndexWriter]
   [junit4]> Caused by: java.lang.OutOfMemoryError: Java heap 
spaceThrowable #3: com.carrotsearch.randomizedtesting.UncaughtExceptionError: 
Captured an uncau

Re: svn commit: r1624108 - /lucene/dev/trunk/lucene/core/src/test/org/apache/lucene/index/TestIndexWriter.java

[Robert Muir]

I'm hitting many OOMs because of this. Can we do this in a different way?

It costs a lot of time when it fails because there is a "bad apple"
test in TestIndexWriter that makes thousands of fields and blows up my
console with megabytes of shit... we should pull that test out of
TestIndexWriter.

On Wed, Sep 10, 2014 at 4:16 PM,   wrote:
> Author: mikemccand
> Date: Wed Sep 10 20:16:34 2014
> New Revision: 1624108
>
> URL: http://svn.apache.org/r1624108
> Log:
> improve test debuggability
>
> Modified:
> 
> lucene/dev/trunk/lucene/core/src/test/org/apache/lucene/index/TestIndexWriter.java
>
> Modified: 
> lucene/dev/trunk/lucene/core/src/test/org/apache/lucene/index/TestIndexWriter.java
> URL: 
> http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/core/src/test/org/apache/lucene/index/TestIndexWriter.java?rev=1624108&r1=1624107&r2=1624108&view=diff
> ==
> --- 
> lucene/dev/trunk/lucene/core/src/test/org/apache/lucene/index/TestIndexWriter.java
>  (original)
> +++ 
> lucene/dev/trunk/lucene/core/src/test/org/apache/lucene/index/TestIndexWriter.java
>  Wed Sep 10 20:16:34 2014
> @@ -1087,6 +1087,7 @@ public class TestIndexWriter extends Luc
>  }
>  IndexWriterConfig conf = newIndexWriterConfig(random,
>new 
> MockAnalyzer(random)).setMaxBufferedDocs(2);
> +conf.setInfoStream(log);
>  w = new IndexWriter(dir, conf);
>
>  Document doc = new Document();
> @@ -1102,6 +1103,7 @@ public class TestIndexWriter extends Luc
>  doc.add(sortedDVField);
>  doc.add(sortedSetDVField);
>  for(int i=0;i<100;i++) {
> +  log.println("\nTEST: i=" + i);
>idField.setStringValue(Integer.toString(i));
>binaryDVField.setBytesValue(new 
> BytesRef(idField.stringValue()));
>numericDVField.setLongValue(i);
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-5930) Change intellij setup to have 1 module per lucene module instead of 3

[Ryan Ernst (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Ernst updated LUCENE-5930:
---
Attachment: LUCENE-5930.patch

New patch, without the trunk diffs.

> Change intellij setup to have 1 module per lucene module instead of 3
> -
>
> Key: LUCENE-5930
> URL: https://issues.apache.org/jira/browse/LUCENE-5930
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ryan Ernst
> Attachments: LUCENE-5930.patch, LUCENE-5930.patch
>
>
> The number of intellij modules is getting out of hand.  Intellij supports 
> marking subdirectories within a module as 
> source/resources/tests/test-resources.  I think we should consolidate these 
> modules so we have just one per lucene module.  Is there some reason I'm 
> missing that this was not done in the first place?



--
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-5930) Change intellij setup to have 1 module per lucene module instead of 3

[Ryan Ernst (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129434#comment-14129434
 ] 

Ryan Ernst commented on LUCENE-5930:


Oops sorry. The problem is my trunk was more up to date than the branch. I will 
upload a new patch as soon as I can get back online. 

> Change intellij setup to have 1 module per lucene module instead of 3
> -
>
> Key: LUCENE-5930
> URL: https://issues.apache.org/jira/browse/LUCENE-5930
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ryan Ernst
> Attachments: LUCENE-5930.patch
>
>
> The number of intellij modules is getting out of hand.  Intellij supports 
> marking subdirectories within a module as 
> source/resources/tests/test-resources.  I think we should consolidate these 
> modules so we have just one per lucene module.  Is there some reason I'm 
> missing that this was not done in the first place?



--
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-5930) Change intellij setup to have 1 module per lucene module instead of 3

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129428#comment-14129428
 ] 

Steve Rowe commented on LUCENE-5930:


[~rjernst], looks like you've got some unrelated changes in the patch: 
lucene/CHANGES.txt, solr/CHANGES.txt, 
lucene/backward-codecs/src/test/org/apache/lucene/index/TestBackwardsCompatibility.java,
 etc.

I'll see if I can figure out what doesn't belong and revert those locally.

> Change intellij setup to have 1 module per lucene module instead of 3
> -
>
> Key: LUCENE-5930
> URL: https://issues.apache.org/jira/browse/LUCENE-5930
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ryan Ernst
> Attachments: LUCENE-5930.patch
>
>
> The number of intellij modules is getting out of hand.  Intellij supports 
> marking subdirectories within a module as 
> source/resources/tests/test-resources.  I think we should consolidate these 
> modules so we have just one per lucene module.  Is there some reason I'm 
> missing that this was not done in the first place?



--
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-6066) CollapsingQParserPlugin + Elevation does not respects "fq" (filter query)

[David Boychuck (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129422#comment-14129422
 ] 

David Boychuck commented on SOLR-6066:
--

Got it patched in... my earlier comments about an error should be disregarded. 
I was doing the tests in a bad order. I'll report back if I find any more 
trouble.

> CollapsingQParserPlugin + Elevation does not respects "fq" (filter query) 
> --
>
> Key: SOLR-6066
> URL: https://issues.apache.org/jira/browse/SOLR-6066
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 4.8
>Reporter: Herb Jiang
>Assignee: Joel Bernstein
> Fix For: 4.9
>
> Attachments: SOLR-6066.patch, SOLR-6066.patch, SOLR-6066.patch, 
> TestCollapseQParserPlugin.java
>
>
> QueryElevationComponent respects the "fq" parameter. But when use 
> CollapsingQParserPlugin with QueryElevationComponent, additional "fq" has no 
> effect.
> I use following test case to show this issue. (It will failed)
> {code:java}
> String[] doc = {"id","1", "term_s", "", "group_s", "group1", 
> "category_s", "cat2", "test_ti", "5", "test_tl", "10", "test_tf", "2000"};
> assertU(adoc(doc));
> assertU(commit());
> String[] doc1 = {"id","2", "term_s","", "group_s", "group1", 
> "category_s", "cat2", "test_ti", "50", "test_tl", "100", "test_tf", "200"};
> assertU(adoc(doc1));
> String[] doc2 = {"id","3", "term_s", "", "test_ti", "5000", 
> "test_tl", "100", "test_tf", "200"};
> assertU(adoc(doc2));
> assertU(commit());
> String[] doc3 = {"id","4", "term_s", "", "test_ti", "500", "test_tl", 
> "1000", "test_tf", "2000"};
> assertU(adoc(doc3));
> String[] doc4 = {"id","5", "term_s", "", "group_s", "group2", 
> "category_s", "cat1", "test_ti", "4", "test_tl", "10", "test_tf", "2000"};
> assertU(adoc(doc4));
> assertU(commit());
> String[] doc5 = {"id","6", "term_s","", "group_s", "group2", 
> "category_s", "cat1", "test_ti", "10", "test_tl", "100", "test_tf", "200"};
> assertU(adoc(doc5));
> assertU(commit());
> //Test additional filter query when using collapse
> params = new ModifiableSolrParams();
> params.add("q", "");
> params.add("fq", "{!collapse field=group_s}");
> params.add("fq", "category_s:cat1");
> params.add("defType", "edismax");
> params.add("bf", "field(test_ti)");
> params.add("qf", "term_s");
> params.add("qt", "/elevate");
> params.add("elevateIds", "2");
> assertQ(req(params), "*[count(//doc)=1]",
> "//result/doc[1]/float[@name='id'][.='6.0']");
> {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] [Issue Comment Deleted] (SOLR-6066) CollapsingQParserPlugin + Elevation does not respects "fq" (filter query)

[David Boychuck (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Boychuck updated SOLR-6066:
-
Comment: was deleted

(was: I added the code from SOLR-6029 but the test provided fails because the 
nullPolicy documents are not grouped with or without elevation after the 
documents are deleted. I am not sure why. My testing was done on 4.7.2

{code}
// delete the elevated docs, confirm collapsing still works
assertU(delI("1"));
assertU(delI("2"));
assertU(commit());
params = new ModifiableSolrParams();
params.add("q", "");
params.add("fq", "{!collapse field=group_s nullPolicy=collapse}");
params.add("defType", "edismax");
params.add("bf", "field(test_ti)");
params.add("qf", "term_s");
//params.add("qt", "/elevate");
assertQ(req(params), "*[count(//doc)=2]",
"//result/doc[1]/float[@name='id'][.='3.0']",
"//result/doc[2]/float[@name='id'][.='6.0']");
{code}

{code}

053.05000100200.014789046109659463684.050010002000.014789046109827235846.0group210100200.01478904610996355072

{code})

> CollapsingQParserPlugin + Elevation does not respects "fq" (filter query) 
> --
>
> Key: SOLR-6066
> URL: https://issues.apache.org/jira/browse/SOLR-6066
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 4.8
>Reporter: Herb Jiang
>Assignee: Joel Bernstein
> Fix For: 4.9
>
> Attachments: SOLR-6066.patch, SOLR-6066.patch, SOLR-6066.patch, 
> TestCollapseQParserPlugin.java
>
>
> QueryElevationComponent respects the "fq" parameter. But when use 
> CollapsingQParserPlugin with QueryElevationComponent, additional "fq" has no 
> effect.
> I use following test case to show this issue. (It will failed)
> {code:java}
> String[] doc = {"id","1", "term_s", "", "group_s", "group1", 
> "category_s", "cat2", "test_ti", "5", "test_tl", "10", "test_tf", "2000"};
> assertU(adoc(doc));
> assertU(commit());
> String[] doc1 = {"id","2", "term_s","", "group_s", "group1", 
> "category_s", "cat2", "test_ti", "50", "test_tl", "100", "test_tf", "200"};
> assertU(adoc(doc1));
> String[] doc2 = {"id","3", "term_s", "", "test_ti", "5000", 
> "test_tl", "100", "test_tf", "200"};
> assertU(adoc(doc2));
> assertU(commit());
> String[] doc3 = {"id","4", "term_s", "", "test_ti", "500", "test_tl", 
> "1000", "test_tf", "2000"};
> assertU(adoc(doc3));
> String[] doc4 = {"id","5", "term_s", "", "group_s", "group2", 
> "category_s", "cat1", "test_ti", "4", "test_tl", "10", "test_tf", "2000"};
> assertU(adoc(doc4));
> assertU(commit());
> String[] doc5 = {"id","6", "term_s","", "group_s", "group2", 
> "category_s", "cat1", "test_ti", "10", "test_tl", "100", "test_tf", "200"};
> assertU(adoc(doc5));
> assertU(commit());
> //Test additional filter query when using collapse
> params = new ModifiableSolrParams();
> params.add("q", "");
> params.add("fq", "{!collapse field=group_s}");
> params.add("fq", "category_s:cat1");
> params.add("defType", "edismax");
> params.add("bf", "field(test_ti)");
> params.add("qf", "term_s");
> params.add("qt", "/elevate");
> params.add("elevateIds", "2");
> assertQ(req(params), "*[count(//doc)=1]",
> "//result/doc[1]/float[@name='id'][.='6.0']");
> {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] [Comment Edited] (SOLR-6066) CollapsingQParserPlugin + Elevation does not respects "fq" (filter query)

[David Boychuck (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129394#comment-14129394
 ] 

David Boychuck edited comment on SOLR-6066 at 9/11/14 12:15 AM:


I added the code from SOLR-6029 but the test provided fails because the 
nullPolicy documents are not grouped with or without elevation after the 
documents are deleted. I am not sure why. My testing was done on 4.7.2

{code}
// delete the elevated docs, confirm collapsing still works
assertU(delI("1"));
assertU(delI("2"));
assertU(commit());
params = new ModifiableSolrParams();
params.add("q", "");
params.add("fq", "{!collapse field=group_s nullPolicy=collapse}");
params.add("defType", "edismax");
params.add("bf", "field(test_ti)");
params.add("qf", "term_s");
//params.add("qt", "/elevate");
assertQ(req(params), "*[count(//doc)=2]",
"//result/doc[1]/float[@name='id'][.='3.0']",
"//result/doc[2]/float[@name='id'][.='6.0']");
{code}

{code}

053.05000100200.014789046109659463684.050010002000.014789046109827235846.0group210100200.01478904610996355072

{code}


was (Author: dboychuck):
I added the code from SOLR-6029 but the test provided fails because the 
nullPolicy documents are not grouped with or without elevation. I am not sure 
why. My testing was done on 4.7.2

{code}
// delete the elevated docs, confirm collapsing still works
assertU(delI("1"));
assertU(delI("2"));
assertU(commit());
params = new ModifiableSolrParams();
params.add("q", "");
params.add("fq", "{!collapse field=group_s nullPolicy=collapse}");
params.add("defType", "edismax");
params.add("bf", "field(test_ti)");
params.add("qf", "term_s");
//params.add("qt", "/elevate");
assertQ(req(params), "*[count(//doc)=2]",
"//result/doc[1]/float[@name='id'][.='3.0']",
"//result/doc[2]/float[@name='id'][.='6.0']");
{code}

{code}

053.05000100200.014789046109659463684.050010002000.014789046109827235846.0group210100200.01478904610996355072

{code}

> CollapsingQParserPlugin + Elevation does not respects "fq" (filter query) 
> --
>
> Key: SOLR-6066
> URL: https://issues.apache.org/jira/browse/SOLR-6066
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 4.8
>Reporter: Herb Jiang
>Assignee: Joel Bernstein
> Fix For: 4.9
>
> Attachments: SOLR-6066.patch, SOLR-6066.patch, SOLR-6066.patch, 
> TestCollapseQParserPlugin.java
>
>
> QueryElevationComponent respects the "fq" parameter. But when use 
> CollapsingQParserPlugin with QueryElevationComponent, additional "fq" has no 
> effect.
> I use following test case to show this issue. (It will failed)
> {code:java}
> String[] doc = {"id","1", "term_s", "", "group_s", "group1", 
> "category_s", "cat2", "test_ti", "5", "test_tl", "10", "test_tf", "2000"};
> assertU(adoc(doc));
> assertU(commit());
> String[] doc1 = {"id","2", "term_s","", "group_s", "group1", 
> "category_s", "cat2", "test_ti", "50", "test_tl", "100", "test_tf", "200"};
> assertU(adoc(doc1));
> String[] doc2 = {"id","3", "term_s", "", "test_ti", "5000", 
> "test_tl", "100", "test_tf", "200"};
> assertU(adoc(doc2));
> assertU(commit());
> String[] doc3 = {"id","4", "term_s", "", "test_ti", "500", "test_tl", 
> "1000", "test_tf", "2000"};
> assertU(adoc(doc3));
> String[] doc4 = {"id","5", "term_s", "", "group_s", "group2", 
> "category_s", "cat1", "test_ti", "4", "test_tl", "10", "test_tf", "2000"};
> assertU(adoc(doc4));
> assertU(commit());
> String[] doc5 = {"id","6", "term_s","", "group_s", "group2", 
> "category_s", "cat1", "test_ti", "10", "test_tl", "100", "test_tf", "200"};
> assertU(adoc(doc5));
> assertU(commit());
> //Test additional filter query when using collapse
> params = new ModifiableSolrParams();
> params.add("q", "");
> params.add("fq", "{!collapse field=group_s}");
> params.add("fq", "category_s:cat1");
> params.add("defType", "edismax");
> params.add("bf", "field(test_ti)");
> params.add("qf", "term_s");
> params.add("qt", "/elevate");
> params.add("elevateIds", "2");
> assertQ(req(params), "*[count(//doc)=1]",
> "//result/doc[1]/float[@name='id'][.='6.0']");
> {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] [Comment Edited] (SOLR-6066) CollapsingQParserPlugin + Elevation does not respects "fq" (filter query)

[David Boychuck (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129394#comment-14129394
 ] 

David Boychuck edited comment on SOLR-6066 at 9/11/14 12:14 AM:


I added the code from SOLR-6029 but the test provided fails because the 
nullPolicy documents are not grouped with or without elevation. I am not sure 
why. My testing was done on 4.7.2

{code}
// delete the elevated docs, confirm collapsing still works
assertU(delI("1"));
assertU(delI("2"));
assertU(commit());
params = new ModifiableSolrParams();
params.add("q", "");
params.add("fq", "{!collapse field=group_s nullPolicy=collapse}");
params.add("defType", "edismax");
params.add("bf", "field(test_ti)");
params.add("qf", "term_s");
//params.add("qt", "/elevate");
assertQ(req(params), "*[count(//doc)=2]",
"//result/doc[1]/float[@name='id'][.='3.0']",
"//result/doc[2]/float[@name='id'][.='6.0']");
{code}

{code}

053.05000100200.014789046109659463684.050010002000.014789046109827235846.0group210100200.01478904610996355072

{code}


was (Author: dboychuck):
I added the code from SOLR-6029 but the test provided fails because the 
nullPolicy documents are not grouped with or without elevation. I am not sure 
why.

{code}
// delete the elevated docs, confirm collapsing still works
assertU(delI("1"));
assertU(delI("2"));
assertU(commit());
params = new ModifiableSolrParams();
params.add("q", "");
params.add("fq", "{!collapse field=group_s nullPolicy=collapse}");
params.add("defType", "edismax");
params.add("bf", "field(test_ti)");
params.add("qf", "term_s");
//params.add("qt", "/elevate");
assertQ(req(params), "*[count(//doc)=2]",
"//result/doc[1]/float[@name='id'][.='3.0']",
"//result/doc[2]/float[@name='id'][.='6.0']");
{code}

{code}

053.05000100200.014789046109659463684.050010002000.014789046109827235846.0group210100200.01478904610996355072

{code}

> CollapsingQParserPlugin + Elevation does not respects "fq" (filter query) 
> --
>
> Key: SOLR-6066
> URL: https://issues.apache.org/jira/browse/SOLR-6066
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 4.8
>Reporter: Herb Jiang
>Assignee: Joel Bernstein
> Fix For: 4.9
>
> Attachments: SOLR-6066.patch, SOLR-6066.patch, SOLR-6066.patch, 
> TestCollapseQParserPlugin.java
>
>
> QueryElevationComponent respects the "fq" parameter. But when use 
> CollapsingQParserPlugin with QueryElevationComponent, additional "fq" has no 
> effect.
> I use following test case to show this issue. (It will failed)
> {code:java}
> String[] doc = {"id","1", "term_s", "", "group_s", "group1", 
> "category_s", "cat2", "test_ti", "5", "test_tl", "10", "test_tf", "2000"};
> assertU(adoc(doc));
> assertU(commit());
> String[] doc1 = {"id","2", "term_s","", "group_s", "group1", 
> "category_s", "cat2", "test_ti", "50", "test_tl", "100", "test_tf", "200"};
> assertU(adoc(doc1));
> String[] doc2 = {"id","3", "term_s", "", "test_ti", "5000", 
> "test_tl", "100", "test_tf", "200"};
> assertU(adoc(doc2));
> assertU(commit());
> String[] doc3 = {"id","4", "term_s", "", "test_ti", "500", "test_tl", 
> "1000", "test_tf", "2000"};
> assertU(adoc(doc3));
> String[] doc4 = {"id","5", "term_s", "", "group_s", "group2", 
> "category_s", "cat1", "test_ti", "4", "test_tl", "10", "test_tf", "2000"};
> assertU(adoc(doc4));
> assertU(commit());
> String[] doc5 = {"id","6", "term_s","", "group_s", "group2", 
> "category_s", "cat1", "test_ti", "10", "test_tl", "100", "test_tf", "200"};
> assertU(adoc(doc5));
> assertU(commit());
> //Test additional filter query when using collapse
> params = new ModifiableSolrParams();
> params.add("q", "");
> params.add("fq", "{!collapse field=group_s}");
> params.add("fq", "category_s:cat1");
> params.add("defType", "edismax");
> params.add("bf", "field(test_ti)");
> params.add("qf", "term_s");
> params.add("qt", "/elevate");
> params.add("elevateIds", "2");
> assertQ(req(params), "*[count(//doc)=1]",
> "//result/doc[1]/float[@name='id'][.='6.0']");
> {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-5930) Change intellij setup to have 1 module per lucene module instead of 3

[Ryan Ernst (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Ernst updated LUCENE-5930:
---
Attachment: LUCENE-5930.patch

This patch does the following:
* Adds group Lucene with subgroups Analysis, Core, and Other
* Adds group Solr with subgroup Contrib
* Adds module for backward-codecs (will not be there for backport to 4x)
* Conslidate lucene-core, codecs, solr-core and solrj to include their 
resources, removing the previous resource specific modules.

Steve, if you could try this out, I was having trouble getting solrj tests to 
run within intellij (fails to compile not finding lucene core stuff). So I 
probably have a bug in this somewhere.

> Change intellij setup to have 1 module per lucene module instead of 3
> -
>
> Key: LUCENE-5930
> URL: https://issues.apache.org/jira/browse/LUCENE-5930
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ryan Ernst
> Attachments: LUCENE-5930.patch
>
>
> The number of intellij modules is getting out of hand.  Intellij supports 
> marking subdirectories within a module as 
> source/resources/tests/test-resources.  I think we should consolidate these 
> modules so we have just one per lucene module.  Is there some reason I'm 
> missing that this was not done in the first place?



--
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-6066) CollapsingQParserPlugin + Elevation does not respects "fq" (filter query)

[David Boychuck (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129394#comment-14129394
 ] 

David Boychuck edited comment on SOLR-6066 at 9/11/14 12:01 AM:


I added the code from SOLR-6029 but the test provided fails because the 
nullPolicy documents are not grouped with or without elevation. I am not sure 
why.

{code}
// delete the elevated docs, confirm collapsing still works
assertU(delI("1"));
assertU(delI("2"));
assertU(commit());
params = new ModifiableSolrParams();
params.add("q", "");
params.add("fq", "{!collapse field=group_s nullPolicy=collapse}");
params.add("defType", "edismax");
params.add("bf", "field(test_ti)");
params.add("qf", "term_s");
//params.add("qt", "/elevate");
assertQ(req(params), "*[count(//doc)=2]",
"//result/doc[1]/float[@name='id'][.='3.0']",
"//result/doc[2]/float[@name='id'][.='6.0']");
{code}

{code}

053.05000100200.014789046109659463684.050010002000.014789046109827235846.0group210100200.01478904610996355072

{code}


was (Author: dboychuck):
I added the code from SOLR-6029 but the test provided fails because the 
nullPolicy documents are not grouped. I am not sure why

{code}
// delete the elevated docs, confirm collapsing still works
assertU(delI("1"));
assertU(delI("2"));
assertU(commit());
params = new ModifiableSolrParams();
params.add("q", "");
params.add("fq", "{!collapse field=group_s nullPolicy=collapse}");
params.add("defType", "edismax");
params.add("bf", "field(test_ti)");
params.add("qf", "term_s");
//params.add("qt", "/elevate");
assertQ(req(params), "*[count(//doc)=2]",
"//result/doc[1]/float[@name='id'][.='3.0']",
"//result/doc[2]/float[@name='id'][.='6.0']");
{code}

{code}

053.05000100200.014789046109659463684.050010002000.014789046109827235846.0group210100200.01478904610996355072

{code}

> CollapsingQParserPlugin + Elevation does not respects "fq" (filter query) 
> --
>
> Key: SOLR-6066
> URL: https://issues.apache.org/jira/browse/SOLR-6066
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 4.8
>Reporter: Herb Jiang
>Assignee: Joel Bernstein
> Fix For: 4.9
>
> Attachments: SOLR-6066.patch, SOLR-6066.patch, SOLR-6066.patch, 
> TestCollapseQParserPlugin.java
>
>
> QueryElevationComponent respects the "fq" parameter. But when use 
> CollapsingQParserPlugin with QueryElevationComponent, additional "fq" has no 
> effect.
> I use following test case to show this issue. (It will failed)
> {code:java}
> String[] doc = {"id","1", "term_s", "", "group_s", "group1", 
> "category_s", "cat2", "test_ti", "5", "test_tl", "10", "test_tf", "2000"};
> assertU(adoc(doc));
> assertU(commit());
> String[] doc1 = {"id","2", "term_s","", "group_s", "group1", 
> "category_s", "cat2", "test_ti", "50", "test_tl", "100", "test_tf", "200"};
> assertU(adoc(doc1));
> String[] doc2 = {"id","3", "term_s", "", "test_ti", "5000", 
> "test_tl", "100", "test_tf", "200"};
> assertU(adoc(doc2));
> assertU(commit());
> String[] doc3 = {"id","4", "term_s", "", "test_ti", "500", "test_tl", 
> "1000", "test_tf", "2000"};
> assertU(adoc(doc3));
> String[] doc4 = {"id","5", "term_s", "", "group_s", "group2", 
> "category_s", "cat1", "test_ti", "4", "test_tl", "10", "test_tf", "2000"};
> assertU(adoc(doc4));
> assertU(commit());
> String[] doc5 = {"id","6", "term_s","", "group_s", "group2", 
> "category_s", "cat1", "test_ti", "10", "test_tl", "100", "test_tf", "200"};
> assertU(adoc(doc5));
> assertU(commit());
> //Test additional filter query when using collapse
> params = new ModifiableSolrParams();
> params.add("q", "");
> params.add("fq", "{!collapse field=group_s}");
> params.add("fq", "category_s:cat1");
> params.add("defType", "edismax");
> params.add("bf", "field(test_ti)");
> params.add("qf", "term_s");
> params.add("qt", "/elevate");
> params.add("elevateIds", "2");
> assertQ(req(params), "*[count(//doc)=1]",
> "//result/doc[1]/float[@name='id'][.='6.0']");
> {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] [Commented] (SOLR-6066) CollapsingQParserPlugin + Elevation does not respects "fq" (filter query)

[David Boychuck (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129394#comment-14129394
 ] 

David Boychuck commented on SOLR-6066:
--

I added the code from SOLR-6029 but the test provided fails because the 
nullPolicy documents are not grouped. I am not sure why

{code}
// delete the elevated docs, confirm collapsing still works
assertU(delI("1"));
assertU(delI("2"));
assertU(commit());
params = new ModifiableSolrParams();
params.add("q", "");
params.add("fq", "{!collapse field=group_s nullPolicy=collapse}");
params.add("defType", "edismax");
params.add("bf", "field(test_ti)");
params.add("qf", "term_s");
//params.add("qt", "/elevate");
assertQ(req(params), "*[count(//doc)=2]",
"//result/doc[1]/float[@name='id'][.='3.0']",
"//result/doc[2]/float[@name='id'][.='6.0']");
{code}

{code}

053.05000100200.014789046109659463684.050010002000.014789046109827235846.0group210100200.01478904610996355072

{code}

> CollapsingQParserPlugin + Elevation does not respects "fq" (filter query) 
> --
>
> Key: SOLR-6066
> URL: https://issues.apache.org/jira/browse/SOLR-6066
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 4.8
>Reporter: Herb Jiang
>Assignee: Joel Bernstein
> Fix For: 4.9
>
> Attachments: SOLR-6066.patch, SOLR-6066.patch, SOLR-6066.patch, 
> TestCollapseQParserPlugin.java
>
>
> QueryElevationComponent respects the "fq" parameter. But when use 
> CollapsingQParserPlugin with QueryElevationComponent, additional "fq" has no 
> effect.
> I use following test case to show this issue. (It will failed)
> {code:java}
> String[] doc = {"id","1", "term_s", "", "group_s", "group1", 
> "category_s", "cat2", "test_ti", "5", "test_tl", "10", "test_tf", "2000"};
> assertU(adoc(doc));
> assertU(commit());
> String[] doc1 = {"id","2", "term_s","", "group_s", "group1", 
> "category_s", "cat2", "test_ti", "50", "test_tl", "100", "test_tf", "200"};
> assertU(adoc(doc1));
> String[] doc2 = {"id","3", "term_s", "", "test_ti", "5000", 
> "test_tl", "100", "test_tf", "200"};
> assertU(adoc(doc2));
> assertU(commit());
> String[] doc3 = {"id","4", "term_s", "", "test_ti", "500", "test_tl", 
> "1000", "test_tf", "2000"};
> assertU(adoc(doc3));
> String[] doc4 = {"id","5", "term_s", "", "group_s", "group2", 
> "category_s", "cat1", "test_ti", "4", "test_tl", "10", "test_tf", "2000"};
> assertU(adoc(doc4));
> assertU(commit());
> String[] doc5 = {"id","6", "term_s","", "group_s", "group2", 
> "category_s", "cat1", "test_ti", "10", "test_tl", "100", "test_tf", "200"};
> assertU(adoc(doc5));
> assertU(commit());
> //Test additional filter query when using collapse
> params = new ModifiableSolrParams();
> params.add("q", "");
> params.add("fq", "{!collapse field=group_s}");
> params.add("fq", "category_s:cat1");
> params.add("defType", "edismax");
> params.add("bf", "field(test_ti)");
> params.add("qf", "term_s");
> params.add("qt", "/elevate");
> params.add("elevateIds", "2");
> assertQ(req(params), "*[count(//doc)=1]",
> "//result/doc[1]/float[@name='id'][.='6.0']");
> {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] [Commented] (LUCENE-5930) Change intellij setup to have 1 module per lucene module instead of 3

[Ryan Ernst (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129346#comment-14129346
 ] 

Ryan Ernst commented on LUCENE-5930:


Thanks Steve.  I tried with 13.1 and I see the same issues you saw before.  
I've opened an issue with IDEA:
http://youtrack.jetbrains.com/issue/IDEA-129728

I will upload a patch with adding groups soon.

> Change intellij setup to have 1 module per lucene module instead of 3
> -
>
> Key: LUCENE-5930
> URL: https://issues.apache.org/jira/browse/LUCENE-5930
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ryan Ernst
>
> The number of intellij modules is getting out of hand.  Intellij supports 
> marking subdirectories within a module as 
> source/resources/tests/test-resources.  I think we should consolidate these 
> modules so we have just one per lucene module.  Is there some reason I'm 
> missing that this was not done in the first place?



--
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-5787) Get spellcheck frequency relatively to current query

[Hakim (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-5787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129324#comment-14129324
 ] 

Hakim commented on SOLR-5787:
-

Ok [~nalinikartha], you can close it.
I guess that doing a separate query is the only possible solution to this issue.

Thanks guys !

> Get spellcheck frequency relatively to current query
> 
>
> Key: SOLR-5787
> URL: https://issues.apache.org/jira/browse/SOLR-5787
> Project: Solr
>  Issue Type: Improvement
>  Components: spellchecker
>Affects Versions: 4.6
> Environment: Solr deployed on Jetty 9 Servlet container
>Reporter: Hakim
>Priority: Minor
>  Labels: features, newbie
>
> I guess that this functionnality isn't implemented yet. I'll begin by an 
> example to explain what I'm requesting:
> I have a lucene query that get articles satisfying a certain query. With this 
> same command, I'm getting at the same time suggestions if this query doesnt 
> return any article (so far, nothing unusual). 
> The frequency (count) associated with these suggestions is relative to all 
> index (it counts all occurences of the suggestion in the whole index). What I 
> want is that it counts only suggestion occurences satisfying current lucene 
> query.
> P.S: I'm using solr's spellcheck component (solr.DirectSolrSpellChecker).



--
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-6502) Custom search component to reduce recall of 'edismax' query.

[Peter Keegan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129292#comment-14129292
 ] 

Peter Keegan commented on SOLR-6502:


Btw, I  do like your 'adaptive precision' approach and should be easy to extend 
the single retry.

> Custom search component to reduce recall of 'edismax' query.
> 
>
> Key: SOLR-6502
> URL: https://issues.apache.org/jira/browse/SOLR-6502
> Project: Solr
>  Issue Type: New Feature
>Reporter: Peter Keegan
>Priority: Minor
> Attachments: LowRecallSearchComponent.zip
>
>
> Custom search component to improve query performance by reducing the normal 
> recall of the 'edismax' query. This component will set the 'mm' (minimum 
> match) parameter to 100%, requiring all keywords to match. If there are no 
> matches, 'mm' is set to 1 and the query is retried. This component is 
> registered in solrconfig.xml as '/LowRecallsearch'.



--
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-trunk-Linux (32bit/jdk1.7.0_67) - Build # 11219 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11219/
Java: 32bit/jdk1.7.0_67 -server -XX:+UseG1GC

2 tests failed.
REGRESSION:  
org.apache.lucene.index.TestIndexWriter.testTwoThreadsInterruptDeadlock

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space


REGRESSION:  org.apache.lucene.index.TestIndexWriter.testThreadInterruptDeadlock

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space




Build Log:
[...truncated 1050 lines...]
   [junit4] Suite: org.apache.lucene.index.TestIndexWriter
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestIndexWriter 
-Dtests.method=testTwoThreadsInterruptDeadlock -Dtests.seed=D1C014CC4D63705 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=sq 
-Dtests.timezone=Asia/Jakarta -Dtests.file.encoding=US-ASCII
   [junit4] ERROR   12.4s J0 | TestIndexWriter.testTwoThreadsInterruptDeadlock 
<<<
   [junit4]> Throwable #1: java.lang.OutOfMemoryError: Java heap 
spaceThrowable #2: com.carrotsearch.randomizedtesting.UncaughtExceptionError: 
Captured an uncaught exception in thread: Thread[id=863, name=Thread-638, 
state=RUNNABLE, group=TGRP-TestIndexWriter]
   [junit4]> Caused by: java.lang.OutOfMemoryError: Java heap space
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([D1C014CC4D63705]:0)
   [junit4]>at java.util.Arrays.copyOf(Arrays.java:2271)
   [junit4]>at 
java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:113)
   [junit4]>at 
java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
   [junit4]>at 
java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:140)
   [junit4]>at java.io.PrintStream.write(PrintStream.java:480)
   [junit4]>at 
sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
   [junit4]>at 
sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
   [junit4]>at 
sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
   [junit4]>at 
java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
   [junit4]>at java.io.PrintStream.write(PrintStream.java:527)
   [junit4]>at java.io.PrintStream.print(PrintStream.java:669)
   [junit4]>at java.io.PrintStream.println(PrintStream.java:806)
   [junit4]>at 
org.apache.lucene.index.TestIndexWriter$IndexerThreadInterrupt.listIndexFiles(TestIndexWriter.java:1229)
   [junit4]>at 
org.apache.lucene.index.TestIndexWriter$IndexerThreadInterrupt.run(TestIndexWriter.java:1171)Throwable
 #3: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an 
uncaught exception in thread: Thread[id=864, name=Thread-639, state=RUNNABLE, 
group=TGRP-TestIndexWriter]
   [junit4]> Caused by: java.lang.RuntimeException: MockDirectoryWrapper: 
cannot close: there are still open locks: 
{write.lock=java.lang.RuntimeException: lock "write.lock" was not released}
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([D1C014CC4D63705]:0)
   [junit4]>at 
org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:715)
   [junit4]>at org.apache.lucene.util.IOUtils.close(IOUtils.java:89)
   [junit4]>at org.apache.lucene.util.IOUtils.close(IOUtils.java:76)
   [junit4]>at 
org.apache.lucene.index.TestIndexWriter$IndexerThreadInterrupt.run(TestIndexWriter.java:1214)
   [junit4]> Caused by: java.lang.RuntimeException: lock "write.lock" was 
not released
   [junit4]>at 
org.apache.lucene.store.MockLockFactoryWrapper$MockLock.obtain(MockLockFactoryWrapper.java:74)
   [junit4]>at org.apache.lucene.store.Lock.obtain(Lock.java:77)
   [junit4]>at 
org.apache.lucene.index.IndexWriter.(IndexWriter.java:755)
   [junit4]>at 
org.apache.lucene.index.TestIndexWriter$IndexerThreadInterrupt.run(TestIndexWriter.java:1091)
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestIndexWriter 
-Dtests.method=testThreadInterruptDeadlock -Dtests.seed=D1C014CC4D63705 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=sq 
-Dtests.timezone=Asia/Jakarta -Dtests.file.encoding=US-ASCII
   [junit4] ERROR   11.5s J0 | TestIndexWriter.testThreadInterruptDeadlock <<<
   [junit4]> Throwable #1: java.lang.OutOfMemoryError: Java heap 
spaceThrowable #2: com.carrotsearch.randomizedtesting.UncaughtExceptionError: 
Captured an uncaught exception in thread: Thread[id=890, name=Thread-665, 
state=RUNNABLE, group=TGRP-TestIndexWriter]
   [junit4]> Caused by: java.lang.RuntimeException: MockDirectoryWrapper: 
cannot close: there are still open files: {_rf.nvd=1, _rk_Lucene410_0.dvd=1, 
_ri.nvd=1, _rk.nvd=1, _rh.nvd=1, _rd_SimpleText_0.pst=1, _rg_Lucene41_0.doc=1, 
_rj_Lucene41_0.doc=1, _rg.nvd=1, _re_Lucene41_0.tim=1, _ri.fdt=1, 
_rf_Lucene41_0.tim=1, _rk_Lucene41_0.doc=1, _rd_Lucene41_0.p

[jira] [Updated] (LUCENE-5931) DirectoryReader.openIfChanged(oldReader, commit) incorrectly assumes given commit point has deletes/field updates

[Michael McCandless (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless updated LUCENE-5931:
---
Attachment: LUCENE-5931.patch

Patch, starting from Vitaly's test case (thank you!) and folding into Lucene's 
tests ... it fails with this on trunk:

{noformat}
1) 
testReopenReaderToOlderCommit(org.apache.lucene.index.TestDirectoryReaderReopen)
java.lang.IllegalStateException: same segment _0 has invalid changes; likely 
you are re-opening a reader after illegally removing index files yourself and 
building a new index in their place.  Use IndexWriter.deleteAll or 
OpenMode.CREATE instead
at 
__randomizedtesting.SeedInfo.seed([D3F22B13D5839643:931C8A9673D003F4]:0)
at 
org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:190)
at 
org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:323)
at 
org.apache.lucene.index.StandardDirectoryReader$2.doBody(StandardDirectoryReader.java:317)
at 
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:649)
at 
org.apache.lucene.index.StandardDirectoryReader.doOpenFromCommit(StandardDirectoryReader.java:312)
at 
org.apache.lucene.index.StandardDirectoryReader.doOpenNoWriter(StandardDirectoryReader.java:308)
at 
org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:259)
at 
org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:137)
at 
org.apache.lucene.index.TestDirectoryReaderReopen.testReopenReaderToOlderCommit(TestDirectoryReaderReopen.java:824)
{noformat}

> DirectoryReader.openIfChanged(oldReader, commit) incorrectly assumes given 
> commit point has deletes/field updates
> -
>
> Key: LUCENE-5931
> URL: https://issues.apache.org/jira/browse/LUCENE-5931
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 4.6.1
>Reporter: Vitaly Funstein
>Assignee: Michael McCandless
>Priority: Critical
> Attachments: CommitReuseTest.java, LUCENE-5931.patch
>
>
> {{StandardDirectoryReader}} assumes that the segments from commit point have 
> deletes, when they may not, yet the original SegmentReader for the segment 
> that we are trying to reuse does. This is evident when running attached JUnit 
> test case with asserts enabled (default): 
> {noformat}
> java.lang.AssertionError
>   at 
> org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:188)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:326)
>   at 
> org.apache.lucene.index.StandardDirectoryReader$2.doBody(StandardDirectoryReader.java:320)
>   at 
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:702)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenFromCommit(StandardDirectoryReader.java:315)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenNoWriter(StandardDirectoryReader.java:311)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:262)
>   at 
> org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:183)
> {noformat}
> or, if asserts are disabled then it falls through into NPE:
> {noformat}
> java.lang.NullPointerException
>   at java.io.File.(File.java:305)
>   at 
> org.apache.lucene.store.NIOFSDirectory.openInput(NIOFSDirectory.java:80)
>   at 
> org.apache.lucene.codecs.lucene40.BitVector.(BitVector.java:327)
>   at 
> org.apache.lucene.codecs.lucene40.Lucene40LiveDocsFormat.readLiveDocs(Lucene40LiveDocsFormat.java:90)
>   at org.apache.lucene.index.SegmentReader.(SegmentReader.java:131)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:194)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:326)
>   at 
> org.apache.lucene.index.StandardDirectoryReader$2.doBody(StandardDirectoryReader.java:320)
>   at 
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:702)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenFromCommit(StandardDirectoryReader.java:315)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenNoWriter(StandardDirectoryReader.java:311)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:262)
>   at 
> org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:183)
> {noformat}



--
This message was sent by Atlassian JIRA

[jira] [Assigned] (LUCENE-5931) DirectoryReader.openIfChanged(oldReader, commit) incorrectly assumes given commit point has deletes/field updates

[Michael McCandless (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless reassigned LUCENE-5931:
--

Assignee: Michael McCandless

> DirectoryReader.openIfChanged(oldReader, commit) incorrectly assumes given 
> commit point has deletes/field updates
> -
>
> Key: LUCENE-5931
> URL: https://issues.apache.org/jira/browse/LUCENE-5931
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 4.6.1
>Reporter: Vitaly Funstein
>Assignee: Michael McCandless
>Priority: Critical
> Attachments: CommitReuseTest.java
>
>
> {{StandardDirectoryReader}} assumes that the segments from commit point have 
> deletes, when they may not, yet the original SegmentReader for the segment 
> that we are trying to reuse does. This is evident when running attached JUnit 
> test case with asserts enabled (default): 
> {noformat}
> java.lang.AssertionError
>   at 
> org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:188)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:326)
>   at 
> org.apache.lucene.index.StandardDirectoryReader$2.doBody(StandardDirectoryReader.java:320)
>   at 
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:702)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenFromCommit(StandardDirectoryReader.java:315)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenNoWriter(StandardDirectoryReader.java:311)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:262)
>   at 
> org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:183)
> {noformat}
> or, if asserts are disabled then it falls through into NPE:
> {noformat}
> java.lang.NullPointerException
>   at java.io.File.(File.java:305)
>   at 
> org.apache.lucene.store.NIOFSDirectory.openInput(NIOFSDirectory.java:80)
>   at 
> org.apache.lucene.codecs.lucene40.BitVector.(BitVector.java:327)
>   at 
> org.apache.lucene.codecs.lucene40.Lucene40LiveDocsFormat.readLiveDocs(Lucene40LiveDocsFormat.java:90)
>   at org.apache.lucene.index.SegmentReader.(SegmentReader.java:131)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:194)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:326)
>   at 
> org.apache.lucene.index.StandardDirectoryReader$2.doBody(StandardDirectoryReader.java:320)
>   at 
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:702)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenFromCommit(StandardDirectoryReader.java:315)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenNoWriter(StandardDirectoryReader.java:311)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:262)
>   at 
> org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:183)
> {noformat}



--
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-Tests-trunk-Java7 - Build # 4842 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java7/4842/

3 tests failed.
REGRESSION:  org.apache.lucene.index.TestIndexWriter.testThreadInterruptDeadlock

Error Message:
Captured an uncaught exception in thread: Thread[id=509, name=Thread-402, 
state=RUNNABLE, group=TGRP-TestIndexWriter]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=509, name=Thread-402, state=RUNNABLE, 
group=TGRP-TestIndexWriter]
at 
__randomizedtesting.SeedInfo.seed([313DE942481B0CC9:7F93B938228BE7C5]:0)
Caused by: java.lang.OutOfMemoryError: Java heap space


REGRESSION:  org.apache.lucene.index.TestIndexWriter.testMergeAllDeleted

Error Message:
Captured an uncaught exception in thread: Thread[id=530, name=Lucene Merge 
Thread #0, state=RUNNABLE, group=TGRP-TestIndexWriter]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=530, name=Lucene Merge Thread #0, 
state=RUNNABLE, group=TGRP-TestIndexWriter]
at 
__randomizedtesting.SeedInfo.seed([313DE942481B0CC9:A404D3C553375F1F]:0)
Caused by: org.apache.lucene.index.MergePolicy$MergeException: 
java.lang.OutOfMemoryError: Java heap space
at __randomizedtesting.SeedInfo.seed([313DE942481B0CC9]:0)
at 
org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:545)
at 
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:518)
Caused by: java.lang.OutOfMemoryError: Java heap space


REGRESSION:  
org.apache.lucene.index.TestIndexWriter.testTwoThreadsInterruptDeadlock

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space




Build Log:
[...truncated 1062 lines...]
   [junit4] Suite: org.apache.lucene.index.TestIndexWriter
   [junit4]   2> IX 10, 2014 6:02:43 PM 
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
 uncaughtException
   [junit4]   2> WARNING: Uncaught exception in thread: 
Thread[Thread-402,5,TGRP-TestIndexWriter]
   [junit4]   2> java.lang.OutOfMemoryError: Java heap space
   [junit4]   2> 
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestIndexWriter 
-Dtests.method=testThreadInterruptDeadlock -Dtests.seed=313DE942481B0CC9 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=bg 
-Dtests.timezone=America/Rio_Branco -Dtests.file.encoding=US-ASCII
   [junit4] ERROR   8.95s J0 | TestIndexWriter.testThreadInterruptDeadlock <<<
   [junit4]> Throwable #1: 
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=509, name=Thread-402, state=RUNNABLE, 
group=TGRP-TestIndexWriter]
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([313DE942481B0CC9:7F93B938228BE7C5]:0)
   [junit4]> Caused by: java.lang.OutOfMemoryError: Java heap space
   [junit4]   2> IX 10, 2014 6:02:43 PM 
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
 uncaughtException
   [junit4]   2> WARNING: Uncaught exception in thread: Thread[Lucene Merge 
Thread #0,6,TGRP-TestIndexWriter]
   [junit4]   2> org.apache.lucene.index.MergePolicy$MergeException: 
java.lang.OutOfMemoryError: Java heap space
   [junit4]   2>at 
__randomizedtesting.SeedInfo.seed([313DE942481B0CC9]:0)
   [junit4]   2>at 
org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:545)
   [junit4]   2>at 
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:518)
   [junit4]   2> Caused by: java.lang.OutOfMemoryError: Java heap space
   [junit4]   2> 
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestIndexWriter 
-Dtests.method=testMergeAllDeleted -Dtests.seed=313DE942481B0CC9 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=bg 
-Dtests.timezone=America/Rio_Branco -Dtests.file.encoding=US-ASCII
   [junit4] ERROR   0.74s J0 | TestIndexWriter.testMergeAllDeleted <<<
   [junit4]> Throwable #1: 
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=530, name=Lucene Merge Thread #0, 
state=RUNNABLE, group=TGRP-TestIndexWriter]
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([313DE942481B0CC9:A404D3C553375F1F]:0)
   [junit4]> Caused by: org.apache.lucene.index.MergePolicy$MergeException: 
java.lang.OutOfMemoryError: Java heap space
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([313DE942481B0CC9]:0)
   [junit4]>at 
org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:545)
   [junit4]>at 
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:518)
   [junit4]> Caused by: java.lang.OutOfMemoryError: Java heap space
   [junit4]   2> IX 10, 2014 6:02:51 PM 

[jira] [Commented] (LUCENE-5934) 4.10 broke backwards compatibility for 4.0 indexes

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129236#comment-14129236
 ] 

ASF subversion and git services commented on LUCENE-5934:
-

Commit 1624149 from [~thetaphi] in branch 'dev/branches/lucene_solr_4_10'
[ https://svn.apache.org/r1624149 ]

Merged revision(s) 1624148 from lucene/dev/branches/branch_4x:
Merged revision(s) 1624146 from lucene/dev/trunk:
LUCENE-5934: Add Ian Lea to CHANGES.txt

> 4.10 broke backwards compatibility for 4.0 indexes
> --
>
> Key: LUCENE-5934
> URL: https://issues.apache.org/jira/browse/LUCENE-5934
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/codecs, core/index
>Affects Versions: 4.10
>Reporter: Robert Muir
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 4.10.1, 4.11, 5.0
>
> Attachments: LUCENE-5934.patch, LUCENE-5934.patch, LUCENE-5934.patch, 
> LUCENE-5934.patch, LUCENE-5934.patch
>
>
> As reported by Ian on the user list:
> Its trying to treat them as 3.x



--
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-5934) 4.10 broke backwards compatibility for 4.0 indexes

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129235#comment-14129235
 ] 

ASF subversion and git services commented on LUCENE-5934:
-

Commit 1624148 from [~thetaphi] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1624148 ]

Merged revision(s) 1624146 from lucene/dev/trunk:
LUCENE-5934: Add Ian Lea to CHANGES.txt

> 4.10 broke backwards compatibility for 4.0 indexes
> --
>
> Key: LUCENE-5934
> URL: https://issues.apache.org/jira/browse/LUCENE-5934
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/codecs, core/index
>Affects Versions: 4.10
>Reporter: Robert Muir
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 4.10.1, 4.11, 5.0
>
> Attachments: LUCENE-5934.patch, LUCENE-5934.patch, LUCENE-5934.patch, 
> LUCENE-5934.patch, LUCENE-5934.patch
>
>
> As reported by Ian on the user list:
> Its trying to treat them as 3.x



--
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-5934) 4.10 broke backwards compatibility for 4.0 indexes

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129232#comment-14129232
 ] 

ASF subversion and git services commented on LUCENE-5934:
-

Commit 1624146 from [~thetaphi] in branch 'dev/trunk'
[ https://svn.apache.org/r1624146 ]

LUCENE-5934: Add Ian Lea to CHANGES.txt

> 4.10 broke backwards compatibility for 4.0 indexes
> --
>
> Key: LUCENE-5934
> URL: https://issues.apache.org/jira/browse/LUCENE-5934
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/codecs, core/index
>Affects Versions: 4.10
>Reporter: Robert Muir
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 4.10.1, 4.11, 5.0
>
> Attachments: LUCENE-5934.patch, LUCENE-5934.patch, LUCENE-5934.patch, 
> LUCENE-5934.patch, LUCENE-5934.patch
>
>
> As reported by Ian on the user list:
> Its trying to treat them as 3.x



--
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-5934) 4.10 broke backwards compatibility for 4.0 indexes

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-5934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler resolved LUCENE-5934.
---
Resolution: Fixed

Thanks Mike. I backported it. Issue finally resolved :-)

> 4.10 broke backwards compatibility for 4.0 indexes
> --
>
> Key: LUCENE-5934
> URL: https://issues.apache.org/jira/browse/LUCENE-5934
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/codecs, core/index
>Affects Versions: 4.10
>Reporter: Robert Muir
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 4.10.1, 4.11, 5.0
>
> Attachments: LUCENE-5934.patch, LUCENE-5934.patch, LUCENE-5934.patch, 
> LUCENE-5934.patch, LUCENE-5934.patch
>
>
> As reported by Ian on the user list:
> Its trying to treat them as 3.x



--
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-5934) 4.10 broke backwards compatibility for 4.0 indexes

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129213#comment-14129213
 ] 

ASF subversion and git services commented on LUCENE-5934:
-

Commit 1624144 from [~thetaphi] in branch 'dev/branches/lucene_solr_4_10'
[ https://svn.apache.org/r1624144 ]

Merged revision(s) 1624141 from lucene/dev/branches/branch_4x:
LUCENE-5934: also check this IllegalStateException up higher so it will not 
cause corruption when IW kisses an index if it ever kicks in again (hopefully 
not!)

> 4.10 broke backwards compatibility for 4.0 indexes
> --
>
> Key: LUCENE-5934
> URL: https://issues.apache.org/jira/browse/LUCENE-5934
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/codecs, core/index
>Affects Versions: 4.10
>Reporter: Robert Muir
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 4.10.1, 4.11, 5.0
>
> Attachments: LUCENE-5934.patch, LUCENE-5934.patch, LUCENE-5934.patch, 
> LUCENE-5934.patch, LUCENE-5934.patch
>
>
> As reported by Ian on the user list:
> Its trying to treat them as 3.x



--
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-5936) Add BWC checks to verify what is tested matches what versions we know about

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129193#comment-14129193
 ] 

Robert Muir commented on LUCENE-5936:
-

yes please, lets not do the network. the smoketester can do that. In fact mike 
already wrote the code.

> Add BWC checks to verify what is tested matches what versions we know about
> ---
>
> Key: LUCENE-5936
> URL: https://issues.apache.org/jira/browse/LUCENE-5936
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Ryan Ernst
> Attachments: LUCENE-5936.patch, LUCENE-5936.patch
>
>
> This is a follow up from LUCENE-5934.  Mike has already has something like 
> this for the smoke tester, but here I am suggesting a test within the test 
> (similar to other Version tests we have which check things like deprecation 
> status of old versions).



--
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-6452) StatsComponent "missing" stat won't work with docValues=true and indexed=false

[JIRA]

[ 
https://issues.apache.org/jira/browse/SOLR-6452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129192#comment-14129192
 ] 

Tomás Fernández Löbbe commented on SOLR-6452:
-

bq. 1. Accumulate methods should not return stats specific numbers (it is 
generic calculation).
I don't see the issue here. Can you provide a test that exposes the bug?

bq. 2. Reduced visibility of fields in FieldFacetStats.
I think this should be done in trunk only

> StatsComponent "missing" stat won't work with docValues=true and indexed=false
> --
>
> Key: SOLR-6452
> URL: https://issues.apache.org/jira/browse/SOLR-6452
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10, 5.0
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-6452-trunk.patch, SOLR-6452-trunk.patch, 
> SOLR-6452.patch, SOLR-6452.patch, SOLR-6452.patch
>
>
> StatsComponent can work with DocValues, but it still required to use 
> indexed=true for the "missing" stat to work. Missing values should be 
> obtained from the docValues too.



--
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-5936) Add BWC checks to verify what is tested matches what versions we know about

[Ryan Ernst (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129187#comment-14129187
 ] 

Ryan Ernst commented on LUCENE-5936:


bq. We could also add a test to TestVersion that checks 
http://archives.apache.org with the list of Versions?

I was trying to avoid a unit test which hit the network (to maintain the 
ability to run offline).  But even so, that test would only check released 
versions have a version constant? I think the missing piece (which is what 
mikes script is doing + every other version) is do we have a unique version for 
this which we are release testing.

> Add BWC checks to verify what is tested matches what versions we know about
> ---
>
> Key: LUCENE-5936
> URL: https://issues.apache.org/jira/browse/LUCENE-5936
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Ryan Ernst
> Attachments: LUCENE-5936.patch, LUCENE-5936.patch
>
>
> This is a follow up from LUCENE-5934.  Mike has already has something like 
> this for the smoke tester, but here I am suggesting a test within the test 
> (similar to other Version tests we have which check things like deprecation 
> status of old versions).



--
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-5936) Add BWC checks to verify what is tested matches what versions we know about

[Ryan Ernst (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Ernst updated LUCENE-5936:
---
Attachment: LUCENE-5936.patch

New patch that handles 4.11 when on trunk.  It's a little hacky but tests 
pass...

> Add BWC checks to verify what is tested matches what versions we know about
> ---
>
> Key: LUCENE-5936
> URL: https://issues.apache.org/jira/browse/LUCENE-5936
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Ryan Ernst
> Attachments: LUCENE-5936.patch, LUCENE-5936.patch
>
>
> This is a follow up from LUCENE-5934.  Mike has already has something like 
> this for the smoke tester, but here I am suggesting a test within the test 
> (similar to other Version tests we have which check things like deprecation 
> status of old versions).



--
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-5934) 4.10 broke backwards compatibility for 4.0 indexes

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129176#comment-14129176
 ] 

Robert Muir commented on LUCENE-5934:
-

thank you Mike

> 4.10 broke backwards compatibility for 4.0 indexes
> --
>
> Key: LUCENE-5934
> URL: https://issues.apache.org/jira/browse/LUCENE-5934
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/codecs, core/index
>Affects Versions: 4.10
>Reporter: Robert Muir
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 4.10.1, 4.11, 5.0
>
> Attachments: LUCENE-5934.patch, LUCENE-5934.patch, LUCENE-5934.patch, 
> LUCENE-5934.patch, LUCENE-5934.patch
>
>
> As reported by Ian on the user list:
> Its trying to treat them as 3.x



--
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

Request for committer attention

[Ramkumar R. Aiyengar]

Have a few Solr patches which have been around for a while, could some one
please take a look and commit, or let me know if anything else is needed?

SOLR-6459  Consistently
log all Overseer operations, and queue size
SOLR-6454  Suppress
EOFExceptions in SolrDispatchFilter
SOLR-6453  Stop throwing
from OverseerExitThread on Solr exit
SOLR-6370  Allow tests to
report when many watches are requested parallelly on the same data
SOLR-6359  Customize
records, logs kept by UpdateLog, improve test on log expiry

Thanks! Ramkumar.

[jira] [Commented] (LUCENE-5934) 4.10 broke backwards compatibility for 4.0 indexes

[Michael McCandless (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129168#comment-14129168
 ] 

Michael McCandless commented on LUCENE-5934:


bq. In fact I would leave the test where it is and instead add a second test at 
the !segmentWasUpgraded() place? 

OK I did that, except I moved the inner check up higher to before we make any 
destructive changes to the index.

Also, I reverted the commit here, but kept Robert's commit, confirmed 
TestBackCompat fails with the IlegalStateExc and that the index is NOT corrupt.

> 4.10 broke backwards compatibility for 4.0 indexes
> --
>
> Key: LUCENE-5934
> URL: https://issues.apache.org/jira/browse/LUCENE-5934
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/codecs, core/index
>Affects Versions: 4.10
>Reporter: Robert Muir
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 4.10.1, 4.11, 5.0
>
> Attachments: LUCENE-5934.patch, LUCENE-5934.patch, LUCENE-5934.patch, 
> LUCENE-5934.patch, LUCENE-5934.patch
>
>
> As reported by Ian on the user list:
> Its trying to treat them as 3.x



--
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-5934) 4.10 broke backwards compatibility for 4.0 indexes

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129167#comment-14129167
 ] 

ASF subversion and git services commented on LUCENE-5934:
-

Commit 1624141 from [~mikemccand] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1624141 ]

LUCENE-5934: also check this IllegalStateException up higher so it will not 
cause corruption when IW kisses an index if it ever kicks in again (hopefully 
not!)

> 4.10 broke backwards compatibility for 4.0 indexes
> --
>
> Key: LUCENE-5934
> URL: https://issues.apache.org/jira/browse/LUCENE-5934
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/codecs, core/index
>Affects Versions: 4.10
>Reporter: Robert Muir
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 4.10.1, 4.11, 5.0
>
> Attachments: LUCENE-5934.patch, LUCENE-5934.patch, LUCENE-5934.patch, 
> LUCENE-5934.patch, LUCENE-5934.patch
>
>
> As reported by Ian on the user list:
> Its trying to treat them as 3.x



--
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-4.x-MacOSX (64bit/jdk1.7.0) - Build # 1785 - Failure!

[Uwe Schindler]

Failed download in previous run (pom file corrumpt).

Uwe

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
> Sent: Wednesday, September 10, 2014 11:16 PM
> To: rm...@apache.org; thelabd...@apache.org; dev@lucene.apache.org
> Subject: [JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.7.0) - Build # 1785 -
> Failure!
> 
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/1785/
> Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseParallelGC
> 
> All tests passed
> 
> Build Log:
> [...truncated 55058 lines...]
> BUILD FAILED
> /Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/build.xml:491: The
> following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/build.xml:78: The
> following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build.xml:130:
> The following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build.xml:233:
> The following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/common-
> build.xml:2407: javax.script.ScriptException:
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> General error during class generation: java.lang.NoClassDefFoundError:
> Unable to load class org.pegdown.PegDownProcessor due to missing
> dependency org/parboiled/BaseParser
> 
> java.lang.RuntimeException: java.lang.NoClassDefFoundError: Unable to load
> class org.pegdown.PegDownProcessor due to missing dependency
> org/parboiled/BaseParser
>   at
> org.codehaus.groovy.control.CompilationUnit.convertUncaughtExceptionTo
> CompilationError(CompilationUnit.java:1083)
>   at
> org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(Co
> mpilationUnit.java:1061)
>   at
> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(Compilatio
> nUnit.java:583)
>   at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(Com
> pilationUnit.java:561)
>   at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:
> 538)
>   at
> groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:286)
>   at
> groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:259)
>   at
> groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:245)
>   at
> groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:203)
>   at
> org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.getScriptClass(GroovyS
> criptEngineImpl.java:367)
>   at
> org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngin
> eImpl.java:143)
>   at
> javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> ava:57)
>   at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at org.apache.tools.ant.util.ReflectUtil.invoke(ReflectUtil.java:108)
>   at
> org.apache.tools.ant.util.ReflectWrapper.invoke(ReflectWrapper.java:81)
>   at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScri
> ptRunner.java:103)
>   at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScri
> ptRunner.java:67)
>   at
> org.apache.tools.ant.types.optional.ScriptFilter.filter(ScriptFilter.java:110)
>   at org.apache.tools.ant.filters.TokenFilter.read(TokenFilter.java:114)
>   at
> org.apache.tools.ant.filters.BaseFilterReader.read(BaseFilterReader.java:83)
>   at java.io.BufferedReader.read1(BufferedReader.java:203)
>   at java.io.BufferedReader.read(BufferedReader.java:279)
>   at
> org.apache.tools.ant.util.ResourceUtils.copyResource(ResourceUtils.java:494
> )
>   at org.apache.tools.ant.util.FileUtils.copyFile(FileUtils.java:559)
>   at
> org.apache.tools.ant.taskdefs.Copy.doFileOperations(Copy.java:875)
>   at org.apache.tools.ant.taskdefs.Copy.execute(Copy.java:549)
>   at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
>   at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
>   at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
>   at org.apache.tools.ant.Task.perform(Task.java:348)
>   at
> org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68)
>   at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
>   at sun.reflect.GeneratedMethodAc

[JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.7.0) - Build # 1785 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/1785/
Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 55058 lines...]
BUILD FAILED
/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/build.xml:491: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/build.xml:78: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build.xml:130: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build.xml:233: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/common-build.xml:2407: 
javax.script.ScriptException: 
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
General error during class generation: java.lang.NoClassDefFoundError: Unable 
to load class org.pegdown.PegDownProcessor due to missing dependency 
org/parboiled/BaseParser

java.lang.RuntimeException: java.lang.NoClassDefFoundError: Unable to load 
class org.pegdown.PegDownProcessor due to missing dependency 
org/parboiled/BaseParser
at 
org.codehaus.groovy.control.CompilationUnit.convertUncaughtExceptionToCompilationError(CompilationUnit.java:1083)
at 
org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1061)
at 
org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:583)
at 
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:561)
at 
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:538)
at 
groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:286)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:259)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:245)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:203)
at 
org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.getScriptClass(GroovyScriptEngineImpl.java:367)
at 
org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:143)
at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.tools.ant.util.ReflectUtil.invoke(ReflectUtil.java:108)
at 
org.apache.tools.ant.util.ReflectWrapper.invoke(ReflectWrapper.java:81)
at 
org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:103)
at 
org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67)
at 
org.apache.tools.ant.types.optional.ScriptFilter.filter(ScriptFilter.java:110)
at org.apache.tools.ant.filters.TokenFilter.read(TokenFilter.java:114)
at 
org.apache.tools.ant.filters.BaseFilterReader.read(BaseFilterReader.java:83)
at java.io.BufferedReader.read1(BufferedReader.java:203)
at java.io.BufferedReader.read(BufferedReader.java:279)
at 
org.apache.tools.ant.util.ResourceUtils.copyResource(ResourceUtils.java:494)
at org.apache.tools.ant.util.FileUtils.copyFile(FileUtils.java:559)
at org.apache.tools.ant.taskdefs.Copy.doFileOperations(Copy.java:875)
at org.apache.tools.ant.taskdefs.Copy.execute(Copy.java:549)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at 
org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:398)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
 

[jira] [Updated] (SOLR-6452) StatsComponent "missing" stat won't work with docValues=true and indexed=false

[Vitaliy Zhovtyuk (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-6452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vitaliy Zhovtyuk updated SOLR-6452:
---
Attachment: SOLR-6452.patch

There are few issues in committed code addressed in attached patch:
1. Accumulate methods should not return stats specific numbers (it is generic 
calculation).
Attached solution with nested container class.
Also made them private scoped.

2. Reduced visibility of fields in FieldFacetStats.
Created getter to expose FieldFacetStats.facetStatsValues.

3. Methods FieldFacetStats#accumulateMissing and 
FieldFacetStats#accumulateTermNum does not throw any IO exception

4. Why missing facet counters cant work on StatsValues directly without 
intermediate maps. They have all required required methods that look like 
duplicated in org.apache.solr.handler.component.FieldFacetStats#facetMissingNum 
and org.apache.solr.handler.component.AbstractStatsValues#missing?
Will try to unite it.

> StatsComponent "missing" stat won't work with docValues=true and indexed=false
> --
>
> Key: SOLR-6452
> URL: https://issues.apache.org/jira/browse/SOLR-6452
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10, 5.0
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-6452-trunk.patch, SOLR-6452-trunk.patch, 
> SOLR-6452.patch, SOLR-6452.patch, SOLR-6452.patch
>
>
> StatsComponent can work with DocValues, but it still required to use 
> indexed=true for the "missing" stat to work. Missing values should be 
> obtained from the docValues too.



--
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-5936) Add BWC checks to verify what is tested matches what versions we know about

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129123#comment-14129123
 ] 

Uwe Schindler commented on LUCENE-5936:
---

We could also add a test to TestVersion that checks http://archives.apache.org 
with the list of Versions?

> Add BWC checks to verify what is tested matches what versions we know about
> ---
>
> Key: LUCENE-5936
> URL: https://issues.apache.org/jira/browse/LUCENE-5936
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Ryan Ernst
> Attachments: LUCENE-5936.patch
>
>
> This is a follow up from LUCENE-5934.  Mike has already has something like 
> this for the smoke tester, but here I am suggesting a test within the test 
> (similar to other Version tests we have which check things like deprecation 
> status of old versions).



--
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-5935) bogus TODO inside TestBackwardsCompatibility in trunk

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129114#comment-14129114
 ] 

Robert Muir commented on LUCENE-5935:
-

thanks for the thorough investigation... it freaked me out to see this!

> bogus TODO inside TestBackwardsCompatibility in trunk
> -
>
> Key: LUCENE-5935
> URL: https://issues.apache.org/jira/browse/LUCENE-5935
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Michael McCandless
>Priority: Blocker
> Fix For: 5.0
>
>
> in TestBackwardsCompatibility in trunk we have:
> {code}
>   // TODO: these are on 4x, but something is wrong (they seem to be a too 
> old DV format):
> {code}
> I put a nocommit above it, to draw as much attention as possible to this. 
> What does this mean, that we aren't testing backwards compatibilty? are tests 
> disabled? I don't see how this is possibly a valid TODO.



--
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-5936) Add BWC checks to verify what is tested matches what versions we know about

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129116#comment-14129116
 ] 

Uwe Schindler commented on LUCENE-5936:
---

In my opinion, smoketester should simply check Version.java that it contains a 
version for every item in the apache archives? So this test together with a 
cheap smoker test is all we need.

> Add BWC checks to verify what is tested matches what versions we know about
> ---
>
> Key: LUCENE-5936
> URL: https://issues.apache.org/jira/browse/LUCENE-5936
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Ryan Ernst
> Attachments: LUCENE-5936.patch
>
>
> This is a follow up from LUCENE-5934.  Mike has already has something like 
> this for the smoke tester, but here I am suggesting a test within the test 
> (similar to other Version tests we have which check things like deprecation 
> status of old versions).



--
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-5936) Add BWC checks to verify what is tested matches what versions we know about

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129110#comment-14129110
 ] 

Uwe Schindler commented on LUCENE-5936:
---

Cool. Somehow I know the Version-field reflection loop already! :-) I cloned it 
several times today.

+1 to add something like this!

> Add BWC checks to verify what is tested matches what versions we know about
> ---
>
> Key: LUCENE-5936
> URL: https://issues.apache.org/jira/browse/LUCENE-5936
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Ryan Ernst
> Attachments: LUCENE-5936.patch
>
>
> This is a follow up from LUCENE-5934.  Mike has already has something like 
> this for the smoke tester, but here I am suggesting a test within the test 
> (similar to other Version tests we have which check things like deprecation 
> status of old versions).



--
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-6494) Query filters applied in a wrong order

[Hoss Man (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129109#comment-14129109
 ] 

Hoss Man commented on SOLR-6494:


Please note the most important part of Erick's comment...

bq. First, please raise issues like this on the user's list...

The user list is the appropriate place to ask questions about how to use 
features, and about performance issues you might be seeing.  The *entire* solr 
user community can help you, instead of the much smaller subset of people who 
track Jira bug reports. 

Please also note the following useful tips for asking for help...
https://wiki.apache.org/solr/UsingMailingLists

Since you haven't provided any details about your schema, fields, fieldtypes, 
or even a full example of what your query looks like (beyond just the fq 
params) it's pretty much impossible to guess why your queries might be slow.



To re-iterate: ask questions on the user mailing list, not in the bug tracker.

> Query filters applied in a wrong order
> --
>
> Key: SOLR-6494
> URL: https://issues.apache.org/jira/browse/SOLR-6494
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.8.1
>Reporter: Alexander S.
>
> This query:
> {code}
> {
>   fq: ["type:Award::Nomination"],
>   sort: "score desc",
>   start: 0,
>   rows: 20,
>   q: "*:*"
> }
> {code}
> takes just a few milliseconds, but this one:
> {code}
> {
>   fq: [
> "type:Award::Nomination",
> "created_at_d:[* TO 2014-09-08T23:59:59Z]"
>   ],
>   sort: "score desc",
>   start: 0,
>   rows: 20,
>   q: "*:*"
> }
> {code}
> takes almost 15 seconds.
> I have just ≈12k of documents with type "Award::Nomination", but around half 
> a billion with created_at_d field set. And it seems Solr applies the 
> created_at_d filter first going through all documents where this field is 
> set, which is not very smart.
> I think if it can't do anything better than applying filters in the alphabet 
> order it should apply them in the order they were received.



--
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-6493) stats on multivalued fields don't respect excluded filters

[Hoss Man (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-6493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man updated SOLR-6493:
---
Fix Version/s: 4.10.1

> stats on multivalued fields don't respect excluded filters
> --
>
> Key: SOLR-6493
> URL: https://issues.apache.org/jira/browse/SOLR-6493
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.8, 4.9, 4.10
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 4.10.1, 4.11, 5.0
>
> Attachments: SOLR-6493.patch, SOLR-6493.patch
>
>
> SOLR-3177 added support to StatsComponent for using the "ex" local param to 
> exclude tagged filters, but these exclusions have apparently never been 
> correct for multivalued fields



--
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-6493) stats on multivalued fields don't respect excluded filters

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129099#comment-14129099
 ] 

ASF subversion and git services commented on SOLR-6493:
---

Commit 1624131 from hoss...@apache.org in branch 'dev/branches/lucene_solr_4_10'
[ https://svn.apache.org/r1624131 ]

SOLR-6493: Fix fq exclusion via ex local param in multivalued stats.field 
(merge r1623893)

> stats on multivalued fields don't respect excluded filters
> --
>
> Key: SOLR-6493
> URL: https://issues.apache.org/jira/browse/SOLR-6493
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.8, 4.9, 4.10
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 4.10.1, 4.11, 5.0
>
> Attachments: SOLR-6493.patch, SOLR-6493.patch
>
>
> SOLR-3177 added support to StatsComponent for using the "ex" local param to 
> exclude tagged filters, but these exclusions have apparently never been 
> correct for multivalued fields



--
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-5935) bogus TODO inside TestBackwardsCompatibility in trunk

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129098#comment-14129098
 ] 

Uwe Schindler commented on LUCENE-5935:
---

Yes,
Eclipse's SVN Annotate function confirms the same.

> bogus TODO inside TestBackwardsCompatibility in trunk
> -
>
> Key: LUCENE-5935
> URL: https://issues.apache.org/jira/browse/LUCENE-5935
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Michael McCandless
>Priority: Blocker
> Fix For: 5.0
>
>
> in TestBackwardsCompatibility in trunk we have:
> {code}
>   // TODO: these are on 4x, but something is wrong (they seem to be a too 
> old DV format):
> {code}
> I put a nocommit above it, to draw as much attention as possible to this. 
> What does this mean, that we aren't testing backwards compatibilty? are tests 
> disabled? I don't see how this is possibly a valid TODO.



--
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-5935) bogus TODO inside TestBackwardsCompatibility in trunk

[Michael McCandless (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless resolved LUCENE-5935.

   Resolution: Fixed
Fix Version/s: 5.0
 Assignee: Michael McCandless

Trunk-only stale TODO.

> bogus TODO inside TestBackwardsCompatibility in trunk
> -
>
> Key: LUCENE-5935
> URL: https://issues.apache.org/jira/browse/LUCENE-5935
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Michael McCandless
>Priority: Blocker
> Fix For: 5.0
>
>
> in TestBackwardsCompatibility in trunk we have:
> {code}
>   // TODO: these are on 4x, but something is wrong (they seem to be a too 
> old DV format):
> {code}
> I put a nocommit above it, to draw as much attention as possible to this. 
> What does this mean, that we aren't testing backwards compatibilty? are tests 
> disabled? I don't see how this is possibly a valid TODO.



--
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-5935) bogus TODO inside TestBackwardsCompatibility in trunk

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129092#comment-14129092
 ] 

ASF subversion and git services commented on LUCENE-5935:
-

Commit 1624128 from [~mikemccand] in branch 'dev/trunk'
[ https://svn.apache.org/r1624128 ]

LUCENE-5935: remove terrifying yet stale TODO

> bogus TODO inside TestBackwardsCompatibility in trunk
> -
>
> Key: LUCENE-5935
> URL: https://issues.apache.org/jira/browse/LUCENE-5935
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Priority: Blocker
> Fix For: 5.0
>
>
> in TestBackwardsCompatibility in trunk we have:
> {code}
>   // TODO: these are on 4x, but something is wrong (they seem to be a too 
> old DV format):
> {code}
> I put a nocommit above it, to draw as much attention as possible to this. 
> What does this mean, that we aren't testing backwards compatibilty? are tests 
> disabled? I don't see how this is possibly a valid TODO.



--
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-6499) Log warning about multiple update request handlers

[Hoss Man (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man updated SOLR-6499:
---
Assignee: Noble Paul

noble: can you follow up with this?

> Log warning about multiple update request handlers
> --
>
> Key: SOLR-6499
> URL: https://issues.apache.org/jira/browse/SOLR-6499
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10
>Reporter: Andreas Hubold
>Assignee: Noble Paul
>Priority: Minor
>
> Solr 4.10.0 logs the following warning upon startup:
> {noformat}
> WARN  - 2014-09-09 17:49:11.455; org.apache.solr.core.RequestHandlers; 
> Multiple requestHandler registered to the same name: /update ignoring: 
> org.apache.solr.handler.UpdateRequestHandler
> {noformat}
> I've just started the Solr example with {{bin/solr start}} to get this 
> warning in {{example/logs/solr.log}}
> I don't know if this indicates a real problem but it seems everything works 
> fine despite the warning.



--
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-5935) bogus TODO inside TestBackwardsCompatibility in trunk

[Michael McCandless (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129089#comment-14129089
 ] 

Michael McCandless commented on LUCENE-5935:


OK this is what happened:

  * I was adding back compat indices for 4.6.1, but then on porting
forward from 4.x to trunk (rev 1562506), I noticed that there were
4.5.0 back compat indices in 4.x's TestBackCompat but they hadn't
been ported to trunk.

  * So I ported those test indices forward to trunk but they were
failing to pass TestBackCompat, which was baffling to me at the
time, so I left them commented out and added that TODO.

  * Shortly later, in rev 1563251, I found the root cause, a bug in
Lucene45DVProducer, which I fixed, and re-enabled those two, but
then I failed to remove the TODO.

Net/net we can remove this now-done TODO ... I'll go do that.


> bogus TODO inside TestBackwardsCompatibility in trunk
> -
>
> Key: LUCENE-5935
> URL: https://issues.apache.org/jira/browse/LUCENE-5935
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Priority: Blocker
>
> in TestBackwardsCompatibility in trunk we have:
> {code}
>   // TODO: these are on 4x, but something is wrong (they seem to be a too 
> old DV format):
> {code}
> I put a nocommit above it, to draw as much attention as possible to this. 
> What does this mean, that we aren't testing backwards compatibilty? are tests 
> disabled? I don't see how this is possibly a valid TODO.



--
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-6499) Log warning about multiple update request handlers

[Hoss Man (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129079#comment-14129079
 ] 

Hoss Man commented on SOLR-6499:


This is because the "/update" handler was made implicit SOLR-6302 (so even if 
it's not in your solrconfig.xml, it will be created) but was also left in the 
example solrconfig.xml (for the reasons noted in the SOLR-6302 comments.



In general the problem is that since we now have implicit request handlers, we 
need to update the existing logic in RequestHandlers.java that checks for 
redundant handler definitions to be smart enough to know the difference between 
two handlers defined in solrconfig.xml with the same name, and a handler 
defined in solrconfig.xml which is intended to override an implicit handler.

> Log warning about multiple update request handlers
> --
>
> Key: SOLR-6499
> URL: https://issues.apache.org/jira/browse/SOLR-6499
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10
>Reporter: Andreas Hubold
>Priority: Minor
>
> Solr 4.10.0 logs the following warning upon startup:
> {noformat}
> WARN  - 2014-09-09 17:49:11.455; org.apache.solr.core.RequestHandlers; 
> Multiple requestHandler registered to the same name: /update ignoring: 
> org.apache.solr.handler.UpdateRequestHandler
> {noformat}
> I've just started the Solr example with {{bin/solr start}} to get this 
> warning in {{example/logs/solr.log}}
> I don't know if this indicates a real problem but it seems everything works 
> fine despite the warning.



--
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-6452) StatsComponent "missing" stat won't work with docValues=true and indexed=false

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129050#comment-14129050
 ] 

ASF subversion and git services commented on SOLR-6452:
---

Commit 1624117 from [~tomasflobbe] in branch 'dev/trunk'
[ https://svn.apache.org/r1624117 ]

SOLR-6452: CHANGES.txt entry

> StatsComponent "missing" stat won't work with docValues=true and indexed=false
> --
>
> Key: SOLR-6452
> URL: https://issues.apache.org/jira/browse/SOLR-6452
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10, 5.0
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-6452-trunk.patch, SOLR-6452-trunk.patch, 
> SOLR-6452.patch, SOLR-6452.patch
>
>
> StatsComponent can work with DocValues, but it still required to use 
> indexed=true for the "missing" stat to work. Missing values should be 
> obtained from the docValues too.



--
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-5936) Add BWC checks to verify what is tested matches what versions we know about

[Ryan Ernst (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Ernst updated LUCENE-5936:
---
Attachment: LUCENE-5936.patch

Here's a patch, but it doesn't quite work yet.  Currently it fails because it 
thinks there should be a 411.cfs filename.  I already have a special check for 
LATEST; this just fails on trunk, since 4.11 is also not yet released (and thus 
doesn't have a bwc index).  Still working on a solution..

> Add BWC checks to verify what is tested matches what versions we know about
> ---
>
> Key: LUCENE-5936
> URL: https://issues.apache.org/jira/browse/LUCENE-5936
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Ryan Ernst
> Attachments: LUCENE-5936.patch
>
>
> This is a follow up from LUCENE-5934.  Mike has already has something like 
> this for the smoke tester, but here I am suggesting a test within the test 
> (similar to other Version tests we have which check things like deprecation 
> status of old versions).



--
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: svn commit: r1624091 - in /lucene/dev/trunk/solr/core/src: java/org/apache/solr/handler/component/ java/org/apache/solr/request/ test/org/apache/solr/handler/component/

[Tomás Fernández Löbbe]

Forgot to add the CHANGES entry. Will do that now

On Wed, Sep 10, 2014 at 11:36 AM,  wrote:

> Author: tflobbe
> Date: Wed Sep 10 18:36:27 2014
> New Revision: 1624091
>
> URL: http://svn.apache.org/r1624091
> Log:
> SOLR-6452: StatsComponent's stat 'missing' will work on fields with
> docValues=true and indexed=false
>
> Modified:
>
> lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/component/FieldFacetStats.java
>
> lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/component/StatsComponent.java
>
> lucene/dev/trunk/solr/core/src/java/org/apache/solr/request/DocValuesStats.java
>
> lucene/dev/trunk/solr/core/src/test/org/apache/solr/handler/component/StatsComponentTest.java
>
> Modified:
> lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/component/FieldFacetStats.java
> URL:
> http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/component/FieldFacetStats.java?rev=1624091&r1=1624090&r2=1624091&view=diff
>
> ==
> ---
> lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/component/FieldFacetStats.java
> (original)
> +++
> lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/component/FieldFacetStats.java
> Wed Sep 10 18:36:27 2014
> @@ -51,7 +51,7 @@ public class FieldFacetStats {
>final boolean calcDistinct;
>
>public final Map facetStatsValues;
> -
> +  private final Map missingStats;
>List> facetStatsTerms;
>
>final AtomicReader topLevelReader;
> @@ -73,6 +73,7 @@ public class FieldFacetStats {
>
>  facetStatsValues = new HashMap<>();
>  facetStatsTerms = new ArrayList<>();
> +missingStats = new HashMap<>();
>}
>
>private StatsValues getStatsValues(String key) throws IOException {
> @@ -100,8 +101,10 @@ public class FieldFacetStats {
>  if (topLevelSortedValues == null) {
>topLevelSortedValues = DocValues.getSorted(topLevelReader, name);
>  }
> +
>
>  int term = topLevelSortedValues.getOrd(docID);
> +
>  int arrIdx = term;
>  if (arrIdx >= 0 && arrIdx < topLevelSortedValues.getValueCount()) {
>final String key;
> @@ -113,6 +116,8 @@ public class FieldFacetStats {
>while (facetStatsTerms.size() <= statsTermNum) {
>  facetStatsTerms.add(new HashMap());
>}
> +
> +
>final Map statsTermCounts =
> facetStatsTerms.get(statsTermNum);
>Integer statsTermCount = statsTermCounts.get(key);
>if (statsTermCount == null) {
> @@ -122,6 +127,7 @@ public class FieldFacetStats {
>}
>return true;
>  }
> +
>  return false;
>}
>
> @@ -132,8 +138,7 @@ public class FieldFacetStats {
>  while (facetStatsTerms.size() <= statsTermNum) {
>facetStatsTerms.add(new HashMap());
>  }
> -for (Map.Entry stringIntegerEntry :
> facetStatsTerms.get(statsTermNum).entrySet()) {
> -  Map.Entry pairs = (Map.Entry) stringIntegerEntry;
> +for (Map.Entry pairs :
> facetStatsTerms.get(statsTermNum).entrySet()) {
>String key = (String) pairs.getKey();
>StatsValues facetStats = facetStatsValues.get(key);
>if (facetStats == null) {
> @@ -156,6 +161,35 @@ public class FieldFacetStats {
>  }
>}
>
> +  public void facetMissingNum(int docID) throws IOException {
> +if (topLevelSortedValues == null) {
> +  topLevelSortedValues = DocValues.getSorted(topLevelReader, name);
> +}
> +
> +int ord = topLevelSortedValues.getOrd(docID);
> +if (ord != -1) {
> +  Integer missingCount = missingStats.get(ord);
> +  if (missingCount == null) {
> +missingStats.put(ord, 1);
> +  } else {
> +missingStats.put(ord, missingCount + 1);
> +  }
> +}
> +  }
> +
> +  public void accumulateMissing() throws IOException {
> +StatsValues statsValue;
> +
> +for (Map.Entry entry : missingStats.entrySet()) {
> +  if (entry.getKey() >= 0) {
> +String key =
> topLevelSortedValues.lookupOrd(entry.getKey()).utf8ToString();
> +if ((statsValue = facetStatsValues.get(key)) != null) {
> +  statsValue.addMissing(entry.getValue());
> +}
> +  }
> +}
> +return;
> +  }
>  }
>
>
>
> Modified:
> lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/component/StatsComponent.java
> URL:
> http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/component/StatsComponent.java?rev=1624091&r1=1624090&r2=1624091&view=diff
>
> ==
> ---
> lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/component/StatsComponent.java
> (original)
> +++
> lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/component/StatsComponent.java
> Wed Sep 10 18:36:27 2014
> @@ -39,7 +39,6 @@ import org.apache.solr.common.util.Simpl
>  import org.apache.solr.common.util.StrUtils;
>  import org.apache.solr.request.DocValuesStats;
>  import org

[jira] [Created] (LUCENE-5936) Add BWC checks to verify what is tested matches what versions we know about

[Ryan Ernst (JIRA)]

Ryan Ernst created LUCENE-5936:
--

 Summary: Add BWC checks to verify what is tested matches what 
versions we know about
 Key: LUCENE-5936
 URL: https://issues.apache.org/jira/browse/LUCENE-5936
 Project: Lucene - Core
  Issue Type: Test
Reporter: Ryan Ernst


This is a follow up from LUCENE-5934.  Mike has already has something like this 
for the smoke tester, but here I am suggesting a test within the test (similar 
to other Version tests we have which check things like deprecation status of 
old versions).



--
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-5935) bogus TODO inside TestBackwardsCompatibility in trunk

[Robert Muir (JIRA)]

Robert Muir created LUCENE-5935:
---

 Summary: bogus TODO inside TestBackwardsCompatibility in trunk
 Key: LUCENE-5935
 URL: https://issues.apache.org/jira/browse/LUCENE-5935
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Priority: Blocker


in TestBackwardsCompatibility in trunk we have:
{code}
  // TODO: these are on 4x, but something is wrong (they seem to be a too 
old DV format):
{code}

I put a nocommit above it, to draw as much attention as possible to this. What 
does this mean, that we aren't testing backwards compatibilty? are tests 
disabled? I don't see how this is possibly a valid TODO.



--
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-5863) Generate backwards compatibility indexes for all 4.x releases

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129017#comment-14129017
 ] 

ASF subversion and git services commented on LUCENE-5863:
-

Commit 1624107 from [~rcmuir] in branch 'dev/trunk'
[ https://svn.apache.org/r1624107 ]

LUCENE-5863: port forward. the nocommit is intentional.

> Generate backwards compatibility indexes for all 4.x releases
> -
>
> Key: LUCENE-5863
> URL: https://issues.apache.org/jira/browse/LUCENE-5863
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Robert Muir
> Fix For: 4.10.1, 4.11, 5.0
>
> Attachments: testTheBWCTester.py
>
>
> Currently the versioning here is a total mess, and its inconsistent across 
> bugfix releases.
> We should just generate back compat indexes for every release: regardless of 
> whether the index format changed, even for bugfix releases. This ensures at 
> least we try to test that the back compat is working.



--
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-5932) SpanNearUnordered duplicate term counts itself as a match

[Steve Davids (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-5932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Davids resolved LUCENE-5932.
--
   Resolution: Duplicate
Fix Version/s: (was: 4.11)

> SpanNearUnordered duplicate term counts itself as a match
> -
>
> Key: LUCENE-5932
> URL: https://issues.apache.org/jira/browse/LUCENE-5932
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 4.9
>Reporter: Steve Davids
> Attachments: LUCENE-5932.patch
>
>
> An unordered span near with the exact same term will count the first position 
> as a match for the second term.
> A document with values: "w1 w2 w3 w4 w5"
> Query hit: spanNear([w1, w1], 1, false) -- SpanNearUnordered
> Query miss: spanNear([w1, w1], 1, true) -- SpanNearOrdered (expected)



--
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-5932) SpanNearUnordered duplicate term counts itself as a match

[Steve Davids (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128971#comment-14128971
 ] 

Steve Davids commented on LUCENE-5932:
--

Oops, you are correct - it does appear to be a duplicate.

> SpanNearUnordered duplicate term counts itself as a match
> -
>
> Key: LUCENE-5932
> URL: https://issues.apache.org/jira/browse/LUCENE-5932
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 4.9
>Reporter: Steve Davids
> Fix For: 4.11
>
> Attachments: LUCENE-5932.patch
>
>
> An unordered span near with the exact same term will count the first position 
> as a match for the second term.
> A document with values: "w1 w2 w3 w4 w5"
> Query hit: spanNear([w1, w1], 1, false) -- SpanNearUnordered
> Query miss: spanNear([w1, w1], 1, true) -- SpanNearOrdered (expected)



--
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-5863) Generate backwards compatibility indexes for all 4.x releases

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-5863:
--
Fix Version/s: 5.0
   4.11
   4.10.1

> Generate backwards compatibility indexes for all 4.x releases
> -
>
> Key: LUCENE-5863
> URL: https://issues.apache.org/jira/browse/LUCENE-5863
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 4.10.1, 4.11, 5.0
>
> Attachments: testTheBWCTester.py
>
>
> Currently the versioning here is a total mess, and its inconsistent across 
> bugfix releases.
> We should just generate back compat indexes for every release: regardless of 
> whether the index format changed, even for bugfix releases. This ensures at 
> least we try to test that the back compat is working.



--
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-5863) Generate backwards compatibility indexes for all 4.x releases

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-5863:
--
Assignee: Robert Muir

> Generate backwards compatibility indexes for all 4.x releases
> -
>
> Key: LUCENE-5863
> URL: https://issues.apache.org/jira/browse/LUCENE-5863
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Robert Muir
> Fix For: 4.10.1, 4.11, 5.0
>
> Attachments: testTheBWCTester.py
>
>
> Currently the versioning here is a total mess, and its inconsistent across 
> bugfix releases.
> We should just generate back compat indexes for every release: regardless of 
> whether the index format changed, even for bugfix releases. This ensures at 
> least we try to test that the back compat is working.



--
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-5863) Generate backwards compatibility indexes for all 4.x releases

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128969#comment-14128969
 ] 

Uwe Schindler commented on LUCENE-5863:
---

LOL, OK Thanks! :-)

> Generate backwards compatibility indexes for all 4.x releases
> -
>
> Key: LUCENE-5863
> URL: https://issues.apache.org/jira/browse/LUCENE-5863
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: testTheBWCTester.py
>
>
> Currently the versioning here is a total mess, and its inconsistent across 
> bugfix releases.
> We should just generate back compat indexes for every release: regardless of 
> whether the index format changed, even for bugfix releases. This ensures at 
> least we try to test that the back compat is working.



--
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-5863) Generate backwards compatibility indexes for all 4.x releases

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128967#comment-14128967
 ] 

Uwe Schindler commented on LUCENE-5863:
---

Robert: Will you backport at least the 3 Lucene 4.0 indexes (4.0-ALPHA, 
4.0-BETA, 4.0.0) to the 4_10 branch? This would be enough for that version to 
actually verify the fix for the brokenness seen by Ian.

Thanks, Uwe

> Generate backwards compatibility indexes for all 4.x releases
> -
>
> Key: LUCENE-5863
> URL: https://issues.apache.org/jira/browse/LUCENE-5863
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: testTheBWCTester.py
>
>
> Currently the versioning here is a total mess, and its inconsistent across 
> bugfix releases.
> We should just generate back compat indexes for every release: regardless of 
> whether the index format changed, even for bugfix releases. This ensures at 
> least we try to test that the back compat is working.



--
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-5863) Generate backwards compatibility indexes for all 4.x releases

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128965#comment-14128965
 ] 

ASF subversion and git services commented on LUCENE-5863:
-

Commit 1624103 from [~rcmuir] in branch 'dev/branches/lucene_solr_4_10'
[ https://svn.apache.org/r1624103 ]

LUCENE-5863: backport

> Generate backwards compatibility indexes for all 4.x releases
> -
>
> Key: LUCENE-5863
> URL: https://issues.apache.org/jira/browse/LUCENE-5863
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: testTheBWCTester.py
>
>
> Currently the versioning here is a total mess, and its inconsistent across 
> bugfix releases.
> We should just generate back compat indexes for every release: regardless of 
> whether the index format changed, even for bugfix releases. This ensures at 
> least we try to test that the back compat is working.



--
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-5934) 4.10 broke backwards compatibility for 4.0 indexes

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128949#comment-14128949
 ] 

ASF subversion and git services commented on LUCENE-5934:
-

Commit 1624100 from [~thetaphi] in branch 'dev/branches/lucene_solr_4_10'
[ https://svn.apache.org/r1624100 ]

Merged revision(s) 1624073 from lucene/dev/branches/branch_4x:
LUCENE-5934: Fix backwards compatibility for 4.0 indexes.

> 4.10 broke backwards compatibility for 4.0 indexes
> --
>
> Key: LUCENE-5934
> URL: https://issues.apache.org/jira/browse/LUCENE-5934
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/codecs, core/index
>Affects Versions: 4.10
>Reporter: Robert Muir
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 4.10.1, 4.11, 5.0
>
> Attachments: LUCENE-5934.patch, LUCENE-5934.patch, LUCENE-5934.patch, 
> LUCENE-5934.patch, LUCENE-5934.patch
>
>
> As reported by Ian on the user list:
> Its trying to treat them as 3.x



--
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-5863) Generate backwards compatibility indexes for all 4.x releases

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128945#comment-14128945
 ] 

ASF subversion and git services commented on LUCENE-5863:
-

Commit 1624099 from [~rcmuir] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1624099 ]

LUCENE-5863: add old indexes. anything before 2.4 is dark ages and tests wont 
even compile, even if you hack build with ancient junit and use ancient ant...

> Generate backwards compatibility indexes for all 4.x releases
> -
>
> Key: LUCENE-5863
> URL: https://issues.apache.org/jira/browse/LUCENE-5863
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: testTheBWCTester.py
>
>
> Currently the versioning here is a total mess, and its inconsistent across 
> bugfix releases.
> We should just generate back compat indexes for every release: regardless of 
> whether the index format changed, even for bugfix releases. This ensures at 
> least we try to test that the back compat is working.



--
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-5098) Add REST support for adding field types to the schema

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-5098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128937#comment-14128937
 ] 

ASF subversion and git services commented on SOLR-5098:
---

Commit 1624098 from [~thelabdude] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1624098 ]

SOLR-5098: fix eol-style

> Add REST support for adding field types to the schema
> -
>
> Key: SOLR-5098
> URL: https://issues.apache.org/jira/browse/SOLR-5098
> Project: Solr
>  Issue Type: Sub-task
>  Components: Schema and Analysis
>Reporter: Steve Rowe
>Assignee: Timothy Potter
>Priority: Minor
> Fix For: 4.11, 5.0
>
> Attachments: SOLR-5098.patch, SOLR-5098.patch, SOLR-5098.patch
>
>
> POST to {{/schema/fieldtypes}} will add one or more new field types to the 
> schema.
> PUT to {{/schema/fieldtypes/_name_}} will add the {{_name_}}'d field type to 
> the schema.



--
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-4.x-Linux (32bit/jdk1.9.0-ea-b28) - Build # 11085 - Failure!

[Timothy Potter]

my bad - 'tis fixed now ... new box didn't have auto-props enabled in
.subversion/config and of course I skipped running precommit because
this was a backport :-(

On Wed, Sep 10, 2014 at 12:49 PM, Policeman Jenkins Server
 wrote:
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/11085/
> Java: 32bit/jdk1.9.0-ea-b28 -server -XX:+UseConcMarkSweepGC
>
> All tests passed
>
> Build Log:
> [...truncated 49774 lines...]
> BUILD FAILED
> /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:491: The following 
> error occurred while executing this line:
> /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:430: The following 
> error occurred while executing this line:
> /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:105: The 
> following error occurred while executing this line:
> /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:204: The 
> following files are missing svn:eol-style (or binary svn:mime-type):
> * ./solr/core/src/java/org/apache/solr/rest/schema/FieldTypeXmlAdapter.java
> * 
> ./solr/core/src/test/org/apache/solr/rest/schema/TestManagedSchemaFieldTypeResource.java
>
> Total time: 112 minutes 6 seconds
> Build step 'Invoke Ant' marked build as failure
> [description-setter] Description set: Java: 32bit/jdk1.9.0-ea-b28 -server 
> -XX:+UseConcMarkSweepGC
> Archiving artifacts
> Recording test results
> Email was triggered for: Failure - Any
> Sending email for trigger: Failure - Any
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-6024) StatsComponent does not work for docValues enabled multiValued fields

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128936#comment-14128936
 ] 

ASF subversion and git services commented on SOLR-6024:
---

Commit 1624097 from hoss...@apache.org in branch 'dev/branches/lucene_solr_4_10'
[ https://svn.apache.org/r1624097 ]

SOLR-6024: Fix StatsComponent when using docValues=true multiValued=true (merge 
r1622525)

> StatsComponent does not work for docValues enabled multiValued fields
> -
>
> Key: SOLR-6024
> URL: https://issues.apache.org/jira/browse/SOLR-6024
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Affects Versions: 4.8
> Environment: java version "1.7.0_45"
> Mac OS X Version 10.7.5
>Reporter: Ahmet Arslan
>Assignee: Tomás Fernández Löbbe
>  Labels: StatsComponent, docValues, multiValued
> Fix For: 4.10.1, 4.11, 5.0
>
> Attachments: SOLR-6024-branch_4x.patch, SOLR-6024-trunk.patch, 
> SOLR-6024-trunk.patch, SOLR-6024-trunk.patch, SOLR-6024-trunk.patch, 
> SOLR-6024-trunk.patch, SOLR-6024.patch, SOLR-6024.patch
>
>
> Harish Agarwal reported this in solr user mailing list : 
> http://search-lucene.com/m/QTPaoTJXV1
> It is east to re-produce with default example solr setup. Following types are 
> added example schema.xml. And exampledocs are indexed.
> {code:xml}
>   docValues="true" multiValued="true"/>
>docValues="true" multiValued="true"/>
> {code}
> When {{docValues="true"}} *and* {{multiValued="true"}} are used at the same 
> time, StatsComponent throws :
> {noformat}
> ERROR org.apache.solr.core.SolrCore  – org.apache.solr.common.SolrException: 
> Type mismatch: popularity was indexed as SORTED_SET
>   at 
> org.apache.solr.request.UnInvertedField.(UnInvertedField.java:193)
>   at 
> org.apache.solr.request.UnInvertedField.getUnInvertedField(UnInvertedField.java:699)
>   at 
> org.apache.solr.handler.component.SimpleStats.getStatsFields(StatsComponent.java:319)
>   at 
> org.apache.solr.handler.component.SimpleStats.getStatsCounts(StatsComponent.java:290)
>   at 
> org.apache.solr.handler.component.StatsComponent.process(StatsComponent.java:78)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:221)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1964)
> {noformat}



--
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-6024) StatsComponent does not work for docValues enabled multiValued fields

[Hoss Man (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man updated SOLR-6024:
---
Fix Version/s: 5.0
   4.10.1

> StatsComponent does not work for docValues enabled multiValued fields
> -
>
> Key: SOLR-6024
> URL: https://issues.apache.org/jira/browse/SOLR-6024
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Affects Versions: 4.8
> Environment: java version "1.7.0_45"
> Mac OS X Version 10.7.5
>Reporter: Ahmet Arslan
>Assignee: Tomás Fernández Löbbe
>  Labels: StatsComponent, docValues, multiValued
> Fix For: 4.10.1, 4.11, 5.0
>
> Attachments: SOLR-6024-branch_4x.patch, SOLR-6024-trunk.patch, 
> SOLR-6024-trunk.patch, SOLR-6024-trunk.patch, SOLR-6024-trunk.patch, 
> SOLR-6024-trunk.patch, SOLR-6024.patch, SOLR-6024.patch
>
>
> Harish Agarwal reported this in solr user mailing list : 
> http://search-lucene.com/m/QTPaoTJXV1
> It is east to re-produce with default example solr setup. Following types are 
> added example schema.xml. And exampledocs are indexed.
> {code:xml}
>   docValues="true" multiValued="true"/>
>docValues="true" multiValued="true"/>
> {code}
> When {{docValues="true"}} *and* {{multiValued="true"}} are used at the same 
> time, StatsComponent throws :
> {noformat}
> ERROR org.apache.solr.core.SolrCore  – org.apache.solr.common.SolrException: 
> Type mismatch: popularity was indexed as SORTED_SET
>   at 
> org.apache.solr.request.UnInvertedField.(UnInvertedField.java:193)
>   at 
> org.apache.solr.request.UnInvertedField.getUnInvertedField(UnInvertedField.java:699)
>   at 
> org.apache.solr.handler.component.SimpleStats.getStatsFields(StatsComponent.java:319)
>   at 
> org.apache.solr.handler.component.SimpleStats.getStatsCounts(StatsComponent.java:290)
>   at 
> org.apache.solr.handler.component.StatsComponent.process(StatsComponent.java:78)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:221)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1964)
> {noformat}



--
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-4.x-Linux (32bit/jdk1.9.0-ea-b28) - Build # 11085 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/11085/
Java: 32bit/jdk1.9.0-ea-b28 -server -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 49774 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:491: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:430: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:105: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:204: The 
following files are missing svn:eol-style (or binary svn:mime-type):
* ./solr/core/src/java/org/apache/solr/rest/schema/FieldTypeXmlAdapter.java
* 
./solr/core/src/test/org/apache/solr/rest/schema/TestManagedSchemaFieldTypeResource.java

Total time: 112 minutes 6 seconds
Build step 'Invoke Ant' marked build as failure
[description-setter] Description set: Java: 32bit/jdk1.9.0-ea-b28 -server 
-XX:+UseConcMarkSweepGC
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-6323) ReRankingQParserPlugin should handle paging beyond number reranked

[Joel Bernstein (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128897#comment-14128897
 ] 

Joel Bernstein commented on SOLR-6323:
--

Ok, this is looking much better then the original implementation and very close 
to complete. I plan on committing this in the next day or two unless someone 
sees an issue with the new implementation.

> ReRankingQParserPlugin should handle paging beyond number reranked
> --
>
> Key: SOLR-6323
> URL: https://issues.apache.org/jira/browse/SOLR-6323
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Affects Versions: 4.9
>Reporter: Adair Kovac
>Assignee: Joel Bernstein
> Attachments: SOLR-6323.patch, SOLR-6323.patch, SOLR-6323.patch, 
> SOLR-6323.patch
>
>
> Discussed in this thread: 
> http://www.mail-archive.com/solr-user@lucene.apache.org/msg100870.html
> Currently the ReRankingQParserPlugin requires the client to drop the re-rank 
> parameter during paging if it only wants the top N documents to be re-ranked 
> and is getting past that N. This also requires that the N must fall on page 
> borders. 
> ReRankingQParserPlugin should provide transparency for the client by 
> returning results beyond N in their regular (non-reranked) order.



--
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-6452) StatsComponent "missing" stat won't work with docValues=true and indexed=false

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128895#comment-14128895
 ] 

ASF subversion and git services commented on SOLR-6452:
---

Commit 1624091 from [~tomasflobbe] in branch 'dev/trunk'
[ https://svn.apache.org/r1624091 ]

SOLR-6452: StatsComponent's stat 'missing' will work on fields with 
docValues=true and indexed=false

> StatsComponent "missing" stat won't work with docValues=true and indexed=false
> --
>
> Key: SOLR-6452
> URL: https://issues.apache.org/jira/browse/SOLR-6452
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10, 5.0
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-6452-trunk.patch, SOLR-6452-trunk.patch, 
> SOLR-6452.patch, SOLR-6452.patch
>
>
> StatsComponent can work with DocValues, but it still required to use 
> indexed=true for the "missing" stat to work. Missing values should be 
> obtained from the docValues too.



--
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-6323) ReRankingQParserPlugin should handle paging beyond number reranked

[Joel Bernstein (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein updated SOLR-6323:
-
Attachment: SOLR-6323.patch

> ReRankingQParserPlugin should handle paging beyond number reranked
> --
>
> Key: SOLR-6323
> URL: https://issues.apache.org/jira/browse/SOLR-6323
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Affects Versions: 4.9
>Reporter: Adair Kovac
>Assignee: Joel Bernstein
> Attachments: SOLR-6323.patch, SOLR-6323.patch, SOLR-6323.patch, 
> SOLR-6323.patch
>
>
> Discussed in this thread: 
> http://www.mail-archive.com/solr-user@lucene.apache.org/msg100870.html
> Currently the ReRankingQParserPlugin requires the client to drop the re-rank 
> parameter during paging if it only wants the top N documents to be re-ranked 
> and is getting past that N. This also requires that the N must fall on page 
> borders. 
> ReRankingQParserPlugin should provide transparency for the client by 
> returning results beyond N in their regular (non-reranked) order.



--
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-5863) Generate backwards compatibility indexes for all 4.x releases

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1412#comment-1412
 ] 

Robert Muir commented on LUCENE-5863:
-

Yes, it works. Just for completeness I want to at least to try to add the old 
indexes that are missing, too.

> Generate backwards compatibility indexes for all 4.x releases
> -
>
> Key: LUCENE-5863
> URL: https://issues.apache.org/jira/browse/LUCENE-5863
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: testTheBWCTester.py
>
>
> Currently the versioning here is a total mess, and its inconsistent across 
> bugfix releases.
> We should just generate back compat indexes for every release: regardless of 
> whether the index format changed, even for bugfix releases. This ensures at 
> least we try to test that the back compat is working.



--
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-5787) Get spellcheck frequency relatively to current query

[Nalini Kartha (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-5787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128884#comment-14128884
 ] 

Nalini Kartha commented on SOLR-5787:
-

[~h4k1m] I think the functionality you're looking for is exposed through 
collations as [~jdyer] explained. In order to get suggestion frequencies taking 
into account the rest of query terms, a query needs to be run and that's 
exactly what collations does - the frequency returned with collations is what 
you're looking for. So should we close this JIRA? I'll open another one for the 
fq param issue discussed above.

> Get spellcheck frequency relatively to current query
> 
>
> Key: SOLR-5787
> URL: https://issues.apache.org/jira/browse/SOLR-5787
> Project: Solr
>  Issue Type: Improvement
>  Components: spellchecker
>Affects Versions: 4.6
> Environment: Solr deployed on Jetty 9 Servlet container
>Reporter: Hakim
>Priority: Minor
>  Labels: features, newbie
>
> I guess that this functionnality isn't implemented yet. I'll begin by an 
> example to explain what I'm requesting:
> I have a lucene query that get articles satisfying a certain query. With this 
> same command, I'm getting at the same time suggestions if this query doesnt 
> return any article (so far, nothing unusual). 
> The frequency (count) associated with these suggestions is relative to all 
> index (it counts all occurences of the suggestion in the whole index). What I 
> want is that it counts only suggestion occurences satisfying current lucene 
> query.
> P.S: I'm using solr's spellcheck component (solr.DirectSolrSpellChecker).



--
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-5863) Generate backwards compatibility indexes for all 4.x releases

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128882#comment-14128882
 ] 

Uwe Schindler commented on LUCENE-5863:
---

{quote}
FYI: the tests work.
As soon as I added 4.0-BETA index, test failed:
{quote}

Perfectly! Thanks for confirmation! It should now also pass with the 4.0 index 
you added a minute ago! :-)

> Generate backwards compatibility indexes for all 4.x releases
> -
>
> Key: LUCENE-5863
> URL: https://issues.apache.org/jira/browse/LUCENE-5863
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: testTheBWCTester.py
>
>
> Currently the versioning here is a total mess, and its inconsistent across 
> bugfix releases.
> We should just generate back compat indexes for every release: regardless of 
> whether the index format changed, even for bugfix releases. This ensures at 
> least we try to test that the back compat is working.



--
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-6502) Custom search component to reduce recall of 'edismax' query.

[Peter Keegan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128872#comment-14128872
 ] 

Peter Keegan commented on SOLR-6502:


The original class name was somewhat specific to our application, so I changed 
the name, but I agree it could be more descriptive.

> Custom search component to reduce recall of 'edismax' query.
> 
>
> Key: SOLR-6502
> URL: https://issues.apache.org/jira/browse/SOLR-6502
> Project: Solr
>  Issue Type: New Feature
>Reporter: Peter Keegan
>Priority: Minor
> Attachments: LowRecallSearchComponent.zip
>
>
> Custom search component to improve query performance by reducing the normal 
> recall of the 'edismax' query. This component will set the 'mm' (minimum 
> match) parameter to 100%, requiring all keywords to match. If there are no 
> matches, 'mm' is set to 1 and the query is retried. This component is 
> registered in solrconfig.xml as '/LowRecallsearch'.



--
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-5863) Generate backwards compatibility indexes for all 4.x releases

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128876#comment-14128876
 ] 

ASF subversion and git services commented on LUCENE-5863:
-

Commit 1624090 from [~rcmuir] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1624090 ]

LUCENE-5863: add 4.0 indexes (actually from 4.0 release)

> Generate backwards compatibility indexes for all 4.x releases
> -
>
> Key: LUCENE-5863
> URL: https://issues.apache.org/jira/browse/LUCENE-5863
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: testTheBWCTester.py
>
>
> Currently the versioning here is a total mess, and its inconsistent across 
> bugfix releases.
> We should just generate back compat indexes for every release: regardless of 
> whether the index format changed, even for bugfix releases. This ensures at 
> least we try to test that the back compat is working.



--
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-5934) 4.10 broke backwards compatibility for 4.0 indexes

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128864#comment-14128864
 ] 

ASF subversion and git services commented on LUCENE-5934:
-

Commit 1624089 from [~thetaphi] in branch 'dev/trunk'
[ https://svn.apache.org/r1624089 ]

Merged revision(s) 1624073 from lucene/dev/branches/branch_4x:
LUCENE-5934: Fix backwards compatibility for 4.0 indexes.

> 4.10 broke backwards compatibility for 4.0 indexes
> --
>
> Key: LUCENE-5934
> URL: https://issues.apache.org/jira/browse/LUCENE-5934
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/codecs, core/index
>Affects Versions: 4.10
>Reporter: Robert Muir
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 4.10.1, 4.11, 5.0
>
> Attachments: LUCENE-5934.patch, LUCENE-5934.patch, LUCENE-5934.patch, 
> LUCENE-5934.patch, LUCENE-5934.patch
>
>
> As reported by Ian on the user list:
> Its trying to treat them as 3.x



--
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-5863) Generate backwards compatibility indexes for all 4.x releases

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128860#comment-14128860
 ] 

Robert Muir commented on LUCENE-5863:
-

(I am still adding indexes)

> Generate backwards compatibility indexes for all 4.x releases
> -
>
> Key: LUCENE-5863
> URL: https://issues.apache.org/jira/browse/LUCENE-5863
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: testTheBWCTester.py
>
>
> Currently the versioning here is a total mess, and its inconsistent across 
> bugfix releases.
> We should just generate back compat indexes for every release: regardless of 
> whether the index format changed, even for bugfix releases. This ensures at 
> least we try to test that the back compat is working.



--
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-5863) Generate backwards compatibility indexes for all 4.x releases

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128859#comment-14128859
 ] 

ASF subversion and git services commented on LUCENE-5863:
-

Commit 1624088 from [~rcmuir] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1624088 ]

LUCENE-5863: add 4.0-BETA and rename 4.0 to alpha

> Generate backwards compatibility indexes for all 4.x releases
> -
>
> Key: LUCENE-5863
> URL: https://issues.apache.org/jira/browse/LUCENE-5863
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: testTheBWCTester.py
>
>
> Currently the versioning here is a total mess, and its inconsistent across 
> bugfix releases.
> We should just generate back compat indexes for every release: regardless of 
> whether the index format changed, even for bugfix releases. This ensures at 
> least we try to test that the back compat is working.



--
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-5863) Generate backwards compatibility indexes for all 4.x releases

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128858#comment-14128858
 ] 

Robert Muir commented on LUCENE-5863:
-

FYI: the tests work.

As soon as I added 4.0-BETA index, test failed:
{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestBackwardsCompatibility -Dtests.method=testAddOldIndexes 
-Dtests.seed=5B7356B8D3654E5F -Dtests.locale=no_NO_NY 
-Dtests.timezone=Etc/GMT+3 -Dtests.file.encoding=UTF-8
   [junit4] ERROR   0.24s | TestBackwardsCompatibility.testAddOldIndexes <<<
   [junit4]> Throwable #1: java.io.IOException: file "_0.si" was already 
written to
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([5B7356B8D3654E5F:F786ADBD20A42A27]:0)
   [junit4]>at 
org.apache.lucene.store.MockDirectoryWrapper.createOutput(MockDirectoryWrapper.java:528)
   [junit4]>at 
org.apache.lucene.index.SegmentInfos.write3xInfo(SegmentInfos.java:610)
   [junit4]>at 
org.apache.lucene.index.SegmentInfos.write(SegmentInfos.java:535)
   [junit4]>at 
org.apache.lucene.index.SegmentInfos.prepareCommit(SegmentInfos.java:1033)
{noformat}

I then did "svn update" to bring in the fixes from LUCENE-5934, and then it 
passes.

> Generate backwards compatibility indexes for all 4.x releases
> -
>
> Key: LUCENE-5863
> URL: https://issues.apache.org/jira/browse/LUCENE-5863
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: testTheBWCTester.py
>
>
> Currently the versioning here is a total mess, and its inconsistent across 
> bugfix releases.
> We should just generate back compat indexes for every release: regardless of 
> whether the index format changed, even for bugfix releases. This ensures at 
> least we try to test that the back compat is working.



--
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-5934) 4.10 broke backwards compatibility for 4.0 indexes

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128838#comment-14128838
 ] 

Uwe Schindler edited comment on LUCENE-5934 at 9/10/14 6:19 PM:


bq. Can we move the codec check:

Mike, can you do this? I already committed to 4.x and I am now 
backporting/forward-porting.

In fact I would leave the test where it is and instead add a second test at the 
!segmentWasUpgraded() place? This feels better to me, although it might be a 
duplicate test. Better test more thorough than corrumption.


was (Author: thetaphi):
bq. Can we move the codec check:

Mike, can you do this? I already committed to 4.x and I am now 
backporting/forward-porting

> 4.10 broke backwards compatibility for 4.0 indexes
> --
>
> Key: LUCENE-5934
> URL: https://issues.apache.org/jira/browse/LUCENE-5934
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/codecs, core/index
>Affects Versions: 4.10
>Reporter: Robert Muir
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 4.10.1, 4.11, 5.0
>
> Attachments: LUCENE-5934.patch, LUCENE-5934.patch, LUCENE-5934.patch, 
> LUCENE-5934.patch, LUCENE-5934.patch
>
>
> As reported by Ian on the user list:
> Its trying to treat them as 3.x



--
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