date:20140730


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

Shawn Heisey updated SOLR-3990:
---

Attachment: SOLR-3990.patch

Patch against branch_4x, for comment.  I've centralized the getIndexSize method 
and added the size in bytes and readable units to the core stats.  For 5.0, 
will we still need the index size in the replication stats, or should the webUI 
get that info from the core stats?

> index size unavailable in gui/mbeans unless replication handler configured
> --
>
> Key: SOLR-3990
> URL: https://issues.apache.org/jira/browse/SOLR-3990
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 5.0, 4.10
>
> Attachments: SOLR-3990.patch
>
>
> Unless you configure the replication handler, the on-disk size of each core's 
> index seems to be unavailable in the gui or from the mbeans handler.  If you 
> are not doing replication, you should still be able to get the size of each 
> index without configuring things that won't be used.
> Also, I would like to get the size of the index in a consistent unit of 
> measurement, probably MB.  I understand the desire to give people a human 
> readable unit next to a number that's not enormous, but it's difficult to do 
> programmatic comparisons between values such as 787.33 MB and 23.56 GB.  That 
> may mean that the number needs to be available twice, one format to be shown 
> in the admin GUI and both formats available from the mbeans handler, for 
> scripting.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Updated] (SOLR-3990) index size unavailable in gui/mbeans unless replication handler configured


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

Shawn Heisey updated SOLR-3990:
---

Fix Version/s: (was: 4.9)
   4.10

> index size unavailable in gui/mbeans unless replication handler configured
> --
>
> Key: SOLR-3990
> URL: https://issues.apache.org/jira/browse/SOLR-3990
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 5.0, 4.10
>
>
> Unless you configure the replication handler, the on-disk size of each core's 
> index seems to be unavailable in the gui or from the mbeans handler.  If you 
> are not doing replication, you should still be able to get the size of each 
> index without configuring things that won't be used.
> Also, I would like to get the size of the index in a consistent unit of 
> measurement, probably MB.  I understand the desire to give people a human 
> readable unit next to a number that's not enormous, but it's difficult to do 
> programmatic comparisons between values such as 787.33 MB and 23.56 GB.  That 
> may mean that the number needs to be available twice, one format to be shown 
> in the admin GUI and both formats available from the mbeans handler, for 
> scripting.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5011) MemoryIndex and FVH don't play along with multi-value fields

2014-07-30 Thread David Smiley (JIRA)


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

David Smiley commented on LUCENE-5011:
--

Is this fixed by LUCENE-5444 (in Lucene 4.7?)

> MemoryIndex and FVH don't play along with multi-value fields
> 
>
> Key: LUCENE-5011
> URL: https://issues.apache.org/jira/browse/LUCENE-5011
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 4.3
>Reporter: Itamar Syn-Hershko
>
> When multi-value fields are indexed to a MemoryIndex, positions are computed 
> correctly on search but the start and end offsets and the values array index 
> aren't correct.
> Comparing the same execution path for IndexReader on a Directory impl  and 
> MemoryIndex (same document, same query, same analyzer, different Index impl), 
> the difference first shows in FieldTermStack.java line 125:
> termList.add( new TermInfo( term, dpEnum.startOffset(), dpEnum.endOffset(), 
> pos, weight ) );
> dpEnum.startOffset() and dpEnum.endOffset don't match between implementations.
> This looks like a bug in MemoryIndex, which doesn't seem to handle tokenized 
> multi-value fields all too well when positions and offsets are required.
> I should also mention we are using an Analyzer which outputs several tokens 
> at a position (a la SynonymFilter), but I don't believe this is related.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5859) Remove Version.java completely


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

Robert Muir commented on LUCENE-5859:
-

I agree, I will leave the entire topic alone. 

I hope someone else can take over the issues of fixing the versioning/back 
compat/etc.

I'm too frustrated with the situation, because i think its too complicated and 
almost created a broken release, and has the potential to almost do it again.

You can back out any of my changes if you want (this issue, or any of the other 
ones). Seriously. I just hope someone who is less emotional about fixing this 
stuff can make it better.

> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
> Attachments: LUCENE-5859_dead_code.patch
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5859) Remove Version.java completely


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

Mark Miller commented on LUCENE-5859:
-

Wow, this is a sad issue. Thanks Robert.

> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
> Attachments: LUCENE-5859_dead_code.patch
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5859) Remove Version.java completely


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

Robert Muir commented on LUCENE-5859:
-

{quote}
If you truly believe that I would argue a position with the primary motivation 
of making/keeping an API (any API) hard to use
{quote}

For the record, I absolutely do believe this, or I would not have said it.

If I opened an issue to add a mandatory "matchVersion" parameter to every HTTP 
solr api "just in case we need the mechanism", thats when people would start 
backpedaling extremely quickly. I'm sure there would be lengthy explanations 
about how "its solr but its different" but its not. Its an API either way. 

And Lucene's doesnt have to suck, by having garbage dead parameters that do 
absolutely nothing.


> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
> Attachments: LUCENE-5859_dead_code.patch
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5859) Remove Version.java completely


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

Hoss Man commented on LUCENE-5859:
--

bq. I removed dead code. There are plenty of lucene classes (including 
analyzers etc) that don't have Version params. If we need to add one, we just 
deprecate the default ctor and add it.

I want to make sure we're crystal clear about what you are suggesting, because 
it seems to be the exact opposite of what you were advocating for when you 
opened this issue.

You seem to be saying that moving forward, starting with 5.0, some class 
"FooAnalyzer" should not have any Version param in it's constructor.  if at 
some point (hypothetically: after 5.2 is released, and before 5.3) and issue 
like LUCENE-5482 pops up that adds improvement to the behavior of FooAnalyzer, 
but would break backcompat for anyone who had already used FooAnalzyer to build 
an existing index, then what should happen is:

* we should mark the {{FooAnalzyer()}} constructor as deprecated
* we should add a {{FooAnalzyer(Version matchVersion)}} constructor that adds 
the improved behavior when {{5.3 <= matchVersion}} otherwise uses the previous, 
non-improved, behavior
* we (presumably) update the FooAnalyzer class level javadocs to point out that 
for the best behavior, users need to use "new FooAnalyzer(5.3)"

...leaving us in a position where "people who don't care about back compat 
(e.g. just prototyping)"  will in fact "have to deal with the horribly complex 
versioning system." in order to get the best possible recommended behavior from 
the analyzer.


...is that really what you suggest moving forward?



bq. I'm not going to revert it. You just want to make Lucene harder to use, so 
more people will use apache solr instead.

I'm making arguments about the merrits of an API that leaves room for future 
changes, while supporting _your_ (initial) proposal to simplify the Java API 
for new users.

If you truly believe that I would argue a position with the primary motivation 
of making/keeping an API (_any_ API) hard to use, then you should be asking the 
PMC to remove me -- because anyone who would act with that kind of intentional 
malice towards any part of the code base doesn't deserve to have commit 
privileges.  

If that's really what you think of me then apparently you don't know me as well 
as i thought -- the fact that you would even type that sentence makes it 
extremely clear to me that i don't know you as well as i thought.  

Frankly, aside from school yard taunts as a kid, that's the most hurtful 
comment i can ever remember being directed at me.  If a stranger had made that 
comment I wouldn't care and could easily brush it off, but from someone i 
admire and respect ... that really fucking sucks.

Fuck you too Rob.  Fuck you too.



I'm done with this issue, i won't be reading anymore comments from it...
https://people.apache.org/~hossman/#personal

> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
> Attachments: LUCENE-5859_dead_code.patch
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
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.8.0_11) - Build # 10807 - Failure!

2014-07-30 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/10807/
Java: 32bit/jdk1.8.0_11 -server -XX:+UseG1GC

1 tests failed.
REGRESSION:  org.apache.solr.cloud.MultiThreadedOCPTest.testDistribSearch

Error Message:
Task 3002 did not complete, final state: failed

Stack Trace:
java.lang.AssertionError: Task 3002 did not complete, final state: failed
at 
__randomizedtesting.SeedInfo.seed([8CD40735F011FE8D:D32892D874E9EB1]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.MultiThreadedOCPTest.testDeduplicationOfSubmittedTasks(MultiThreadedOCPTest.java:163)
at 
org.apache.solr.cloud.MultiThreadedOCPTest.doTest(MultiThreadedOCPTest.java:72)
at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:867)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.St

[jira] [Comment Edited] (SOLR-5776) Look at speeding up using SSL with tests.

2014-07-30 Thread Steve Rowe (JIRA)


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

Steve Rowe edited comment on SOLR-5776 at 7/30/14 11:22 PM:


*edit*: prepended /sbin/ to sysctl and dmesg in the crontab, since /sbin/ isn't 
in the PATH under cron

I logged into ASF FreeBSD Jenkins's lucene.zones.apache.org and ran {{sudo su - 
hudson}} and {{crontab -e}} to put in place a cron job to run every minute.  
Here's the result (from user hudson's {{crontab -l}}):

{noformat}
# Stolen from /etc/rc.d/initrandom to unblock /dev/random
* * * * * ( ps -fauxww; /sbin/sysctl -a; date; df -ib; /sbin/dmesg; ps -fauxww 
; cat /bin/ls ) | dd of=/dev/random bs=8k 2>/dev/null
{noformat} 

When I time the above command, it takes about 0.2 seconds to run, so running 
this every minute shouldn't overwhelm the system.  Maybe it doesn't need to run 
every minute, I don't know, we can try dialling it back if this works.

I'll re-enable SSL for a couple tests on trunk that previously failed regularly 
on ASF FreeBSD Jenkins, to see if this change allows those to pass.


was (Author: steve_rowe):
I logged into ASF FreeBSD Jenkins's lucene.zones.apache.org and ran {{sudo su - 
hudson}} and {{crontab -e}} to put in place a cron job to run every minute.  
Here's the result (from user hudson's {{crontab -l}}):

{noformat}
# Stolen from /etc/rc.d/initrandom to unblock /dev/random
* * * * * ( ps -fauxww; sysctl -a; date; df -ib; dmesg; ps -fauxww ; cat 
/bin/ls ) | dd of=/dev/random bs=8k 2>/dev/null
{noformat} 

When I time the above command, it takes about 0.2 seconds to run, so running 
this every minute shouldn't overwhelm the system.  Maybe it doesn't need to run 
every minute, I don't know, we can try dialling it back if this works.

I'll re-enable SSL for a couple tests on trunk that previously failed regularly 
on ASF FreeBSD Jenkins, to see if this change allows those to pass.

> Look at speeding up using SSL with tests.
> -
>
> Key: SOLR-5776
> URL: https://issues.apache.org/jira/browse/SOLR-5776
> Project: Solr
>  Issue Type: Test
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.9, 5.0
>
> Attachments: SOLR-5776.patch, SOLR-5776.patch
>
>
> We have to disable SSL on a bunch of tests now because it appears to sometime 
> be ridiculously slow - especially in slow envs (I never see timeouts on my 
> machine).
> I was talking to Robert about this, and he mentioned that there might be some 
> settings we could change to speed it up.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Resolved] (LUCENE-5856) remove useless & 0x3f from *BitSet.get and company

2014-07-30 Thread ASF subversion and git services (JIRA)


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

Robert Muir resolved LUCENE-5856.
-

   Resolution: Fixed
Fix Version/s: 4.10
   5.0

> remove useless & 0x3f from *BitSet.get and company
> --
>
> Key: LUCENE-5856
> URL: https://issues.apache.org/jira/browse/LUCENE-5856
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Fix For: 5.0, 4.10
>
> Attachments: LUCENE-5856.patch
>
>
> java specification says:
> {quote}
> If the promoted type of the left-hand operand is long, then only the six 
> lowest-order bits of the right-hand operand are used as the shift distance. 
> It is as if the right-hand operand were subjected to a bitwise logical AND 
> operator & (§15.22.1) with the mask value 0x3f (0b11). The shift distance 
> actually used is therefore always in the range 0 to 63, inclusive.
> {quote}
> and x86 works the same way.
> if we remove this, we just see less instructions with printassembly...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5856) remove useless & 0x3f from *BitSet.get and company


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

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

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

LUCENE-5856: Optimize Fixed/Open/LongBitSet to remove unnecessary AND

> remove useless & 0x3f from *BitSet.get and company
> --
>
> Key: LUCENE-5856
> URL: https://issues.apache.org/jira/browse/LUCENE-5856
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Fix For: 5.0, 4.10
>
> Attachments: LUCENE-5856.patch
>
>
> java specification says:
> {quote}
> If the promoted type of the left-hand operand is long, then only the six 
> lowest-order bits of the right-hand operand are used as the shift distance. 
> It is as if the right-hand operand were subjected to a bitwise logical AND 
> operator & (§15.22.1) with the mask value 0x3f (0b11). The shift distance 
> actually used is therefore always in the range 0 to 63, inclusive.
> {quote}
> and x86 works the same way.
> if we remove this, we just see less instructions with printassembly...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Comment Edited] (SOLR-5776) Look at speeding up using SSL with tests.

2014-07-30 Thread Steve Rowe (JIRA)


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

Steve Rowe edited comment on SOLR-5776 at 7/30/14 11:14 PM:


bq. Steve Rowe: I have no idea what the cron-job is doing!  Can somebody 
explain and why this helps?

The cron job is feeding the entropy pool by writing to {{/dev/random}}, which 
should unblock reads from {{/dev/random}}, assuming there is some randomness in 
what gets fed in, and/or that side-effect I/O timings feed the pool.

I don't know much about this stuff, but here's some things I've read recently 
about it:

* https://we.riseup.net/debian/entropy (Linux random entropy, some Debian 
specifics, with a discussion of other OSs)
* 
http://security.stackexchange.com/questions/42952/how-can-i-measure-and-increase-entropy-on-mac-os-x
 (Q/A about OS X entropy)
* http://en.wikipedia.org/wiki/Entropy_(computing) (Brief coverage of various 
OSs' handling of entropy) 
* http://en.wikipedia.org/?title=/dev/random (random number generation on 
various OSs)
* https://wiki.freebsd.org/201308DevSummit/Security/DevRandom (FreeBSD 
/dev/random design discussion)

bq. Is there anything to change in Windows or the Linux Jenkins?

I don't know; as Hoss says above, we want to run some experiments to see if 
re-enabling SSL in tests that have had trouble in the past will cause trouble 
again.  So we should know in short order if these need changes.

{quote}
You can log into MacOSX jenkins (if its running): ssh 
jenk...@jenkins-mac.thetaphi.de (has IPv4 and IPv6 address), for the password 
send me a note. You can try out whatever you want. Please note, that the 
virtual machine gets reset to "clean and empty state" on every update, so once 
you found a good cron-job, I can persist it on the VM snapshot.
{quote}

Done - I only did two things: {{sudo touch /etc/crontab}} to enable cron 
(apparently on OSX cron doesn't do anything unless this file exists, and it 
doesn't exist until you create it); and added a crontab for the jenkins user 
via {{crontab -e}} - here's the result (via {{crontab -l}}):

{noformat}
# Stolen from FreeBSD's /etc/rc.d/initrandom to unblock /dev/random
* * * * * ( ps -faxww ; /usr/sbin/sysctl -a ; date ; df -ib ; ps -faxww ; cat 
/bin/ls ) | dd of=/dev/random bs=8k 2>/dev/null
{noformat}

I re-enabled SSL on {{TestCloudSchemaless}}, and I'll monitor Jenkins to see if 
it starts failing. 


was (Author: steve_rowe):
bq. Steve Rowe: I have no idea what the cron-job is doing!  Can somebody 
explain and why this helps?

The cron job is feeding the entropy pool by writing to {{/dev/random}}, which 
should unblock reads from {{/dev/random}}, assuming there is some randomness in 
what gets fed in, and/or that side-effect I/O timings feed the pool.

I don't much about this stuff, but here's some things I've read recently about 
it:

* https://we.riseup.net/debian/entropy (Linux random entropy, some Debian 
specifics, with a discussion of other OSs)
* 
http://security.stackexchange.com/questions/42952/how-can-i-measure-and-increase-entropy-on-mac-os-x
 (Q/A about OS X entropy)
* http://en.wikipedia.org/wiki/Entropy_(computing) (Brief coverage of various 
OSs' handling of entropy) 
* http://en.wikipedia.org/?title=/dev/random (random number generation on 
various OSs)
* https://wiki.freebsd.org/201308DevSummit/Security/DevRandom (FreeBSD 
/dev/random design discussion)

bq. Is there anything to change in Windows or the Linux Jenkins?

I don't know; as Hoss says above, we want to run some experiments to see if 
re-enabling SSL in tests that have had trouble in the past will cause trouble 
again.  So we should know in short order if these need changes.

{quote}
You can log into MacOSX jenkins (if its running): ssh 
jenk...@jenkins-mac.thetaphi.de (has IPv4 and IPv6 address), for the password 
send me a note. You can try out whatever you want. Please note, that the 
virtual machine gets reset to "clean and empty state" on every update, so once 
you found a good cron-job, I can persist it on the VM snapshot.
{quote}

Done - I only did two things: {{sudo touch /etc/crontab}} to enable cron 
(apparently on OSX cron doesn't do anything unless this file exists, and it 
doesn't exist until you create it); and added a crontab for the jenkins user 
via {{crontab -e}} - here's the result (via {{crontab -l}}):

{noformat}
# Stolen from FreeBSD's /etc/rc.d/initrandom to unblock /dev/random
* * * * * ( ps -faxww ; /usr/sbin/sysctl -a ; date ; df -ib ; ps -faxww ; cat 
/bin/ls ) | dd of=/dev/random bs=8k 2>/dev/null
{noformat}

I re-enabled SSL on {{TestCloudSchemaless}}, and I'll monitor Jenkins to see if 
it starts failing. 

> Look at speeding up using SSL with tests.
> -
>
> Key: SOLR-5776
> URL: https://issues.apache.org/jira/browse/SOLR-5776
> P

[jira] [Commented] (LUCENE-5859) Remove Version.java completely


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

Robert Muir commented on LUCENE-5859:
-

I'm not going to revert it. You just want to make Lucene harder to use, so more 
people will use apache solr instead.

I removed dead code. There are plenty of lucene classes (including analyzers 
etc) that don't have Version params. If we need to add one, we just deprecate 
the default ctor and add it.

> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
> Attachments: LUCENE-5859_dead_code.patch
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5859) Remove Version.java completely

2014-07-30 Thread ASF subversion and git services (JIRA)


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

Hoss Man commented on LUCENE-5859:
--

bq. Commit 1614778 from Robert Muir in branch 'dev/trunk'

Please revert this until there can be more discussion.

bq. And you will notice all the backcompat is preserved: again no runtime 
behavior changed here. I didnt change the back compat.

This commit may not change the backcompat behavior of any existing class, but 
you hobbled our ability to make _future_ changes w/o jumping through hoops to 
avoid breaking back compat.

You seem to be conflating a general API convention that _allows_ for variations 
in behavior with the idea that if every class following this convention doesn't 
already take advantage of this behavior then it's "dead code" that is in some 
way broken.

bq. ThaiAnalyzer, TurkishAnalyzer, NGrams, unfortunately they all still have 
this silly parameter, because they actually make use of it, for back compat 
purposes since they had serious changes in 4.x.

It boggles my mind how you can point out that these classes remain unchanged, 
and still call the param "silly" while you gut it from all other classes 
baffles me.

Let's look at TurkishAnalyzer for example -- it uses the matchVersion param to 
decide whether or not to include "ApostropheFilter" in the stream, because in 
4.8, Ahmet suggested adding the ApostropheFilter and you thought it was a great 
idea and should be part of the default behavior of TurkishAnalyzer.

The fact that TurkishAnalyzer already had a constructor that took in a Version 
param is the reason we could make this change to the default behavior of the 
analyzer, and improve the  out of the box experience for all future users of 
the class, w/o breaking any back compact for existing users.

if you had committed r1614778 prior to LUCENE-5482 being opened, and included 
TurkishAnalyzer in the list of classes you purged Version from, we would not 
have been able to change the _default_ behavior of TurkishAnalyzer w/o breaking 
backcompat for existing users.  This wasn't about a "bug fix" it was about an 
improved default user experience moving forward, w/o breaking things for 
existing users who had working systems

What you have done now is put is in the position that for any similar 
improvements that anyone ever suggests to any analyzer (except ThaiAnalyzer and 
TurkishAnalyzer which you spared) we either can't change the default behavior, 
or we have to break backcompat for existing users.

(you may argue that this is only a trunk change, but that just kicks the can 
down the road -- w/o these constructors in place when 5.0 is released, we'll 
face all the same problems in the 5.x releases that the existence of Version 
has helped us avoid in the 4.x release)



* Your initial suggestion of adding non-Version constructors for people who 
don't care about backcompat was a good one.
* your r1614698 commit to cleanup and simplify 99.9% of the calls to 
newIndexWriterConfig from tests was also a great simplification
* r1614778 is a terrible, crippling, blow to our ability to make changes in the 
future w/o breaking back compat to existing users.



> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
> Attachments: LUCENE-5859_dead_code.patch
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-5986) Don't allow runaway queries from harming Solr cluster health or search performance

2014-07-30 Thread Steve Davids (JIRA)


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

Steve Davids commented on SOLR-5986:


There doesn't appear to be any Lucene code that is specifically honoring a 
thread interrupt, so if Solr/Lucene is busy enumerating terms in a continual 
for loop, sending an interrupt won't actually do anything. The Java code needs 
to check if the thread has been interrupted, if so, then bail on the current 
process.

Blur does this by creating their own "ExitableTerms", "ExitableTermsEnum", etc 
where every time the enum next method is called, it will check to see if the 
thread has been interrupted, if it is then an exception is thrown which halts 
processing of the query. 
https://git-wip-us.apache.org/repos/asf?p=incubator-blur.git;a=blob;f=blur-store/src/main/java/org/apache/blur/index/ExitableReader.java;h=8321dd27d3537ee239f876448e56e8296407700b;hb=61480125dee51c469a4921004f6daf590410bca6

Performing the thread interrupt check within Lucene seems reasonable for things 
that may take a long time to complete, enumerating terms is one of them.

> Don't allow runaway queries from harming Solr cluster health or search 
> performance
> --
>
> Key: SOLR-5986
> URL: https://issues.apache.org/jira/browse/SOLR-5986
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Steve Davids
>Priority: Critical
> Fix For: 4.9
>
>
> The intent of this ticket is to have all distributed search requests stop 
> wasting CPU cycles on requests that have already timed out or are so 
> complicated that they won't be able to execute. We have come across a case 
> where a nasty wildcard query within a proximity clause was causing the 
> cluster to enumerate terms for hours even though the query timeout was set to 
> minutes. This caused a noticeable slowdown within the system which made us 
> restart the replicas that happened to service that one request, the worst 
> case scenario are users with a relatively low zk timeout value will have 
> nodes start dropping from the cluster due to long GC pauses.
> [~amccurry] Built a mechanism into Apache Blur to help with the issue in 
> BLUR-142 (see commit comment for code, though look at the latest code on the 
> trunk for newer bug fixes).
> Solr should be able to either prevent these problematic queries from running 
> by some heuristic (possibly estimated size of heap usage) or be able to 
> execute a thread interrupt on all query threads once the time threshold is 
> met. This issue mirrors what others have discussed on the mailing list: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200903.mbox/%3c856ac15f0903272054q2dbdbd19kea3c5ba9e105b...@mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5856) remove useless & 0x3f from *BitSet.get and company


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

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

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

LUCENE-5856: Optimize Fixed/Open/LongBitSet to remove unnecessary AND

> remove useless & 0x3f from *BitSet.get and company
> --
>
> Key: LUCENE-5856
> URL: https://issues.apache.org/jira/browse/LUCENE-5856
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-5856.patch
>
>
> java specification says:
> {quote}
> If the promoted type of the left-hand operand is long, then only the six 
> lowest-order bits of the right-hand operand are used as the shift distance. 
> It is as if the right-hand operand were subjected to a bitwise logical AND 
> operator & (§15.22.1) with the mask value 0x3f (0b11). The shift distance 
> actually used is therefore always in the range 0 to 63, inclusive.
> {quote}
> and x86 works the same way.
> if we remove this, we just see less instructions with printassembly...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
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


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

Robert Muir commented on LUCENE-5863:
-

As part of this I obviously want to change 
http://wiki.apache.org/lucene-java/ReleaseTodo so we just do it this way in the 
future.

Its kind of annoying to generate the indexes, but its not so horrible. Maybe we 
can figure out a way to make it smoother in the process.

> 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
>
> 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.2#6252)

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

[jira] [Created] (LUCENE-5863) Generate backwards compatibility indexes for all 4.x releases

Robert Muir created LUCENE-5863:
---

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


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.2#6252)

-
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 # 4785 - Still Failing

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

2 tests failed.
REGRESSION:  org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch

Error Message:
No live SolrServers available to handle this request:[https://127.0.0.1:62629]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[https://127.0.0.1:62629]
at 
org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:319)
at 
org.apache.solr.client.solrj.impl.CloudSolrServer.request(CloudSolrServer.java:659)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1506)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1527)
at 
org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.doTest(ChaosMonkeySafeLeaderTest.java:164)
at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:865)
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 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(

[jira] [Commented] (LUCENE-5859) Remove Version.java completely

2014-07-30 Thread ASF subversion and git services (JIRA)


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

Robert Muir commented on LUCENE-5859:
-

And you will notice all the backcompat is preserved: again no runtime behavior 
changed here. I didnt change the back compat.

ThaiAnalyzer, TurkishAnalyzer, NGrams, unfortunately they all still have this 
silly parameter, because they actually make use of it, for back compat purposes 
since they had serious changes in 4.x.

But the vast majority of these version variables were just unnecessary 
confusion to the API, relics from a past life, that did nothing at all (you 
could even pass null if you like, didnt matter).

> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
> Attachments: LUCENE-5859_dead_code.patch
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5859) Remove Version.java completely


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

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

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

LUCENE-5859: remove dead code: changes no runtime behavior, these are all 
unused variables

> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
> Attachments: LUCENE-5859_dead_code.patch
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Updated] (LUCENE-5859) Remove Version.java completely

2014-07-30 Thread ASF subversion and git services (JIRA)


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

Robert Muir updated LUCENE-5859:


Attachment: LUCENE-5859_dead_code.patch

Here is a patch removing all the dead code from trunk.

It doesnt "remove version.java completely" or anything like that. It changes no 
runtime behavior at all. 

All it does is remove useless parameters: parameters that were added way back 
in the day like in Lucene 2.4 when a bug was found, that are now totally 
irrelevant.

This is really simple dead code removal. There is no reason for CharArraySet to 
require a Version parameter anymore, its a simple collection that just stores 
strings. 

Sure, its possible some of this could have a bug in the future, but we can't 
add Version parameters to every api "in case it might have a bug". If it 
happens, we deprecate and do the right thing if we must.

But for now, we should remove this dead code. It was a simple omission when I 
tried to remove deprecations in trunk previously, I removed some of them, but I 
also missed some, I didn't get all of them. Here i just do a more thorough job.

We should still rethink this version mechanism: e.g. make it an optional 
parameter for those who care about it, or remove it completely. It seriously 
hurts the usability of the api. 

But there is no way in hell I will just leave dead code in trunk. We have to 
refactor away these relics.

> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
> Attachments: LUCENE-5859_dead_code.patch
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-5776) Look at speeding up using SSL with tests.

2014-07-30 Thread Steve Rowe (JIRA)


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

Steve Rowe commented on SOLR-5776:
--

bq. Steve Rowe: I have no idea what the cron-job is doing!  Can somebody 
explain and why this helps?

The cron job is feeding the entropy pool by writing to {{/dev/random}}, which 
should unblock reads from {{/dev/random}}, assuming there is some randomness in 
what gets fed in, and/or that side-effect I/O timings feed the pool.

I don't much about this stuff, but here's some things I've read recently about 
it:

* https://we.riseup.net/debian/entropy (Linux random entropy, some Debian 
specifics, with a discussion of other OSs)
* 
http://security.stackexchange.com/questions/42952/how-can-i-measure-and-increase-entropy-on-mac-os-x
 (Q/A about OS X entropy)
* http://en.wikipedia.org/wiki/Entropy_(computing) (Brief coverage of various 
OSs' handling of entropy) 
* http://en.wikipedia.org/?title=/dev/random (random number generation on 
various OSs)
* https://wiki.freebsd.org/201308DevSummit/Security/DevRandom (FreeBSD 
/dev/random design discussion)

bq. Is there anything to change in Windows or the Linux Jenkins?

I don't know; as Hoss says above, we want to run some experiments to see if 
re-enabling SSL in tests that have had trouble in the past will cause trouble 
again.  So we should know in short order if these need changes.

{quote}
You can log into MacOSX jenkins (if its running): ssh 
jenk...@jenkins-mac.thetaphi.de (has IPv4 and IPv6 address), for the password 
send me a note. You can try out whatever you want. Please note, that the 
virtual machine gets reset to "clean and empty state" on every update, so once 
you found a good cron-job, I can persist it on the VM snapshot.
{quote}

Done - I only did two things: {{sudo touch /etc/crontab}} to enable cron 
(apparently on OSX cron doesn't do anything unless this file exists, and it 
doesn't exist until you create it); and added a crontab for the jenkins user 
via {{crontab -e}} - here's the result (via {{crontab -l}}):

{noformat}
# Stolen from FreeBSD's /etc/rc.d/initrandom to unblock /dev/random
* * * * * ( ps -faxww ; /usr/sbin/sysctl -a ; date ; df -ib ; ps -faxww ; cat 
/bin/ls ) | dd of=/dev/random bs=8k 2>/dev/null
{noformat}

I re-enabled SSL on {{TestCloudSchemaless}}, and I'll monitor Jenkins to see if 
it starts failing. 

> Look at speeding up using SSL with tests.
> -
>
> Key: SOLR-5776
> URL: https://issues.apache.org/jira/browse/SOLR-5776
> Project: Solr
>  Issue Type: Test
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.9, 5.0
>
> Attachments: SOLR-5776.patch, SOLR-5776.patch
>
>
> We have to disable SSL on a bunch of tests now because it appears to sometime 
> be ridiculously slow - especially in slow envs (I never see timeouts on my 
> machine).
> I was talking to Robert about this, and he mentioned that there might be some 
> settings we could change to speed it up.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-5776) Look at speeding up using SSL with tests.


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

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

Commit 1614775 from [~sar...@syr.edu] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1614775 ]

SOLR-5776: Re-enable SSL for this test, to see if attempts to increase the 
entropy pool on ASF FreeBSD Jenkins and Policeman MacOSX Jenkins are helping at 
all. (merged trunk r1614774)

> Look at speeding up using SSL with tests.
> -
>
> Key: SOLR-5776
> URL: https://issues.apache.org/jira/browse/SOLR-5776
> Project: Solr
>  Issue Type: Test
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.9, 5.0
>
> Attachments: SOLR-5776.patch, SOLR-5776.patch
>
>
> We have to disable SSL on a bunch of tests now because it appears to sometime 
> be ridiculously slow - especially in slow envs (I never see timeouts on my 
> machine).
> I was talking to Robert about this, and he mentioned that there might be some 
> settings we could change to speed it up.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-5776) Look at speeding up using SSL with tests.

2014-07-30 Thread ASF subversion and git services (JIRA)


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

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

Commit 1614774 from [~sar...@syr.edu] in branch 'dev/trunk'
[ https://svn.apache.org/r1614774 ]

SOLR-5776: Re-enable SSL for this test, to see if attempts to increase the 
entropy pool on ASF FreeBSD Jenkins and Policeman MacOSX Jenkins are helping at 
all.

> Look at speeding up using SSL with tests.
> -
>
> Key: SOLR-5776
> URL: https://issues.apache.org/jira/browse/SOLR-5776
> Project: Solr
>  Issue Type: Test
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.9, 5.0
>
> Attachments: SOLR-5776.patch, SOLR-5776.patch
>
>
> We have to disable SSL on a bunch of tests now because it appears to sometime 
> be ridiculously slow - especially in slow envs (I never see timeouts on my 
> machine).
> I was talking to Robert about this, and he mentioned that there might be some 
> settings we could change to speed it up.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5859) Remove Version.java completely


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

Robert Muir commented on LUCENE-5859:
-

{quote}
There is indeed a technical justification: The Version parameter may be useless 
now, but once we add new features to StandardAnalyzer, the Version parameter 
gets useful again, so we need to re-add it - leading to the known backwards 
problems. This again brings the problem that uses, who started at 5.0 will not 
have a defined value for it in 5.1 and then we have problems. In my personal 
opinion, every Analyzer must have the Version parameter mandatory.
{quote}

This is so bogus, Im not even going to have this conversation with you. 

We cannot corrupt our API with useless parameters that do nothing. 

As soon as I have tests passing, I am removing all this dead code!

> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5862) Old segments not deleted on merge

2014-07-30 Thread Adrien Grand (JIRA)


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

Adrien Grand commented on LUCENE-5862:
--

This sounds like something during your import process opened index readers and 
didn't close when? The restart released the old readers, that is why associated 
segments got deleted.

> Old segments not deleted on merge
> -
>
> Key: LUCENE-5862
> URL: https://issues.apache.org/jira/browse/LUCENE-5862
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 4.9
> Environment: Linux bigindy5 3.14.1-1.el6.elrepo.x86_64 #1 SMP Mon Apr 
> 14 19:29:19 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_55"
> Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)
> [root@bigindy5 s5_0]# cat /etc/redhat-release
> CentOS release 6.5 (Final)
>Reporter: Shawn Heisey
> Fix For: 5.0, 4.10
>
>
> After a full rebuild with the dataimport handler on a Solr install upgraded 
> to Solr 4.9.0, I ended up with an index that was considerably larger than the 
> one it replaced (built by 4.7.2), 28GB instead of 20GB.  I also upgraded a 
> third-party component at the same time, to a version which has been tested 
> with Solr 4.9.0.  The config didn't change at all.  Optimizing the index did 
> not shrink it.
> At first I thought there must have been something different about the way the 
> new version worked, or possibly a change/bug in the third-party component.
> After looking deeper, I discovered that the optimization process had created 
> one segment that was 20GB in size, but there were also a number of other 
> segments on the disk, all of which were several hours older than the large 
> segment.  Another optimize created a new segment of 20GB, and the previous 
> segment of 20GB was deleted, but the older segments remained.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5860) Use Terms.getMin/Max to speed up range queries/filters

2014-07-30 Thread Yonik Seeley (JIRA)


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

Yonik Seeley commented on LUCENE-5860:
--

Wouldn't NRQ benefit at least as much as TRQ?  That said, this is about 
speeding up what is already the fastest case, so I don't have an opinion if the 
complexity added complexity is worth it.

> Use Terms.getMin/Max to speed up range queries/filters
> --
>
> Key: LUCENE-5860
> URL: https://issues.apache.org/jira/browse/LUCENE-5860
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, 4.10
>
> Attachments: LUCENE-5860.patch
>
>
> As of LUCENE-5610, Lucene's Terms API now exposes min and max terms in
> each field.  I think we can use this in our term/numeric range
> query/filters to avoid visiting a given segment by detecting up front
> that the terms in the segment don't overlap with the query's range.
> Even though block tree avoids disk seeks in certain cases when the
> term cannot exist on-disk, I think this change would further avoid
> disk seeks in additional cases because the min/max term has
> more/different information than the in-memory FST terms index.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5862) Old segments not deleted on merge


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

Shawn Heisey commented on LUCENE-5862:
--

Somewhat interesting development: I changed the solrconfig to enable 
infoStream, and when I restarted Solr, all those shards dropped from 28GB to 
under 20GB - the extra segments got deleted.


> Old segments not deleted on merge
> -
>
> Key: LUCENE-5862
> URL: https://issues.apache.org/jira/browse/LUCENE-5862
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 4.9
> Environment: Linux bigindy5 3.14.1-1.el6.elrepo.x86_64 #1 SMP Mon Apr 
> 14 19:29:19 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_55"
> Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)
> [root@bigindy5 s5_0]# cat /etc/redhat-release
> CentOS release 6.5 (Final)
>Reporter: Shawn Heisey
> Fix For: 5.0, 4.10
>
>
> After a full rebuild with the dataimport handler on a Solr install upgraded 
> to Solr 4.9.0, I ended up with an index that was considerably larger than the 
> one it replaced (built by 4.7.2), 28GB instead of 20GB.  I also upgraded a 
> third-party component at the same time, to a version which has been tested 
> with Solr 4.9.0.  The config didn't change at all.  Optimizing the index did 
> not shrink it.
> At first I thought there must have been something different about the way the 
> new version worked, or possibly a change/bug in the third-party component.
> After looking deeper, I discovered that the optimization process had created 
> one segment that was 20GB in size, but there were also a number of other 
> segments on the disk, all of which were several hours older than the large 
> segment.  Another optimize created a new segment of 20GB, and the previous 
> segment of 20GB was deleted, but the older segments remained.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-5986) Don't allow runaway queries from harming Solr cluster health or search performance

2014-07-30 Thread Anshum Gupta (JIRA)


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

Anshum Gupta commented on SOLR-5986:


I'm trying to solve this problem a little differently. Just for the curious 
(before there's a patch), I intend to have a tracking thread that'd look up a 
list of requests at the core level and interrupt the requests that have timed 
out. I'm hoping that lucene would play well with it and respect the interrupt 
too solving the problem of a query running for hours/days.
That would keep this change at Solr level without being really intrusive and 
requiring change in all TermsEnum implementations out there.

> Don't allow runaway queries from harming Solr cluster health or search 
> performance
> --
>
> Key: SOLR-5986
> URL: https://issues.apache.org/jira/browse/SOLR-5986
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Steve Davids
>Priority: Critical
> Fix For: 4.9
>
>
> The intent of this ticket is to have all distributed search requests stop 
> wasting CPU cycles on requests that have already timed out or are so 
> complicated that they won't be able to execute. We have come across a case 
> where a nasty wildcard query within a proximity clause was causing the 
> cluster to enumerate terms for hours even though the query timeout was set to 
> minutes. This caused a noticeable slowdown within the system which made us 
> restart the replicas that happened to service that one request, the worst 
> case scenario are users with a relatively low zk timeout value will have 
> nodes start dropping from the cluster due to long GC pauses.
> [~amccurry] Built a mechanism into Apache Blur to help with the issue in 
> BLUR-142 (see commit comment for code, though look at the latest code on the 
> trunk for newer bug fixes).
> Solr should be able to either prevent these problematic queries from running 
> by some heuristic (possibly estimated size of heap usage) or be able to 
> execute a thread interrupt on all query threads once the time threshold is 
> met. This issue mirrors what others have discussed on the mailing list: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200903.mbox/%3c856ac15f0903272054q2dbdbd19kea3c5ba9e105b...@mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6294) The JsonLoader should accept a single doc without wrapping in an array


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

Hoss Man commented on SOLR-6294:


bq. I really don't like having separate APIs for one doc vs. multiple docs...

I don't think anyone suggested that?

what was suggested was a new request param (i suggested 
{{json.command=true|false}}), that would indicate when a top level JSON object 
should be interpreted as a set of commands, or as a single document.

if this request param exists, then a new sample configuration could be supplied 
(noble suggested {{/update/json/doc}} - i would suggest {{/update/json/docs}} 
(plural) might be better) which could have a {{}} block 
setting {{json.command=true}} ... which would mean you could send *either* one 
doc or multiple docs to that endpoint, and they would just plain work. if you 
use {{/update}} or {{/update/json}} then for backcompat reasons, a top level 
JSON object would be interpreted as a list of commands -- but you could 
override that with {{json.command=true}} in the request.

bq. How about deprecating the existing approach in favor a new one that 
properly captures commands, single docs, and multiple docs and is clean for 
users? 

I'm not sure i understand what you are proposing? .. there are only 3 "top 
level" constructs we could have in a valid JSON document: arrays, objects, and 
literals -- if you want both top level objects / top level arrays to be 
interpreted as a doc / list of docs that doesn't leave much to put commands 
(only the most trivial command could be specified by a top level string/number 
primitive.

If folks feel like sending single documents should be the "default" and 
commands should be considered abnormal (a sentiment i generally agree with, 
particularly since most basic commands can already be sent as request params) 
then i already made a suggestion to how to move forward with that goal:

bq. we can also change the default value of the new request param (and thus, 
the default behavior) in 5.0 so that by default we assume everything is a doc, 
and you have to send "json.command=true" if you want your top level braces to 
be interpreted as starting a set of commands.



bq. Ease of use has to be all about the user's data and their questions for it, 
not about idiosyncrasies in API design to workaround previous approaches.

Nothing in the suggestion Noble and i coalesced towards has anything to do with 
"working around" the existing API -- it's about ensuring that as the API 
evolves to be more freindly towards new users, we don't alienate existing users 
by breaking their shit if we don't have to, and giving them an easy way to edit 
their config to make their shit keep working if we change the default behavior.

> The JsonLoader should accept a single doc without wrapping in an array
> --
>
> Key: SOLR-6294
> URL: https://issues.apache.org/jira/browse/SOLR-6294
> Project: Solr
>  Issue Type: Bug
>  Components: update
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
>
> This is the multi document input command
> {noformat}
> curl http://localhost:8983/solr/update/json -H 
> 'Content-type:application/json' -d '
> [
>  {"id" : "TestDoc1", "title" : "test1"},
> ]'
> {noformat}
> The following also should be a valid update command for a single doc
> {noformat}
> curl http://localhost:8983/solr/update/json -H 
> 'Content-type:application/json' -d '
>  {"id" : "TestDoc1", "title" : "test1"},
> '
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5862) Old segments not deleted on merge


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

Shawn Heisey commented on LUCENE-5862:
--

I do not know if there is anything in the third-party component that might 
trigger a problem with segment merging.

> Old segments not deleted on merge
> -
>
> Key: LUCENE-5862
> URL: https://issues.apache.org/jira/browse/LUCENE-5862
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 4.9
> Environment: Linux bigindy5 3.14.1-1.el6.elrepo.x86_64 #1 SMP Mon Apr 
> 14 19:29:19 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_55"
> Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)
> [root@bigindy5 s5_0]# cat /etc/redhat-release
> CentOS release 6.5 (Final)
>Reporter: Shawn Heisey
> Fix For: 5.0, 4.10
>
>
> After a full rebuild with the dataimport handler on a Solr install upgraded 
> to Solr 4.9.0, I ended up with an index that was considerably larger than the 
> one it replaced (built by 4.7.2), 28GB instead of 20GB.  I also upgraded a 
> third-party component at the same time, to a version which has been tested 
> with Solr 4.9.0.  The config didn't change at all.  Optimizing the index did 
> not shrink it.
> At first I thought there must have been something different about the way the 
> new version worked, or possibly a change/bug in the third-party component.
> After looking deeper, I discovered that the optimization process had created 
> one segment that was 20GB in size, but there were also a number of other 
> segments on the disk, all of which were several hours older than the large 
> segment.  Another optimize created a new segment of 20GB, and the previous 
> segment of 20GB was deleted, but the older segments remained.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Comment Edited] (LUCENE-5862) Old segments not deleted on merge


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

Shawn Heisey edited comment on LUCENE-5862 at 7/30/14 8:50 PM:
---

I do not know if there is anything in the third-party component that might 
trigger a problem with segment merging.  I can also run another test without 
the third-party component enabled.


was (Author: elyograg):
I do not know if there is anything in the third-party component that might 
trigger a problem with segment merging.

> Old segments not deleted on merge
> -
>
> Key: LUCENE-5862
> URL: https://issues.apache.org/jira/browse/LUCENE-5862
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 4.9
> Environment: Linux bigindy5 3.14.1-1.el6.elrepo.x86_64 #1 SMP Mon Apr 
> 14 19:29:19 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_55"
> Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)
> [root@bigindy5 s5_0]# cat /etc/redhat-release
> CentOS release 6.5 (Final)
>Reporter: Shawn Heisey
> Fix For: 5.0, 4.10
>
>
> After a full rebuild with the dataimport handler on a Solr install upgraded 
> to Solr 4.9.0, I ended up with an index that was considerably larger than the 
> one it replaced (built by 4.7.2), 28GB instead of 20GB.  I also upgraded a 
> third-party component at the same time, to a version which has been tested 
> with Solr 4.9.0.  The config didn't change at all.  Optimizing the index did 
> not shrink it.
> At first I thought there must have been something different about the way the 
> new version worked, or possibly a change/bug in the third-party component.
> After looking deeper, I discovered that the optimization process had created 
> one segment that was 20GB in size, but there were also a number of other 
> segments on the disk, all of which were several hours older than the large 
> segment.  Another optimize created a new segment of 20GB, and the previous 
> segment of 20GB was deleted, but the older segments remained.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5862) Old segments not deleted on merge


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

Shawn Heisey commented on LUCENE-5862:
--

This problem seems more like a Lucene problem than a Solr problem, which is why 
I opened it in the LUCENE project.  I'm not even sure at this point that it's a 
bug, I suppose it could have been something that I did.

I will repeat the rebuild with the infoStream enabled and attach at least one 
of those logs.


> Old segments not deleted on merge
> -
>
> Key: LUCENE-5862
> URL: https://issues.apache.org/jira/browse/LUCENE-5862
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 4.9
> Environment: Linux bigindy5 3.14.1-1.el6.elrepo.x86_64 #1 SMP Mon Apr 
> 14 19:29:19 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_55"
> Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)
> [root@bigindy5 s5_0]# cat /etc/redhat-release
> CentOS release 6.5 (Final)
>Reporter: Shawn Heisey
> Fix For: 5.0, 4.10
>
>
> After a full rebuild with the dataimport handler on a Solr install upgraded 
> to Solr 4.9.0, I ended up with an index that was considerably larger than the 
> one it replaced (built by 4.7.2), 28GB instead of 20GB.  I also upgraded a 
> third-party component at the same time, to a version which has been tested 
> with Solr 4.9.0.  The config didn't change at all.  Optimizing the index did 
> not shrink it.
> At first I thought there must have been something different about the way the 
> new version worked, or possibly a change/bug in the third-party component.
> After looking deeper, I discovered that the optimization process had created 
> one segment that was 20GB in size, but there were also a number of other 
> segments on the disk, all of which were several hours older than the large 
> segment.  Another optimize created a new segment of 20GB, and the previous 
> segment of 20GB was deleted, but the older segments remained.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Created] (LUCENE-5862) Old segments not deleted on merge

Shawn Heisey created LUCENE-5862:


 Summary: Old segments not deleted on merge
 Key: LUCENE-5862
 URL: https://issues.apache.org/jira/browse/LUCENE-5862
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 4.9
 Environment: Linux bigindy5 3.14.1-1.el6.elrepo.x86_64 #1 SMP Mon Apr 
14 19:29:19 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux

java version "1.7.0_55"
Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)

[root@bigindy5 s5_0]# cat /etc/redhat-release
CentOS release 6.5 (Final)

Reporter: Shawn Heisey
 Fix For: 5.0, 4.10


After a full rebuild with the dataimport handler on a Solr install upgraded to 
Solr 4.9.0, I ended up with an index that was considerably larger than the one 
it replaced (built by 4.7.2), 28GB instead of 20GB.  I also upgraded a 
third-party component at the same time, to a version which has been tested with 
Solr 4.9.0.  The config didn't change at all.  Optimizing the index did not 
shrink it.

At first I thought there must have been something different about the way the 
new version worked, or possibly a change/bug in the third-party component.

After looking deeper, I discovered that the optimization process had created 
one segment that was 20GB in size, but there were also a number of other 
segments on the disk, all of which were several hours older than the large 
segment.  Another optimize created a new segment of 20GB, and the previous 
segment of 20GB was deleted, but the older segments remained.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5860) Use Terms.getMin/Max to speed up range queries/filters


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

Uwe Schindler commented on LUCENE-5860:
---

Hi, looks interesting, although I am not sure if the added complexity, 
especially in NRQ is woth the small speed improvement. I have to carefully 
apply the patch and review it, maybe tomorrow.

Without a good benchmark result that brings a good speed improvemenmt, I would 
-1 it for NRQ (especially as NRQ only looks at few terms at all - at least with 
my preferred precisionSteps, I still disagree with the new defaults). For NRQ 
it is also not sure, if the additional min/max lookup cost is useful (because 
the min/max term in the term dictionary does not help for the NRQ case, you 
need the min/max shift=0 term).

Go for it for TRQ! Strong +1

> Use Terms.getMin/Max to speed up range queries/filters
> --
>
> Key: LUCENE-5860
> URL: https://issues.apache.org/jira/browse/LUCENE-5860
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, 4.10
>
> Attachments: LUCENE-5860.patch
>
>
> As of LUCENE-5610, Lucene's Terms API now exposes min and max terms in
> each field.  I think we can use this in our term/numeric range
> query/filters to avoid visiting a given segment by detecting up front
> that the terms in the segment don't overlap with the query's range.
> Even though block tree avoids disk seeks in certain cases when the
> term cannot exist on-disk, I think this change would further avoid
> disk seeks in additional cases because the min/max term has
> more/different information than the in-memory FST terms index.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Comment Edited] (LUCENE-5859) Remove Version.java completely

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

Uwe Schindler edited comment on LUCENE-5859 at 7/30/14 8:36 PM:

I think we should all calm down here. We are all strong personalities, so it is
always a bit hard if different opinions crush against each other. I had the
same problem today in LUCENE-5850, two different opinions. Yes, I am now
disappointed, because I spent hard work on the issue and instead of looking at
the key parts of the patch and the process of moving forward and improving the
stuff, only quibbling around stupid ALPHA/BETA versions was the response - just
disappointing. I don't think the other issue participant ever looked at the
patch, he just read what I wrote down as patch description and then did not
like it because of a small detail. I just stopped working on the issue and
maybe I will work on it tomorrow, maybe.

We should stop heavy committing here and all calm down!

bq. Veto must have technical justification. Good luck with the technical
justification of me not removing dead code.

There is indeed a technical justification: The Version parameter may be useless
now, but once we add new features to StandardAnalyzer, the Version parameter
gets useful again, so we need to re-add it - leading to the known backwards
problems. This again brings the problem that uses, who started at 5.0 will not
have a defined value for it in 5.1 and then we have problems. In my personal
opinion, every Analyzer must have the Version parameter mandatory.

On the other hand I know the problems with the mandatory parameter. I have seen
users tripping in the same trap like without the parameter: Once they upgrade
Lucene, they just search/replace every occurence of the old Version parameter,
just to get the "latest and best features" (documentation) and to remove
deprecations, because all previous versions are deprecated. But they don't
reindex - and boom they have the same problem like without the parameter. So it
had no good effect. Other projects like Elasticsearch don't care about the
version parameter. They have a global static constant in every release. Users
just upgrade - boom, same problem.

In my opinion, the documentation is much too general. We should only ever use
Version in the analyzers. Version should also be only part of the Analyzers
module, not Lucene core. In my opinion - and I agree with Robert - it is only
useful there! And in the analysis moudle it should be correctly documented, why
it is there and what it does. And why it is wrong to just use the latest and
best without reindexing.

was (Author: thetaphi):
I think we should all calm down here. We are all strong personalities, so it is
always a bit hard if different opinions crush against each other. I had the
same problem today in LUCENE-5850, two different opinions. Yes, I am now
disappointed, because I spent hard work on the issue and instead of looking at
the key parts of the patch and the process of moving forward and improving the
stuff, only quibbling around stupid ALPHA/BETA versions was the response - just
disappointing. I just stopped working on the issue and maybe I will work on it
tomorrow, just maybe.

We should stop heavy committing here and all calm down!

bq. Veto must have technical justification. Good luck with the technical
justification of me not removing dead code.

[jira] [Commented] (LUCENE-5859) Remove Version.java completely


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

Uwe Schindler commented on LUCENE-5859:
---

I think we should all calm down here. We are all strong personalities, so it is 
always a bit hard if different opinions crush against each other. I had the 
same problem today in LUCENE-5850, two different opinions. Yes, I am now 
disappointed, because I spent hard work on the issue and instead of looking at 
the key parts of the patch and the process of moving forward and improving the 
stuff, only quibbling around stupid ALPHA/BETA versions was the response - just 
disappointing. I just stopped working on the issue and maybe I will work on it 
tomorrow, just maybe.

We should stop heavy committing here and all calm down!

bq. Veto must have technical justification. Good luck with the technical 
justification of me not removing dead code.

There is indeed a technical justification: The Version parameter may be useless 
now, but once we add new features to StandardAnalyzer, the Version parameter 
gets useful again, so we need to re-add it - leading to the known backwards 
problems. This again brings the problem that uses, who started at 5.0 will not 
have a defined value for it in 5.1 and then we have problems. In my personal 
opinion, every Analyzer must have the Version parameter mandatory.

On the other hand I know the problems with the mandatory parameter. I have seen 
users tripping in the same trap like without the parameter: Once they upgrade 
Lucene, they just search/replace every occurence of the old Version parameter, 
just to get the "latest and best features" (documentation) and to remove 
deprecations, because all previous versions are deprecated. But they don't 
reindex - and boom they have the same problem like without the parameter. So it 
had no good effect. Other projects like Elasticsearch don't care about the 
version parameter. They have a global static constant in every release. Users 
just upgrade - boom, same problem.

In my opinion, the documentation is much too general. We should only ever use 
Version in the analyzers. Version should also be only part of the Analyzers 
module, not Lucene core. In my opinion - and I agree with Robert - it is only 
useful there! And in the analysis moudle it should be correctly documented, why 
it is there and what it does. And why it is wrong to just use the latest and 
best without reindexing.

> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[JENKINS] Lucene-Solr-Tests-4.x-Java7 - Build # 2042 - Still Failing

Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-Java7/2042/

1 tests failed.
FAILED:  org.apache.solr.cloud.MultiThreadedOCPTest.testDistribSearch

Error Message:
We have a failed SPLITSHARD task

Stack Trace:
java.lang.AssertionError: We have a failed SPLITSHARD task
at 
__randomizedtesting.SeedInfo.seed([321C63B44F6D6ADC:B3FAEDAC38320AE0]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.MultiThreadedOCPTest.testTaskExclusivity(MultiThreadedOCPTest.java:125)
at 
org.apache.solr.cloud.MultiThreadedOCPTest.doTest(MultiThreadedOCPTest.java:71)
at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:867)
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 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomize

[jira] [Commented] (LUCENE-5849) Scary "read past EOF" in RAMDir

2014-07-30 Thread Jack Krupansky (JIRA)


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

Jack Krupansky commented on LUCENE-5849:


Any sense of whether this is JVM-dependent? Or whether it is an issue for the 
JVM itself?

> Scary "read past EOF" in RAMDir
> ---
>
> Key: LUCENE-5849
> URL: https://issues.apache.org/jira/browse/LUCENE-5849
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
> Attachments: TestBinaryDocIndex.java
>
>
> Nightly build hit this: 
> http://builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/91095
> And I'm able to repro at least once after beasting w/ the right JVM 
> (1.7.0_55) and G1GC.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-4351) JSON QParser integration

2014-07-30 Thread John Lianoglou (JIRA)


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

John Lianoglou commented on SOLR-4351:
--

Shame it's sat around for over a year without any indication of response from 
any project members.

> JSON QParser integration
> 
>
> Key: SOLR-4351
> URL: https://issues.apache.org/jira/browse/SOLR-4351
> Project: Solr
>  Issue Type: New Feature
>Reporter: Yonik Seeley
> Attachments: SOLR-4351.patch
>
>
> Our QParser framework currently gets parameters from localParams.  JSON 
> integration would allow specifying parameters to the parsers in JSON.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5859) Remove Version.java completely


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

Robert Muir commented on LUCENE-5859:
-

{quote}
It seems like we basically have consensus on that issue already, but the answer 
is, because this is a community project. That's why there is veto power, that's 
just how things work if you want to make progress 
{quote}

Veto must have technical justification. Good luck with the technical 
justification of me not removing dead code.

> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5859) Remove Version.java completely


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

Mark Miller commented on LUCENE-5859:
-

bq. Why should I waste my time trying to convince anybody to remove a parameter 
that does absolutely nothing today?

It seems like we basically have consensus on that issue already, but the answer 
is, because this is a community project. That's why there is veto power, that's 
just how things work if you want to make progress :)

bq.  Don't worry, I won't remove any Version logic that is actually doing 
something.

That's the broader issue that you seem to be after and the one that you 
probably would need to convince people of. You are generally not bad at it, so 
it seems silly to avoid it when a contentious issue comes up. This issue was 
filed this morning. You threw up your hands on it hours later. A little intense 
man :)


> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5859) Remove Version.java completely


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

Robert Muir commented on LUCENE-5859:
-

Why should I waste my time trying to convince anybody to remove a parameter 
that does absolutely nothing today?

This is called "dead code". I will make a commit shortly to trunk to remove 
such dead code. Don't worry, I won't remove any Version logic that is *actually 
doing something*.


> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5859) Remove Version.java completely


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

Mark Miller commented on LUCENE-5859:
-

bq. and yet there are -1's to clean this stuff up :) 

Let's not over-blow a -1. It has gotten so conflated with a veto these days. By 
my reading, it means, "I don't currently agree with this".

We can't skip the step of trying to convince people of an argument and just go 
to throwing up our hands and saying "there is no convincing anybody". I think 
people want to be on board with a lot of these ideas, but you are making it 
harder than it needs to be.

I'm easily sold on the better constructers. I'm willing to be convinced on the 
broader version thing in general. 

bq.  So I suppose you are volunteering to fix StandardAnalyzer on trunk to be 
backwards compatible with 4.0-4.6?

I'm pretty open to the idea that everything can break over major versions...


> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6294) The JsonLoader should accept a single doc without wrapping in an array

2014-07-30 Thread Grant Ingersoll (JIRA)


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

Grant Ingersoll commented on SOLR-6294:
---

I really don't like having separate APIs for one doc vs. multiple docs.  How 
about deprecating the existing approach in favor a new one that properly 
captures commands, single docs, and multiple docs and is clean for users?  

The whole point of stuff like this is to make it easier for people first coming 
to Solr to not have to think about all the gotchas and just get their data in.  
Ease of use has to be all about the user's data and their questions for it, not 
about idiosyncrasies in API design to workaround previous approaches.

> The JsonLoader should accept a single doc without wrapping in an array
> --
>
> Key: SOLR-6294
> URL: https://issues.apache.org/jira/browse/SOLR-6294
> Project: Solr
>  Issue Type: Bug
>  Components: update
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
>
> This is the multi document input command
> {noformat}
> curl http://localhost:8983/solr/update/json -H 
> 'Content-type:application/json' -d '
> [
>  {"id" : "TestDoc1", "title" : "test1"},
> ]'
> {noformat}
> The following also should be a valid update command for a single doc
> {noformat}
> curl http://localhost:8983/solr/update/json -H 
> 'Content-type:application/json' -d '
>  {"id" : "TestDoc1", "title" : "test1"},
> '
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5859) Remove Version.java completely


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

Robert Muir commented on LUCENE-5859:
-

{quote}
...I am -1 on this newer proposal...

... I'm now going down the path of removing Version completely. ...

...since it would effectively eliminate the ability for anyone to confidently 
upgrade Lucene minor versions, w/o re-indexing all data.
{quote}

This is already the case though. So I suppose you are volunteering to fix 
StandardAnalyzer on trunk to be backwards compatible with 4.0-4.6? 

We should at least be consistent. Its hilarious it has the Version parameter 
right now, doing nothing, providing no back compat, and yet there are -1's to 
clean this stuff up :)

The back compat here is clearly too complex.

> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Updated] (LUCENE-5860) Use Terms.getMin/Max to speed up range queries/filters

2014-07-30 Thread Michael McCandless (JIRA)


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

Michael McCandless updated LUCENE-5860:
---

Attachment: LUCENE-5860.patch

Patch.

I also hit and fixed a bug in MemoryIndex's TermsEnum seek-by-ord ...

> Use Terms.getMin/Max to speed up range queries/filters
> --
>
> Key: LUCENE-5860
> URL: https://issues.apache.org/jira/browse/LUCENE-5860
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, 4.10
>
> Attachments: LUCENE-5860.patch
>
>
> As of LUCENE-5610, Lucene's Terms API now exposes min and max terms in
> each field.  I think we can use this in our term/numeric range
> query/filters to avoid visiting a given segment by detecting up front
> that the terms in the segment don't overlap with the query's range.
> Even though block tree avoids disk seeks in certain cases when the
> term cannot exist on-disk, I think this change would further avoid
> disk seeks in additional cases because the min/max term has
> more/different information than the in-memory FST terms index.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5859) Remove Version.java completely


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

Robert Muir commented on LUCENE-5859:
-

I havent pulled out the grenade. The grenade is when i get so frustrated with 
this crap that i do the following:

{{svn copy https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x 
https://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x}}

Call a vote for 5.0 (and get 2 other people to agree with me), and then make 
trunk 6.0 and remove all the back compat mess.

> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5858) Move back compat codecs out of core/ into codecs/ jar


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

Robert Muir commented on LUCENE-5858:
-

If people really want a separate jar, then fine.

BUT

we remove them from the normal "rotation" so core testing has a clean classpath 
and we can remove even more cruft (like packed ints). These days, we have 
dedicated TestXXXFormat for every codec, so this is not really needed anymore, 
instead just an annoyance: wasted time debugging test failures that are just 
quirks in old behavior of ancient codecs (e.g. not supporting missing values), 
and false jenkins failures because newer features arent supported (causing tons 
of SuppressCodecs everywhere). I think it made sense for the initial 3.x->4.x 
cutover, we didn't have such a mechanism for testing at that point, nor did we 
have really so many new index features that various search functionality was 
trying to use: blasting them thru all the tests was our only choice. But I 
think these days it does more harm than good. Most of the old formats we are 
still testing (like 3.0) are years and years old and just don't support the 
modern features. We should be looking forwards instead of backwards.

My motivation here is to make backwards compatibility simpler and less of a 
hassle for us as a project, not more difficult and more complex.

> Move back compat codecs out of core/ into codecs/ jar
> -
>
> Key: LUCENE-5858
> URL: https://issues.apache.org/jira/browse/LUCENE-5858
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>
> These take significant space and bloat core lucene. Not everyone needs the 
> ability to read ancient indexes (especially building a new app). 
> We should move this cruft out of the core/ jar. codecs/ is the obvious place, 
> its already setup in the build system for tests and everything else.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5858) Move back compat codecs out of core/ into codecs/ jar


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

Uwe Schindler commented on LUCENE-5858:
---

I would also suggest to move the backwards codecs into a separate JAR, not the 
experimental codecs module! We should also maybe add some useful text to the 
Codec.forName() and PostingsFormat.forName() APIs, so it tells the user that he 
might need to add lucene-backwards-codecs.jar into classpath.

> Move back compat codecs out of core/ into codecs/ jar
> -
>
> Key: LUCENE-5858
> URL: https://issues.apache.org/jira/browse/LUCENE-5858
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>
> These take significant space and bloat core lucene. Not everyone needs the 
> ability to read ancient indexes (especially building a new app). 
> We should move this cruft out of the core/ jar. codecs/ is the obvious place, 
> its already setup in the build system for tests and everything else.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[JENKINS] Lucene-Solr-NightlyTests-4.x - Build # 587 - Failure

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-4.x/587/

1 tests failed.
REGRESSION:  org.apache.solr.cloud.MultiThreadedOCPTest.testDistribSearch

Error Message:
Captured an uncaught exception in thread: Thread[id=19795, 
name=qtp1220221503-19795, state=RUNNABLE, group=TGRP-MultiThreadedOCPTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=19795, name=qtp1220221503-19795, state=RUNNABLE, 
group=TGRP-MultiThreadedOCPTest]
Caused by: java.lang.OutOfMemoryError: unable to create new native thread
at __randomizedtesting.SeedInfo.seed([A5CEC7F740A5F943]:0)
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:714)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1047)
at 
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323)
at 
org.eclipse.jetty.server.ssl.SslSocketConnector$SslConnectorEndPoint.run(SslSocketConnector.java:665)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 12962 lines...]
   [junit4] Suite: org.apache.solr.cloud.MultiThreadedOCPTest
   [junit4]   2> Creating dataDir: 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/solr/build/solr-core/test/J0/./solr.cloud.MultiThreadedOCPTest-A5CEC7F740A5F943-001/init-core-data-001
   [junit4]   2> 4532911 T18117 oas.SolrTestCaseJ4.buildSSLConfig Randomized 
ssl (true) and clientAuth (true)
   [junit4]   2> 4532911 T18117 
oas.BaseDistributedSearchTestCase.initHostContext Setting hostContext system 
property: /x_u/c
   [junit4]   2> 4532915 T18117 oas.SolrTestCaseJ4.setUp ###Starting 
testDistribSearch
   [junit4]   2> 4532916 T18117 oasc.ZkTestServer.run STARTING ZK TEST SERVER
   [junit4]   1> client port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 4532917 T18118 oasc.ZkTestServer$ZKServerMain.runFromConfig 
Starting server
   [junit4]   2> 4533017 T18117 oasc.ZkTestServer.run start zk server on 
port:50300
   [junit4]   2> 4533018 T18117 oascc.ConnectionManager.waitForConnected 
Waiting for client to connect to ZooKeeper
   [junit4]   2> 4533021 T18124 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@6513411d 
name:ZooKeeperConnection Watcher:127.0.0.1:50300 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 4533021 T18117 oascc.ConnectionManager.waitForConnected Client 
is connected to ZooKeeper
   [junit4]   2> 4533021 T18117 oascc.SolrZkClient.makePath makePath: /solr
   [junit4]   2> 4533024 T18117 oascc.ConnectionManager.waitForConnected 
Waiting for client to connect to ZooKeeper
   [junit4]   2> 4533025 T18126 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@4b33727f 
name:ZooKeeperConnection Watcher:127.0.0.1:50300/solr got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 4533025 T18117 oascc.ConnectionManager.waitForConnected Client 
is connected to ZooKeeper
   [junit4]   2> 4533025 T18117 oascc.SolrZkClient.makePath makePath: 
/collections/collection1
   [junit4]   2> 4533027 T18117 oascc.SolrZkClient.makePath makePath: 
/collections/collection1/shards
   [junit4]   2> 4533028 T18117 oascc.SolrZkClient.makePath makePath: 
/collections/control_collection
   [junit4]   2> 4533030 T18117 oascc.SolrZkClient.makePath makePath: 
/collections/control_collection/shards
   [junit4]   2> 4533031 T18117 oasc.AbstractZkTestCase.putConfig put 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 4533032 T18117 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/solrconfig.xml
   [junit4]   2> 4533034 T18117 oasc.AbstractZkTestCase.putConfig put 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/solr/core/src/test-files/solr/collection1/conf/schema.xml
 to /configs/conf1/schema.xml
   [junit4]   2> 4533034 T18117 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/schema.xml
   [junit4]   2> 4533136 T18117 oasc.AbstractZkTestCase.putConfig put 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/solr/core/src/test-files/solr/collection1/conf/solrconfig.snippet.randomindexconfig.xml
 to /configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 4533137 T18117 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 4533139 T18117 oasc.AbstractZkTestCase.

[jira] [Commented] (LUCENE-5858) Move back compat codecs out of core/ into codecs/ jar


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

Hoss Man commented on LUCENE-5858:
--

bq. Its not mandatory today. Its only mandatory for tests, which is the 
advantage, there is no risk to the build system moving stuff there. It removes 
it from the core jar and makes it optional, whereas today its mandatory.

I guess i'm misunderstanding something about your initial suggestion.  (There 
are also a lot of instances of "It" in that paragraph that that are confusing 
me about which "it" you are refering to at any given time ... sometimes it 
seems like "it" is the codecs module, other times i think "it" refers to the 
backcompat codecs?

Here's the point i was trying to make...

Today: a simple-app.jar that wants extremely basic search functionality, can 
depend exclusively on lucene-core.jar and build an index and search that index. 
 If that simple-app.jar built an index with lucene-core-4.5.jar and then later 
upgraded to use lucene-core-4.9.jar, then simple-app.jar would continue to work 
just fine

If i understand your idea correctly: then starting in 4.10 the back compat 
codecs would now live in lucene-codecs.jar.  So simple-app.jar would need to 
include both lucene-core-4.10.jar and lucene-codecs-4.10.jar in it's classpath 
if it wanted to keep reading those older 4.5-4.9 indexes.  There might however 
be some trivial-app.jar that doesn't care about index backcompat at all, and it 
only needs to load lucene-core-4.10.jar

Am i correct so far?

The concern i have is that when it comes to upgrading, the "simple-app.jar" 
scenerio seems more common to me then the "trivial-app.jar" situation, and for 
the simple-app.jar situation, moving the backcompat codecs into 
lucene-codecs.jar doesn't actually do anything to reduce the "bloat" of classes 
in the lucene jars it includes -- it makes the bloat worse -- because now in 
addition to the core classes, and the backcompat codecs, simple-app.jar also 
has to include all of the "optional" codecs (like simpletext) that already 
exist in the lucene-codecs.jar.

The bloat of unnecessary classes has been reduced for trivial-app.jar, but is 
that really the situation we should be optimizing for?

The key question i'm raising is:

Does it really make sense to _increase_ the size of jars needed for apps that 
want to read old indexes, in order to _decrease_ the size of the jars needed 
for (in my opinion) "toy" apps that don't care about index compatibility?
 
Moving the backcompat codecs into their own jar seems like a great idea -- i'm 
just not sure if any "real" lucene users benefit from moving them into the 
_existing_ codecs jar.



> Move back compat codecs out of core/ into codecs/ jar
> -
>
> Key: LUCENE-5858
> URL: https://issues.apache.org/jira/browse/LUCENE-5858
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>
> These take significant space and bloat core lucene. Not everyone needs the 
> ability to read ancient indexes (especially building a new app). 
> We should move this cruft out of the core/ jar. codecs/ is the obvious place, 
> its already setup in the build system for tests and everything else.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5859) Remove Version.java completely


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

Mark Miller commented on LUCENE-5859:
-

bq. but we can at least make no-arg ctors forwarding to VERSION_CURRENT 

+1

bq. I'm not against the proposal here, just raising some concerns that I have. 
bq. I tried to be reasonable here and open an issue with a compromise. Its 
clear this is a mistake. 
bq. but you also seem to have gotten very antagonistic and unreasonable 

+1. Less coffee Rob :)

Doesn't seem like much is in your way yet, keep the pin in the grenade for 
later.

Let's start with some sane constructors before we nuke the whole system. I half 
way know the versioning system, and every time I've tried to toss together some 
quick Lucene code it has really annoyed me to deal with this. Good doc issue 
IMO.


> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6295) AssertionError in ToChildBlockJoinScorer.advance

2014-07-30 Thread Mikhail Khludnev (JIRA)


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

Mikhail Khludnev commented on SOLR-6295:


damn! I've thought all of these was covered during LUCENE-5375 

> AssertionError in ToChildBlockJoinScorer.advance
> 
>
> Key: SOLR-6295
> URL: https://issues.apache.org/jira/browse/SOLR-6295
> Project: Solr
>  Issue Type: Bug
>Reporter: Shalin Shekhar Mangar
> Attachments: SOLR-6295.patch, block-join.log
>
>
> This happened in Solr land in the 
> SolrExampleStreamingTest.testChildDoctransformer
> https://builds.apache.org/job/Lucene-Solr-Maven-4.x/665/
> {code}
> 327371 T810 oejs.ServletHandler.doHandle WARN Error for 
> /solr/collection1/select java.lang.AssertionError
>   at 
> org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:286)
>   at 
> org.apache.lucene.search.FilteredQuery$LeapFrogScorer.advanceToNextCommonDoc(FilteredQuery.java:274)
>   at 
> org.apache.lucene.search.FilteredQuery$LeapFrogScorer.nextDoc(FilteredQuery.java:286)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:192)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
>   at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:297)
>   at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:209)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1619)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1433)
>   at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:514)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocList(SolrIndexSearcher.java:1268)
>   at 
> org.apache.solr.response.transform.ChildDocTransformer.transform(ChildDocTransformerFactory.java:144)
>   at 
> org.apache.solr.response.TextResponseWriter.writeDocuments(TextResponseWriter.java:252)
>   at 
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:170)
>   at org.apache.solr.response.XMLWriter.writeResponse(XMLWriter.java:112)
>   at 
> org.apache.solr.response.XMLResponseWriter.write(XMLResponseWriter.java:40)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.writeResponse(SolrDispatchFilter.java:765)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:426)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5859) Remove Version.java completely


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

Hoss Man commented on LUCENE-5859:
--

bq. I happen to prefer your proposal to the one Shai made, but you are not 
coming across, to me, as being very reasonable in your response.

I realize now that my entire comment, in total, may have been miscounstrued.

Just to be clear: this is the proposal i agree with...

bq. ...we can at least make no-arg ctors forwarding to VERSION_CURRENT so that 
people who don't care about back compat ...

...I am -1 on this newer proposal...

bq. ... I'm now going down the path of removing Version completely. ...

...since it would effectively eliminate the ability for anyone to confidently 
upgrade Lucene minor versions, w/o re-indexing all data.



> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5858) Move back compat codecs out of core/ into codecs/ jar


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

Robert Muir commented on LUCENE-5858:
-

What is the problem with codecs/ ?

Its not mandatory today. Its only mandatory for tests, which is the advantage, 
there is no risk to the build system moving stuff there. It removes it from the 
core jar and makes it optional, whereas today its mandatory.

This is the conservative route: trying to add a new jar is more complex... I'm 
not against it, I just want to make an improvement step for 5.0. If someone 
else wants to do the build system work for some backcompat module, thats great, 
but it shouldnt be a requirement for getting this crap out of core.

Especially since its trunk, core/ shouldn't be cluttered with all this cruft.

> Move back compat codecs out of core/ into codecs/ jar
> -
>
> Key: LUCENE-5858
> URL: https://issues.apache.org/jira/browse/LUCENE-5858
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>
> These take significant space and bloat core lucene. Not everyone needs the 
> ability to read ancient indexes (especially building a new app). 
> We should move this cruft out of the core/ jar. codecs/ is the obvious place, 
> its already setup in the build system for tests and everything else.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5850) Constants#LUCENE_MAIN_VERSION can have broken values


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

Robert Muir commented on LUCENE-5850:
-

I am happy also if Version is the "one thing" with the comparator and used for 
the index... (with all constants for all releases).

And not mandatory for analyzers.

> Constants#LUCENE_MAIN_VERSION can have broken values 
> -
>
> Key: LUCENE-5850
> URL: https://issues.apache.org/jira/browse/LUCENE-5850
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Affects Versions: 4.3.1, 4.5.1
>Reporter: Simon Willnauer
> Fix For: 5.0, 4.10
>
> Attachments: LUCENE-5850.patch, LUCENE-5850.patch, 
> LUCENE-5850_bomb.patch, LUCENE-5850_smoketester.patch
>
>
> Constants#LUCENE_MAIN_VERSION is set to the Lucene Main version and should 
> not contain minor versions. Well this is at least what I thought and to my 
> knowledge what the comments say too. Yet in for instance 4.3.1 and 4.5.1 we 
> broke this such that the version from SegmentsInfo can not be parsed with 
> Version#parseLeniently. IMO we should really add an assertion that this 
> constant doesn't throw an error and / or make the smoketester catch this. to 
> me this is actually a index BWC break. Note that 4.8.1 doesn't have this 
> problem...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5858) Move back compat codecs out of core/ into codecs/ jar


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

Hoss Man commented on LUCENE-5858:
--

IIUC: This means that, moving forward, users who want to upgrade, and have 
indexes built with older versions of Lucene, will need to include the 
codecs.jar as well as the core.jar in their applications as well ... correct?

Since a big part of the reason the codecs modules already exists was so apps 
that didn't want/need those optional codecs wouldn't have to load them, would 
it make more sense to create a new backcompat-codecs module/jar instead of 
lumping them all in codecs.jar?

> Move back compat codecs out of core/ into codecs/ jar
> -
>
> Key: LUCENE-5858
> URL: https://issues.apache.org/jira/browse/LUCENE-5858
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>
> These take significant space and bloat core lucene. Not everyone needs the 
> ability to read ancient indexes (especially building a new app). 
> We should move this cruft out of the core/ jar. codecs/ is the obvious place, 
> its already setup in the build system for tests and everything else.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory


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

Mark Miller commented on SOLR-3619:
---

bq. On the other hand, this will create some headaches back-porting from trunk 
to 4x

Yeah, that was most of the pain I was referring to with "My feeling is, as 
painful as it might be in some cases".



> Rename 'example' dir to 'server' and pull examples into an 'examples' 
> directory
> ---
>
> Key: SOLR-3619
> URL: https://issues.apache.org/jira/browse/SOLR-3619
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Timothy Potter
> Fix For: 4.9, 5.0
>
> Attachments: SOLR-3619.patch, SOLR-3619.patch, server-name-layout.png
>
>




--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory


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

Mark Miller commented on SOLR-3619:
---

Because of upgrade difficulties and the degree of changes for a point release, 
I would guess 4x would get a lot of pushback. I wouldn't really be against it 
myself.

On the other hand, I don't think 5x is that far out in the scheme of things.

> Rename 'example' dir to 'server' and pull examples into an 'examples' 
> directory
> ---
>
> Key: SOLR-3619
> URL: https://issues.apache.org/jira/browse/SOLR-3619
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Timothy Potter
> Fix For: 4.9, 5.0
>
> Attachments: SOLR-3619.patch, SOLR-3619.patch, server-name-layout.png
>
>




--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5850) Constants#LUCENE_MAIN_VERSION can have broken values


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

Uwe Schindler commented on LUCENE-5850:
---

I have seen, you are going to remove Version.java completely in LUCENE-5859, so 
I will not touch Version in this issue.

I will rewrite the patch, to clean up common-build.xml and use the full bugfix 
version when writing index files.

> Constants#LUCENE_MAIN_VERSION can have broken values 
> -
>
> Key: LUCENE-5850
> URL: https://issues.apache.org/jira/browse/LUCENE-5850
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Affects Versions: 4.3.1, 4.5.1
>Reporter: Simon Willnauer
> Fix For: 5.0, 4.10
>
> Attachments: LUCENE-5850.patch, LUCENE-5850.patch, 
> LUCENE-5850_bomb.patch, LUCENE-5850_smoketester.patch
>
>
> Constants#LUCENE_MAIN_VERSION is set to the Lucene Main version and should 
> not contain minor versions. Well this is at least what I thought and to my 
> knowledge what the comments say too. Yet in for instance 4.3.1 and 4.5.1 we 
> broke this such that the version from SegmentsInfo can not be parsed with 
> Version#parseLeniently. IMO we should really add an assertion that this 
> constant doesn't throw an error and / or make the smoketester catch this. to 
> me this is actually a index BWC break. Note that 4.8.1 doesn't have this 
> problem...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Resolved] (SOLR-6281) PostingsSolrHighlighter should be more configurable

2014-07-30 Thread David Smiley (JIRA)


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

David Smiley resolved SOLR-6281.


Resolution: Fixed

> PostingsSolrHighlighter should be more configurable
> ---
>
> Key: SOLR-6281
> URL: https://issues.apache.org/jira/browse/SOLR-6281
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 5.0, 4.10
>
> Attachments: SOLR-6281_PostingsSolrHighlighter_more_configurable.patch
>
>
> The DefaultSolrHighlighter (works on non-FVH and FVH modes) and 
> PostingsSolrHighlighter are quite different, although they do share some 
> highlighting parameters where it's directly applicable.  DSH has its 
> fragListBuilder, fragmentsBuilder, boundaryScanner, configurable by letting 
> you defined your own class in solrconfig.xml.  PSH does not; it uses the 
> Lucene default implementations of DefaultPassageFormatter, PassageScorer, and 
> Java BreakIterator, though it configures each of them based on options. I 
> have a case where I need to provide a custom PassageFormatter, for example.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

Re: How to edit the Solr ref guide

2014-07-30 Thread Chris Hostetter


: OK thanks. I subscribed with the user 'shaie' (name: Shai Erera).

I've added your edit permissions.

: I will fix trivial typos and wording stuff directly there, and if there's a
: bigger change I'll open JIRA issues.

For edits to existing pages, feel free to make them directly.  If you're 
talking about wanting to create big hunks of new content, but not being 
sure where to put them -- we actaully have a staging area for stuff like 
that...

https://cwiki.apache.org/confluence/display/solr/Internal+-+Trunk+Changes+to+Document

As evident by the name & intro on the page it was created as a place to 
document stuff on trunk so it would be ready to go when 5.0 comes out.

but you can also use it to stage changes (already formated in the wiki 
editor) that should go in a 4.x release of the ref guide, but you aren't 
sure where exactly it makes the most sense yet.



-Hoss
http://www.lucidworks.com/

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

[jira] [Commented] (LUCENE-5859) Remove Version.java completely

2014-07-30 Thread ASF subversion and git services (JIRA)


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

Robert Muir commented on LUCENE-5859:
-

I don't think there is a general understanding of how bad the bugs are i fixed 
in LUCENE-5850, probably because of how confusing the versioning is.

If we had issued a broken release with these, people would be freaking out and 
acting unreasonable. I'm just fixing it before it happens. Perpetuating the 
current brokenness even more into the APIs is the wrong direction.

> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6295) AssertionError in ToChildBlockJoinScorer.advance

2014-07-30 Thread Varun Thacker (JIRA)


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

Varun Thacker commented on SOLR-6295:
-

bq. We do the same in L1315 currently.

I meant Line 1315 in SolrExampleTests. Sorry for being vague. 



> AssertionError in ToChildBlockJoinScorer.advance
> 
>
> Key: SOLR-6295
> URL: https://issues.apache.org/jira/browse/SOLR-6295
> Project: Solr
>  Issue Type: Bug
>Reporter: Shalin Shekhar Mangar
> Attachments: SOLR-6295.patch, block-join.log
>
>
> This happened in Solr land in the 
> SolrExampleStreamingTest.testChildDoctransformer
> https://builds.apache.org/job/Lucene-Solr-Maven-4.x/665/
> {code}
> 327371 T810 oejs.ServletHandler.doHandle WARN Error for 
> /solr/collection1/select java.lang.AssertionError
>   at 
> org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:286)
>   at 
> org.apache.lucene.search.FilteredQuery$LeapFrogScorer.advanceToNextCommonDoc(FilteredQuery.java:274)
>   at 
> org.apache.lucene.search.FilteredQuery$LeapFrogScorer.nextDoc(FilteredQuery.java:286)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:192)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
>   at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:297)
>   at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:209)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1619)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1433)
>   at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:514)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocList(SolrIndexSearcher.java:1268)
>   at 
> org.apache.solr.response.transform.ChildDocTransformer.transform(ChildDocTransformerFactory.java:144)
>   at 
> org.apache.solr.response.TextResponseWriter.writeDocuments(TextResponseWriter.java:252)
>   at 
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:170)
>   at org.apache.solr.response.XMLWriter.writeResponse(XMLWriter.java:112)
>   at 
> org.apache.solr.response.XMLResponseWriter.write(XMLResponseWriter.java:40)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.writeResponse(SolrDispatchFilter.java:765)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:426)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6295) AssertionError in ToChildBlockJoinScorer.advance

2014-07-30 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar commented on SOLR-6295:
-

Thanks Varun. In this case, why is such a query even accepted by Solr? Most 
people don't have assertions enabled and they'd never get this error.

> AssertionError in ToChildBlockJoinScorer.advance
> 
>
> Key: SOLR-6295
> URL: https://issues.apache.org/jira/browse/SOLR-6295
> Project: Solr
>  Issue Type: Bug
>Reporter: Shalin Shekhar Mangar
> Attachments: SOLR-6295.patch, block-join.log
>
>
> This happened in Solr land in the 
> SolrExampleStreamingTest.testChildDoctransformer
> https://builds.apache.org/job/Lucene-Solr-Maven-4.x/665/
> {code}
> 327371 T810 oejs.ServletHandler.doHandle WARN Error for 
> /solr/collection1/select java.lang.AssertionError
>   at 
> org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:286)
>   at 
> org.apache.lucene.search.FilteredQuery$LeapFrogScorer.advanceToNextCommonDoc(FilteredQuery.java:274)
>   at 
> org.apache.lucene.search.FilteredQuery$LeapFrogScorer.nextDoc(FilteredQuery.java:286)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:192)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
>   at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:297)
>   at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:209)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1619)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1433)
>   at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:514)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocList(SolrIndexSearcher.java:1268)
>   at 
> org.apache.solr.response.transform.ChildDocTransformer.transform(ChildDocTransformerFactory.java:144)
>   at 
> org.apache.solr.response.TextResponseWriter.writeDocuments(TextResponseWriter.java:252)
>   at 
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:170)
>   at org.apache.solr.response.XMLWriter.writeResponse(XMLWriter.java:112)
>   at 
> org.apache.solr.response.XMLResponseWriter.write(XMLResponseWriter.java:40)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.writeResponse(SolrDispatchFilter.java:765)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:426)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Created] (SOLR-6303) JDBC drivers not being released causing permgen memory leak

2014-07-30 Thread Robin Grindrod (JIRA)

Robin Grindrod created SOLR-6303:


 Summary: JDBC drivers not being released causing permgen memory 
leak 
 Key: SOLR-6303
 URL: https://issues.apache.org/jira/browse/SOLR-6303
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.9
 Environment: Debian 7
OpenJDK Runtime Environment (IcedTea 2.5.1) (7u65-2.5.1-2~deb7u1)
Apache Tomcat 7.0.28
Solr 4.9.0
Reporter: Robin Grindrod


I have an issue where after reloading Solr a few times Tomcat runs out of 
permgen space. After a little bit of investigation it seems that if I reload 
Solr without running the DataImportHandler and then perform garbage collection 
the amount of used permgen memory seems to return to roughly where it was 
before. However, if I run the DataImportHandler and then reload, the amount of 
memory will not return to where it was before. If this is repeated a few times 
it will eventually cause Tomcat to hang and throw a 
"java.lang.OutOfMemoryError: PermGen space" error.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5859) Remove Version.java completely


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

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

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

LUCENE-5859: remove Version param from LuceneTestCase.newIndexWriterConfig, the 
grand sum of 2 tests making use of it can use the 3-arg version and reduce the 
noise everywhere else

> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5859) Remove Version.java completely

2014-07-30 Thread ASF subversion and git services (JIRA)


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

Hoss Man commented on LUCENE-5859:
--

bq. we can at least make no-arg ctors forwarding to VERSION_CURRENT so that 
people who don't care about back compat (e.g. just prototyping) don't have to 
deal with the horribly complex versioning system.

+1 .. As long as we have some boilerplate javadocs on all of these constructors 
("The runtime behavior of this class may change btween releases when using this 
constructor, please consider the 'Version' constructor to maximize 
compatibility between releases") this seems like a good idea.

bq. I tried to be reasonable here and open an issue with a compromise. Its 
clear this is a mistake. I'm now going down the path of removing Version 
completely.

Your proposal seems very reasonable -- but you also seem to have gotten very 
antagonistic and unreasonable when Shai suggested his own, reasonable, 
alternative proposal for discussion.

I happen to prefer your proposal to the one Shai made, but you are not coming 
across, to me, as being very reasonable in your response.

> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Created] (LUCENE-5861) CachingTokenFilter should use ArrayList not LinkedList

2014-07-30 Thread David Smiley (JIRA)

David Smiley created LUCENE-5861:


 Summary: CachingTokenFilter should use ArrayList not LinkedList
 Key: LUCENE-5861
 URL: https://issues.apache.org/jira/browse/LUCENE-5861
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/analysis
Reporter: David Smiley
Assignee: David Smiley
Priority: Minor


CachingTokenFilter, to my surprise, puts each new AttributeSource.State onto a 
LinkedList.  I think it should be an ArrayList.  On large fields that get 
analyzed, there can be a ton of State objects to cache.

I also observe that State is itself a linked list of other State objects.  
Perhaps we could take this one step further and do parallel arrays of 
AttributeImpl, thereby bypassing State.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

Re: Solr IndexConfig and mergeFactor

2014-07-30 Thread Chris Hostetter


: Even though the example solrconfig.xml documents what this parameter means
: for LogMP and TieredMP. I think if users want to meddle with merge
: settings, it is not uber-expert if we ask them to specify which MP they
: want to use, and then use that MP's specific parameters. To make it easier

Agreed -- the  tag exists because of backcompat -- we should 
absolutely move away from using it explicitly in sample configs and docs, 
and instead encourage people to declare a  and then use the 
appropriate settings nested inside it for the policy they pick ... 
users really should not be picking  in a vacume.

: on users, we can support a class="Tiered/LogMergePolicy" so users don't
: have to define the full class name (maybe we prefix that with
: "lucene.Tiered/LogMP"), but once it's defined, they need to use the right
: parameters for the chosen MP.

I don't like the road this idea is headed down ... this would basically 
introduce a *third* was to declare a mergePolicy, and introduce all the 
fun and exciting error checking / warning / logging involved in dealing 
with what happens if people mix and match bits and pieces of all three.  
My vote would be to go the other direction: fail hard in 5.0 if a 
 tag is found.

We have a robust system in place for allowing users to configure arbitrary 
mergePolicies -- we should use that system moving forward and improve the 
docs as needed if folks are concerned that making the jump from "simple 
sample configs w/o a merge policy configured" to "i want to adjust the 
merge settings, how do i do that" is currently too complicated.

: reference guide, but I think it's more important that we document the
: default MergePolicy and some important settings about it (e.g.
: maxMergedSegmentMB, maxMergeAtOnce and segmentsPerTier).

+1 



-Hoss
http://www.lucidworks.com/

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

[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory

2014-07-30 Thread Timothy Potter (JIRA)


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

Timothy Potter commented on SOLR-3619:
--

bq. because otherwise the "doing" goes to /dev/null 

No doubt! Your original patch on this was an immense amount of work sent into 
/dev/null :-( I'm happy to scale back some of these changes if it helps get it 
into 4x. What jumps out as being incompatible with 4x here? Heck, we can ship a 
script that creates symbolic links to do:

ln -s server/start.jar example/start.jar

etc

On the other hand, this will create some headaches back-porting from trunk to 
4x but for the most part, it shouldn't be too bad since there aren't any 
code-level changes.

Lastly, I definitely want to get the scripts in place for 4x as those don't 
introduce back compat issues and I'd like to see those get some use sooner than 
later.

> Rename 'example' dir to 'server' and pull examples into an 'examples' 
> directory
> ---
>
> Key: SOLR-3619
> URL: https://issues.apache.org/jira/browse/SOLR-3619
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Timothy Potter
> Fix For: 4.9, 5.0
>
> Attachments: SOLR-3619.patch, SOLR-3619.patch, server-name-layout.png
>
>




--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Created] (LUCENE-5860) Use Terms.getMin/Max to speed up range queries/filters

2014-07-30 Thread Michael McCandless (JIRA)

Michael McCandless created LUCENE-5860:
--

 Summary: Use Terms.getMin/Max to speed up range queries/filters
 Key: LUCENE-5860
 URL: https://issues.apache.org/jira/browse/LUCENE-5860
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
 Fix For: 5.0, 4.10


As of LUCENE-5610, Lucene's Terms API now exposes min and max terms in
each field.  I think we can use this in our term/numeric range
query/filters to avoid visiting a given segment by detecting up front
that the terms in the segment don't overlap with the query's range.

Even though block tree avoids disk seeks in certain cases when the
term cannot exist on-disk, I think this change would further avoid
disk seeks in additional cases because the min/max term has
more/different information than the in-memory FST terms index.




--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6281) PostingsSolrHighlighter should be more configurable


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

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

Commit 1614704 from [~dsmiley] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1614704 ]

SOLR-6281: Made PostingsSolrHighlighter more configurable

> PostingsSolrHighlighter should be more configurable
> ---
>
> Key: SOLR-6281
> URL: https://issues.apache.org/jira/browse/SOLR-6281
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 5.0, 4.10
>
> Attachments: SOLR-6281_PostingsSolrHighlighter_more_configurable.patch
>
>
> The DefaultSolrHighlighter (works on non-FVH and FVH modes) and 
> PostingsSolrHighlighter are quite different, although they do share some 
> highlighting parameters where it's directly applicable.  DSH has its 
> fragListBuilder, fragmentsBuilder, boundaryScanner, configurable by letting 
> you defined your own class in solrconfig.xml.  PSH does not; it uses the 
> Lucene default implementations of DefaultPassageFormatter, PassageScorer, and 
> Java BreakIterator, though it configures each of them based on options. I 
> have a case where I need to provide a custom PassageFormatter, for example.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6281) PostingsSolrHighlighter should be more configurable

2014-07-30 Thread ASF subversion and git services (JIRA)


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

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

Commit 1614702 from [~dsmiley] in branch 'dev/trunk'
[ https://svn.apache.org/r1614702 ]

SOLR-6281: Made PostingsSolrHighlighter more configurable

> PostingsSolrHighlighter should be more configurable
> ---
>
> Key: SOLR-6281
> URL: https://issues.apache.org/jira/browse/SOLR-6281
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 5.0, 4.10
>
> Attachments: SOLR-6281_PostingsSolrHighlighter_more_configurable.patch
>
>
> The DefaultSolrHighlighter (works on non-FVH and FVH modes) and 
> PostingsSolrHighlighter are quite different, although they do share some 
> highlighting parameters where it's directly applicable.  DSH has its 
> fragListBuilder, fragmentsBuilder, boundaryScanner, configurable by letting 
> you defined your own class in solrconfig.xml.  PSH does not; it uses the 
> Lucene default implementations of DefaultPassageFormatter, PassageScorer, and 
> Java BreakIterator, though it configures each of them based on options. I 
> have a case where I need to provide a custom PassageFormatter, for example.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5859) Remove Version.java completely

2014-07-30 Thread ASF subversion and git services (JIRA)


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

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

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

LUCENE-5859: remove Version param from LuceneTestCase.newIndexWriterConfig, the 
grand sum of 2 tests making use of it can use the 3-arg version and reduce the 
noise everywhere else

> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory


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

Mark Miller commented on SOLR-3619:
---

bq. See any issues with a few additional renames as part of this change?

I don't, but at this point, with these changes, this is all 5x I think. My 
feeling is, as painful as it might be in some cases, we need to make things as 
right as possible for 5x though. So in my opinion, everything is fair game to 
get things right, renames included. Depends on who chimes in when though.

I was thinking of a more limited server folder that would also work with 4x. 
But IMO, you have gone with what really needs to be done, which is along the 
lines of what I have pushed for for a long time, and that kind of effort and 
work needs to be absorbed when it shows up. Those that do decide, because 
otherwise the doing goes to /dev/null :) So I'm +1 on "let's make 5x like it 
should be".

bq. thinking it should have a better name. 

Yup.

> Rename 'example' dir to 'server' and pull examples into an 'examples' 
> directory
> ---
>
> Key: SOLR-3619
> URL: https://issues.apache.org/jira/browse/SOLR-3619
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Timothy Potter
> Fix For: 4.9, 5.0
>
> Attachments: SOLR-3619.patch, SOLR-3619.patch, server-name-layout.png
>
>




--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Comment Edited] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory


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

Mark Miller edited comment on SOLR-3619 at 7/30/14 4:21 PM:


bq. See any issues with a few additional renames as part of this change?

I don't, but at this point, with these changes, this is all 5x I think. My 
feeling is, as painful as it might be in some cases, we need to make things as 
right as possible for 5x though. So in my opinion, everything is fair game to 
get things right, renames included. Depends on who chimes in when though.

I was thinking of a more limited server folder that would also work with 4x. 
But IMO, you have gone with what really needs to be done, which is along the 
lines of what I have pushed for for a long time, and that kind of effort and 
work needs to be absorbed when it shows up. "Those that do, decide", because 
otherwise the "doing" goes to /dev/null :) So I'm +1 on "let's make 5x like it 
should be".

bq. thinking it should have a better name. 

Yup.


was (Author: markrmil...@gmail.com):
bq. See any issues with a few additional renames as part of this change?

I don't, but at this point, with these changes, this is all 5x I think. My 
feeling is, as painful as it might be in some cases, we need to make things as 
right as possible for 5x though. So in my opinion, everything is fair game to 
get things right, renames included. Depends on who chimes in when though.

I was thinking of a more limited server folder that would also work with 4x. 
But IMO, you have gone with what really needs to be done, which is along the 
lines of what I have pushed for for a long time, and that kind of effort and 
work needs to be absorbed when it shows up. Those that do decide, because 
otherwise the doing goes to /dev/null :) So I'm +1 on "let's make 5x like it 
should be".

bq. thinking it should have a better name. 

Yup.

> Rename 'example' dir to 'server' and pull examples into an 'examples' 
> directory
> ---
>
> Key: SOLR-3619
> URL: https://issues.apache.org/jira/browse/SOLR-3619
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Timothy Potter
> Fix For: 4.9, 5.0
>
> Attachments: SOLR-3619.patch, SOLR-3619.patch, server-name-layout.png
>
>




--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory

2014-07-30 Thread Timothy Potter (JIRA)


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

Timothy Potter commented on SOLR-3619:
--

Thanks for the feedback! I'm wondering if we should rename example -> examples 
as well? In addition, that solr directory under example (aka the kitchen sink 
example) sticks out to me like a sore thumb ... thinking it should have a 
better name. See any issues with a few additional renames as part of this 
change?

I'll provide the default_conf directory in this ticket and add an easy way to 
create a core (for standalone) or collection (for cloud) using the bin/solr 
script. We might need some UI changes to the Core Admin page to use this 
default_conf by default when creating a new core (I'll open a different ticket 
for that).



> Rename 'example' dir to 'server' and pull examples into an 'examples' 
> directory
> ---
>
> Key: SOLR-3619
> URL: https://issues.apache.org/jira/browse/SOLR-3619
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Timothy Potter
> Fix For: 4.9, 5.0
>
> Attachments: SOLR-3619.patch, SOLR-3619.patch, server-name-layout.png
>
>




--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5850) Constants#LUCENE_MAIN_VERSION can have broken values


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

Robert Muir commented on LUCENE-5850:
-

Right, to be clear, here we have calmed the symptoms (the back compat time-bomb 
bugs in SegmentReader and codec).
But to me this isn't enough, i am afraid of what would happen if we released 
such code in a bugfix release.
We need to cure the disease, and prevent such bugs from being easy to do.

Additionally we should probably change the release instructions to generate 
back compat index for *every release*  bugfix or not, index format change or 
not, and retroactively generate them for all 4.x releases. This would provide 
additional protection.

> Constants#LUCENE_MAIN_VERSION can have broken values 
> -
>
> Key: LUCENE-5850
> URL: https://issues.apache.org/jira/browse/LUCENE-5850
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Affects Versions: 4.3.1, 4.5.1
>Reporter: Simon Willnauer
> Fix For: 5.0, 4.10
>
> Attachments: LUCENE-5850.patch, LUCENE-5850.patch, 
> LUCENE-5850_bomb.patch, LUCENE-5850_smoketester.patch
>
>
> Constants#LUCENE_MAIN_VERSION is set to the Lucene Main version and should 
> not contain minor versions. Well this is at least what I thought and to my 
> knowledge what the comments say too. Yet in for instance 4.3.1 and 4.5.1 we 
> broke this such that the version from SegmentsInfo can not be parsed with 
> Version#parseLeniently. IMO we should really add an assertion that this 
> constant doesn't throw an error and / or make the smoketester catch this. to 
> me this is actually a index BWC break. Note that 4.8.1 doesn't have this 
> problem...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5847) Improved implementation of language models in lucene

2014-07-30 Thread Ryan Ernst (JIRA)


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

Ryan Ernst commented on LUCENE-5847:


Why can't the background score be implemented in the specific scorers for 
Dirichlet or JM? I don't think the Scorer interface should be cluttered with 
something specific to one implementation.

> Improved implementation of language models in lucene 
> -
>
> Key: LUCENE-5847
> URL: https://issues.apache.org/jira/browse/LUCENE-5847
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Hadas Raviv
>Priority: Minor
> Fix For: 5.0
>
> Attachments: LUCENE-2507.patch
>
>
> The current implementation of language models in lucene is based on the paper 
> "A Study of Smoothing Methods for Language Models Applied to Ad Hoc 
> Information Retrieval" by Zhai and Lafferty ('01). Specifically, 
> LMDiricheltSimilarity and LMJelinikMercerSimilarity use a normalized smoothed 
> score for a matching term in a document, as suggested in the above mentioned 
> paper.
> However, lucene doesn't assign a score to query terms that do not appear in a 
> matched document. According to the "pure" LM approach, these terms should be 
> assigned with a collection probability "background score". If one uses the 
> Jelinik Mercer smoothing method, the final result list produced by lucene is 
> rank equivalent to the one that would have been created by a full LM 
> implementation. However, this is not the case for Dirichlet smoothing method, 
> because the background score is document dependent. Documents in which not 
> all query terms appear, are missing the document-dependant background score 
> for the missing terms. This component affects the final ranking of documents 
> in the list.
> Since LM is a baseline method in many works in the IR research field, I 
> attach a patch that implements a full LM in lucene. The basic issue that 
> should be addressed here is assigning a document with a score that depends on 
> *all* the query terms, collection statistics and the document length. The 
> general idea of what I did is adding a new getBackGroundScore(int docID) 
> method to similarity, scorer and bulkScorer. Than, when a collector assigns a 
> score to a document (score = scorer.score()) I added the backgound score 
> (score=scorer.score()+scorer.background(doc)) that is assigned by the 
> similarity class used for ranking. 
> The patch also includes a correction of the document length such that it will 
> be the real document length and not the encoded one. It is required for the 
> full LM implementation.  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6302) Add implicit update request handlers


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

Mark Miller commented on SOLR-6302:
---

I wonder if the regular /update hander is a good idea to take out. 

It makes it easy to understand how to use a different update chain, it's not 
very verbose, and it would be a pain to add it when you want to change some 
settings.

/update is so central, it seems really odd to me to take out by default.

The other deprecated stuff, for sure doesn't need to be in 5x.

> Add implicit update request handlers
> 
>
> Key: SOLR-6302
> URL: https://issues.apache.org/jira/browse/SOLR-6302
> Project: Solr
>  Issue Type: Sub-task
>  Components: update
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> like we add implicit responseWriters lets add implicit updatehandlers also 
> and get rid of the following from solrconfig.xml
> {code:xml}
>   
> 
> 
>   
> 
>   
> 
>  application/json
>
>   
>   
>   
> 
>  application/json
>  doc
>
>   
>   
> 
>  application/csv
>
>   
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6294) The JsonLoader should accept a single doc without wrapping in an array

2014-07-30 Thread Noble Paul (JIRA)


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

Noble Paul commented on SOLR-6294:
--

[~varunthacker]  Please open annother bug and we should fix it

> The JsonLoader should accept a single doc without wrapping in an array
> --
>
> Key: SOLR-6294
> URL: https://issues.apache.org/jira/browse/SOLR-6294
> Project: Solr
>  Issue Type: Bug
>  Components: update
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
>
> This is the multi document input command
> {noformat}
> curl http://localhost:8983/solr/update/json -H 
> 'Content-type:application/json' -d '
> [
>  {"id" : "TestDoc1", "title" : "test1"},
> ]'
> {noformat}
> The following also should be a valid update command for a single doc
> {noformat}
> curl http://localhost:8983/solr/update/json -H 
> 'Content-type:application/json' -d '
>  {"id" : "TestDoc1", "title" : "test1"},
> '
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5856) remove useless & 0x3f from *BitSet.get and company

2014-07-30 Thread Ryan Ernst (JIRA)


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

Ryan Ernst commented on LUCENE-5856:


+1

> remove useless & 0x3f from *BitSet.get and company
> --
>
> Key: LUCENE-5856
> URL: https://issues.apache.org/jira/browse/LUCENE-5856
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-5856.patch
>
>
> java specification says:
> {quote}
> If the promoted type of the left-hand operand is long, then only the six 
> lowest-order bits of the right-hand operand are used as the shift distance. 
> It is as if the right-hand operand were subjected to a bitwise logical AND 
> operator & (§15.22.1) with the mask value 0x3f (0b11). The shift distance 
> actually used is therefore always in the range 0 to 63, inclusive.
> {quote}
> and x86 works the same way.
> if we remove this, we just see less instructions with printassembly...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Created] (SOLR-6302) Add implicit update request handlers

2014-07-30 Thread Noble Paul (JIRA)

Noble Paul created SOLR-6302:


 Summary: Add implicit update request handlers
 Key: SOLR-6302
 URL: https://issues.apache.org/jira/browse/SOLR-6302
 Project: Solr
  Issue Type: Sub-task
Reporter: Noble Paul
Assignee: Noble Paul


like we add implicit responseWriters lets add implicit updatehandlers also and 
get rid of the following from solrconfig.xml

{code:xml}
  


  


  

 application/json
   
  
  
  

 application/json
 doc
   
  
  

 application/csv
   
  
{code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Updated] (SOLR-6295) AssertionError in ToChildBlockJoinScorer.advance

2014-07-30 Thread Varun Thacker (JIRA)


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

Varun Thacker updated SOLR-6295:


Attachment: SOLR-6295.patch

We should never create a childFilterQuery which matches parent documents as it 
violates the BJQ assert.

>From the test seed this was the query being formed which was causing the 
>AssertionError - 

{noformat}
q=name:python&fq=level_i:1&fl=id,[child parentFilter="level_i:1" 
childFilter="level_i:[1 TO 1]" limit="7"]
{noformat}

Patch fixes kidLevelMin to be 1 more than parentLevel always. We do the same in 
L1315 currently.

> AssertionError in ToChildBlockJoinScorer.advance
> 
>
> Key: SOLR-6295
> URL: https://issues.apache.org/jira/browse/SOLR-6295
> Project: Solr
>  Issue Type: Bug
>Reporter: Shalin Shekhar Mangar
> Attachments: SOLR-6295.patch, block-join.log
>
>
> This happened in Solr land in the 
> SolrExampleStreamingTest.testChildDoctransformer
> https://builds.apache.org/job/Lucene-Solr-Maven-4.x/665/
> {code}
> 327371 T810 oejs.ServletHandler.doHandle WARN Error for 
> /solr/collection1/select java.lang.AssertionError
>   at 
> org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:286)
>   at 
> org.apache.lucene.search.FilteredQuery$LeapFrogScorer.advanceToNextCommonDoc(FilteredQuery.java:274)
>   at 
> org.apache.lucene.search.FilteredQuery$LeapFrogScorer.nextDoc(FilteredQuery.java:286)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:192)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
>   at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:297)
>   at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:209)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1619)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1433)
>   at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:514)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocList(SolrIndexSearcher.java:1268)
>   at 
> org.apache.solr.response.transform.ChildDocTransformer.transform(ChildDocTransformerFactory.java:144)
>   at 
> org.apache.solr.response.TextResponseWriter.writeDocuments(TextResponseWriter.java:252)
>   at 
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:170)
>   at org.apache.solr.response.XMLWriter.writeResponse(XMLWriter.java:112)
>   at 
> org.apache.solr.response.XMLResponseWriter.write(XMLResponseWriter.java:40)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.writeResponse(SolrDispatchFilter.java:765)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:426)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory


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

Mark Miller commented on SOLR-3619:
---

bq. I'm asking if we want to include a minimal solrconfig.xml / schema.xml 
configuration that new users can use to setup their own index?

Yes, we must if we are going to remove the default core / collection. It must 
be very simple to create one then. I think you should not even have to specify 
config in which case you get the default.

{quote}I vote for a minimal solrconfig.xml and managed-schema; basically I 
would strip out all non-essential elements from the solrconfig.xml from the 
schema-less example for Solr's default config.{quote}

Ideally, that is what I want as well. You either start solr with std minimal 
config (perhaps the schema just has dynamic fields defined) or in schemaless. 
Either one should be just as easy. Some stuff should probably be commented out 
to make it easy to enable, but a lot could go in a kitchen sink example or doc.

bq. If so, where should that live?

No strong preference.

> Rename 'example' dir to 'server' and pull examples into an 'examples' 
> directory
> ---
>
> Key: SOLR-3619
> URL: https://issues.apache.org/jira/browse/SOLR-3619
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Timothy Potter
> Fix For: 4.9, 5.0
>
> Attachments: SOLR-3619.patch, SOLR-3619.patch, server-name-layout.png
>
>




--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory


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

Mark Miller commented on SOLR-3619:
---

Heh, you went full hog.

+1 from me, that's all stuff I want.

> Rename 'example' dir to 'server' and pull examples into an 'examples' 
> directory
> ---
>
> Key: SOLR-3619
> URL: https://issues.apache.org/jira/browse/SOLR-3619
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Timothy Potter
> Fix For: 4.9, 5.0
>
> Attachments: SOLR-3619.patch, SOLR-3619.patch, server-name-layout.png
>
>




--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Comment Edited] (LUCENE-5850) Constants#LUCENE_MAIN_VERSION can have broken values


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

Uwe Schindler edited comment on LUCENE-5850 at 7/30/14 1:34 PM:


Then we should change issue title and description!

{quote}
Constants#LUCENE_MAIN_VERSION is set to the Lucene Main version and should not 
contain minor versions. Well this is at least what I thought and to my 
knowledge what the comments say too. Yet in for instance 4.3.1 and 4.5.1 we 
broke this such that the version from SegmentsInfo can not be parsed with 
Version#parseLeniently. IMO we should really add an assertion that this 
constant doesn't throw an error and / or make the smoketester catch this. to me 
this is actually a index BWC break. Note that 4.8.1 doesn't have this problem...
{quote}

This was fixed in LUCENE-5537 because it enforced LUCENE_MAIN_VERSION to be 
"x.y" or "x.y.0.z" via regex. The reason why [~simonw] opened the issue was, 
because he was hurt by the broken releases before the added check.

The new issue is about the above 2 things:
- recording bugfix version in segmentinfos
- refactor Version


was (Author: thetaphi):
Then we should change issue title and description!

{quote}
Constants#LUCENE_MAIN_VERSION is set to the Lucene Main version and should not 
contain minor versions. Well this is at least what I thought and to my 
knowledge what the comments say too. Yet in for instance 4.3.1 and 4.5.1 we 
broke this such that the version from SegmentsInfo can not be parsed with 
Version#parseLeniently. IMO we should really add an assertion that this 
constant doesn't throw an error and / or make the smoketester catch this. to me 
this is actually a index BWC break. Note that 4.8.1 doesn't have this problem...
{quote}

This was fixed in LUCENE-5537 because it enforced LUCENE_MAIN_VERSION to be 
"x.y" or "x.y.0.z" via regex.

> Constants#LUCENE_MAIN_VERSION can have broken values 
> -
>
> Key: LUCENE-5850
> URL: https://issues.apache.org/jira/browse/LUCENE-5850
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Affects Versions: 4.3.1, 4.5.1
>Reporter: Simon Willnauer
> Fix For: 5.0, 4.10
>
> Attachments: LUCENE-5850.patch, LUCENE-5850.patch, 
> LUCENE-5850_bomb.patch, LUCENE-5850_smoketester.patch
>
>
> Constants#LUCENE_MAIN_VERSION is set to the Lucene Main version and should 
> not contain minor versions. Well this is at least what I thought and to my 
> knowledge what the comments say too. Yet in for instance 4.3.1 and 4.5.1 we 
> broke this such that the version from SegmentsInfo can not be parsed with 
> Version#parseLeniently. IMO we should really add an assertion that this 
> constant doesn't throw an error and / or make the smoketester catch this. to 
> me this is actually a index BWC break. Note that 4.8.1 doesn't have this 
> problem...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5850) Constants#LUCENE_MAIN_VERSION can have broken values


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

Uwe Schindler commented on LUCENE-5850:
---

Then we should change issue title and description!

{quote}
Constants#LUCENE_MAIN_VERSION is set to the Lucene Main version and should not 
contain minor versions. Well this is at least what I thought and to my 
knowledge what the comments say too. Yet in for instance 4.3.1 and 4.5.1 we 
broke this such that the version from SegmentsInfo can not be parsed with 
Version#parseLeniently. IMO we should really add an assertion that this 
constant doesn't throw an error and / or make the smoketester catch this. to me 
this is actually a index BWC break. Note that 4.8.1 doesn't have this problem...
{quote}

This was fixed in LUCENE-5537 because it enforced LUCENE_MAIN_VERSION to be 
"x.y" or "x.y.0.z" via regex.

> Constants#LUCENE_MAIN_VERSION can have broken values 
> -
>
> Key: LUCENE-5850
> URL: https://issues.apache.org/jira/browse/LUCENE-5850
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Affects Versions: 4.3.1, 4.5.1
>Reporter: Simon Willnauer
> Fix For: 5.0, 4.10
>
> Attachments: LUCENE-5850.patch, LUCENE-5850.patch, 
> LUCENE-5850_bomb.patch, LUCENE-5850_smoketester.patch
>
>
> Constants#LUCENE_MAIN_VERSION is set to the Lucene Main version and should 
> not contain minor versions. Well this is at least what I thought and to my 
> knowledge what the comments say too. Yet in for instance 4.3.1 and 4.5.1 we 
> broke this such that the version from SegmentsInfo can not be parsed with 
> Version#parseLeniently. IMO we should really add an assertion that this 
> constant doesn't throw an error and / or make the smoketester catch this. to 
> me this is actually a index BWC break. Note that 4.8.1 doesn't have this 
> problem...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5859) Remove Version.java completely

2014-07-30 Thread Shai Erera (JIRA)


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

Shai Erera commented on LUCENE-5859:


bq. I tried to be reasonable here and open an issue with a compromise. Its 
clear this is a mistake

Why is this a mistake? Are we not allowed to discuss the proposal? I raised 
some concerns around runtime back-compat, not as a means to oppress your 
proposal, but to note something to think about. It's fine if you want to say "I 
don't care about it, users should RTFM". I personally won't be against it. But 
maybe others in the community will want to say something about it ...

> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Updated] (LUCENE-5859) Remove Version.java completely


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

Robert Muir updated LUCENE-5859:


Description: 
This has always been a mess: analyzers are easy enough to make on your own, we 
don't need to "take responsibility" for the users analysis chain for 2 major 
releases.

The code maintenance is horrible here.

This creates a huge usability issue too, and as seen from numerous mailing list 
issues, users don't even understand how this versioning works anyway.

I'm sure someone will whine if i try to remove these constants, but we can at 
least make no-arg ctors forwarding to VERSION_CURRENT so that people who don't 
care about back compat (e.g. just prototyping) don't have to deal with the 
horribly complex versioning system.

If you want to make the argument that doing this is "trappy" (i heard this 
before), i think thats bogus, and ill counter by trying to remove them. Either 
way, I'm personally not going to add any of this kind of back compat logic 
myself ever again.

Updated: description of the issue updated as expected. We should remove this 
API completely. No one else on the planet has APIs that require a mandatory 
version parameter.

  was:
This has always been a mess: analyzers are easy enough to make on your own, we 
don't need to "take responsibility" for the users analysis chain for 2 major 
releases.

The code maintenance is horrible here.

This creates a huge usability issue too, and as seen from numerous mailing list 
issues, users don't even understand how this versioning works anyway.

I'm sure someone will whine if i try to remove these constants, but we can at 
least make no-arg ctors forwarding to VERSION_CURRENT so that people who don't 
care about back compat (e.g. just prototyping) don't have to deal with the 
horribly complex versioning system.

If you want to make the argument that doing this is "trappy" (i heard this 
before), i think thats bogus, and ill counter by trying to remove them. Either 
way, I'm personally not going to add any of this kind of back compat logic 
myself ever again.

Summary: Remove Version.java completely  (was: add no-Version parameter 
to Analyzers/QueryParser)

> Remove Version.java completely
> --
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this 
> API completely. No one else on the planet has APIs that require a mandatory 
> version parameter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[JENKINS-MAVEN] Lucene-Solr-Maven-4.x #666: POMs out of sync

Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/666/

1 tests failed.
REGRESSION:  org.apache.solr.cloud.MultiThreadedOCPTest.testDistribSearch

Error Message:
We have a failed SPLITSHARD task

Stack Trace:
java.lang.AssertionError: We have a failed SPLITSHARD task
at 
__randomizedtesting.SeedInfo.seed([D80927D6DF3434BD:59EFA9CEA86B5481]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.MultiThreadedOCPTest.testTaskExclusivity(MultiThreadedOCPTest.java:125)
at 
org.apache.solr.cloud.MultiThreadedOCPTest.doTest(MultiThreadedOCPTest.java:71)




Build Log:
[...truncated 53054 lines...]
BUILD FAILED
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-4.x/build.xml:490: 
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-4.x/build.xml:182: 
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-4.x/extra-targets.xml:77:
 Java returned: 1

Total time: 207 minutes 4 seconds
Build step 'Invoke Ant' marked build as failure
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure



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

[jira] [Commented] (LUCENE-5859) add no-Version parameter to Analyzers/QueryParser


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

Robert Muir commented on LUCENE-5859:
-

{quote}
That's why I proposed the Foo48Analyzer, so a Foo49Analyzer does not silently 
break your app
{quote}

This argument is bogus. As i said, if you want back compat, you can use the 
ctor parameter with the version constant, otherwise you dont have to. 

I tried to be reasonable here and open an issue with a compromise. Its clear 
this is a mistake. I'm now going down the path of removing Version completely. 
This will at the same time address my other concerns with having multiple 
version apis.

> add no-Version parameter to Analyzers/QueryParser
> -
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5859) add no-Version parameter to Analyzers/QueryParser

2014-07-30 Thread Shai Erera (JIRA)


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

Shai Erera commented on LUCENE-5859:


The thing that worries me is that if you upgrade your app from 4.8 to 4.9 and a 
FooAnalyzer changed runtime behavior, and you didn't read the CHANGES, your app 
will break silently or loudly, depending on the back-compat break. And you may 
not notice that break until it's too late.

At least with Codecs, you cannot continue to index w/ a Foo48Codec because we 
remove the indexing classes and you will get a RuntimeException. That's why I 
proposed the Foo48Analyzer, so a Foo49Analyzer does not silently break your 
app, and if you upgrade your app to use it, then it's your responsibility to 
understand the changes and determine what needs to be done in your app.

I'm not against the proposal here, just raising some concerns that I have. 
Going w/ a no-Version ctor does not address the silent break you may experience 
if you don't read the CHANGES ...

> add no-Version parameter to Analyzers/QueryParser
> -
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.0
>
>
> This has always been a mess: analyzers are easy enough to make on your own, 
> we don't need to "take responsibility" for the users analysis chain for 2 
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing 
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at 
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who 
> don't care about back compat (e.g. just prototyping) don't have to deal with 
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this 
> before), i think thats bogus, and ill counter by trying to remove them. 
> Either way, I'm personally not going to add any of this kind of back compat 
> logic myself ever again.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5850) Constants#LUCENE_MAIN_VERSION can have broken values


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

Robert Muir commented on LUCENE-5850:
-

I don't think the real problem (confusion) is fixed yet. Seems to me that 
making a new issue will just make it harder to follow the discussion.

> Constants#LUCENE_MAIN_VERSION can have broken values 
> -
>
> Key: LUCENE-5850
> URL: https://issues.apache.org/jira/browse/LUCENE-5850
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Affects Versions: 4.3.1, 4.5.1
>Reporter: Simon Willnauer
> Fix For: 5.0, 4.10
>
> Attachments: LUCENE-5850.patch, LUCENE-5850.patch, 
> LUCENE-5850_bomb.patch, LUCENE-5850_smoketester.patch
>
>
> Constants#LUCENE_MAIN_VERSION is set to the Lucene Main version and should 
> not contain minor versions. Well this is at least what I thought and to my 
> knowledge what the comments say too. Yet in for instance 4.3.1 and 4.5.1 we 
> broke this such that the version from SegmentsInfo can not be parsed with 
> Version#parseLeniently. IMO we should really add an assertion that this 
> constant doesn't throw an error and / or make the smoketester catch this. to 
> me this is actually a index BWC break. Note that 4.8.1 doesn't have this 
> problem...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5850) Constants#LUCENE_MAIN_VERSION can have broken values