date:20140904

[
https://issues.apache.org/jira/browse/LUCENE-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121014#comment-14121014
]

Uwe Schindler commented on LUCENE-5920:
---

Hi Robert,
this cannot be fixed easily, the reason is that the statistics are initialized
before the -beast target is invoked and the message printed after the
-beast target. This is completely out of the scope of our groovy script.
I generally try the whole stuff first with a low beast.iter or simple ant test
and later replace the beast count once I am sure it works.

bq. About your additional idea, i think we can do it, but I think we need to
fix this check to happen on the first iteration?

The problem is: you get no output at all. If a test error happens you won't see
it, too. You just see the BuildException, nothing more (I tried it with a fake
failure).

bq. If we fix this, we don't need any of the current output, just maybe a .
or some other kind of status bar to see progress.

We would then need to switch on/off on every iteration and print a single line
log message (the beaster iteration, like we do currently). Printing all
progress into one line is impossible with ANT. You must log whole lines.

tweak junit4 output options for 'ant beast'
---

Key: LUCENE-5920
URL: https://issues.apache.org/jira/browse/LUCENE-5920
Project: Lucene - Core
Issue Type: Test
Reporter: Robert Muir
Fix For: 5.0, 4.11

Attachments: LUCENE-5920-silencer1.patch, LUCENE-5920.patch,
LUCENE-5920.patch

Currently, this outputs way too much, e.g. including all test output for
every passing run (because this is the behavior when -Dtestcase is set).
Especially with tests.verbose, this is really annoying as you have output
from say 200 runs that you don't care about.
I think ant beast should only show the interesting output for the failing run
and try to suppress unnecessary output as much as possible for passing ones
(it should be JUST enough to know your test ran and passed and not ignored,
e.g. you didnt screw up).

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5920) tweak junit4 output options for 'ant beast'


[ 
https://issues.apache.org/jira/browse/LUCENE-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121023#comment-14121023
 ] 

Dawid Weiss commented on LUCENE-5920:
-

 -echo5 slowest tests:/echo

Why was it useless? I warn you -- you'll get to reply to people asking what 
'tophints' shows in the future! :)


 tweak junit4 output options for 'ant beast'
 ---

 Key: LUCENE-5920
 URL: https://issues.apache.org/jira/browse/LUCENE-5920
 Project: Lucene - Core
  Issue Type: Test
Reporter: Robert Muir
 Fix For: 5.0, 4.11

 Attachments: LUCENE-5920-silencer1.patch, LUCENE-5920.patch, 
 LUCENE-5920.patch


 Currently, this outputs way too much, e.g. including all test output for 
 every passing run (because this is the behavior when -Dtestcase is set).
 Especially with tests.verbose, this is really annoying as you have output 
 from say 200 runs that you don't care about.
 I think ant beast should only show the interesting output for the failing run 
 and try to suppress unnecessary output as much as possible for passing ones 
 (it should be JUST enough to know your test ran and passed and not ignored, 
 e.g. you didnt screw up).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (LUCENE-5920) tweak junit4 output options for 'ant beast'

[
https://issues.apache.org/jira/browse/LUCENE-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121014#comment-14121014
]

Uwe Schindler edited comment on LUCENE-5920 at 9/4/14 6:46 AM:
---

bq. About your additional idea, i think we can do it, but I think we need to
fix this check to happen on the first iteration?

The problem is: you get no output at all. If a test error happens you won't see
it, too. You just see the BuildException, nothing more (I tried it with a fake
failure). The main issue: You don't even see the reproduce line with seed.

We can do this if junit4 is fixed to make use of log levels. By default, Ant
logs with level WARN. If I allow minimum of WARN to be printed, I see
everything. For minimum ERROR I see nothing (that is what 0 means when I
tested it).

Unfortunately, Ant's API added log levels later, so for backwards compatibility
it is not enforced to be given. And because of this every task around there
just prints with default WARN level. The reason is also that you never see a
difference in the output (e.g., Maven shows log level like any good logger
does), but Ant ignores it completely in its output. These 2 facts make the log
levels ignored by everyone creating tasks, including [~dweiss] (also the Ant
people themselves don't care).

bq. If we fix this, we don't need any of the current output, just maybe a .
or some other kind of status bar to see progress.

was (Author: thetaphi):
Hi Robert,
this cannot be fixed easily, the reason is that the statistics are initialized
before the -beast target is invoked and the message printed after the
-beast target. This is completely out of the scope of our groovy script.
I generally try the whole stuff first with a low beast.iter or simple ant test
and later replace the beast count once I am sure it works.

bq. About your additional idea, i think we can do it, but I think we need to
fix this check to happen on the first iteration?

The problem is: you get no output at all. If a test error happens you won't see
it, too. You just see the BuildException, nothing more (I tried it with a fake
failure).

bq. If we fix this, we don't need any of the current output, just maybe a .
or some other kind of status bar to see progress.

tweak junit4 output options for 'ant beast'
---

Key: LUCENE-5920
URL: https://issues.apache.org/jira/browse/LUCENE-5920
Project: Lucene - Core
Issue Type: Test
Reporter: Robert Muir
Fix For: 5.0, 4.11

Attachments: LUCENE-5920-silencer1.patch, LUCENE-5920.patch,
LUCENE-5920.patch

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5920) tweak junit4 output options for 'ant beast'


[ 
https://issues.apache.org/jira/browse/LUCENE-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121026#comment-14121026
 ] 

Uwe Schindler commented on LUCENE-5920:
---

bq. Why was it useless?

I changed the taskname, see commit. With the current version its much better 
now, but the log message is just a static line of text, so:
If you want to have it, include it into the output of the tophints task - 
that's my opinion.

 tweak junit4 output options for 'ant beast'
 ---

 Key: LUCENE-5920
 URL: https://issues.apache.org/jira/browse/LUCENE-5920
 Project: Lucene - Core
  Issue Type: Test
Reporter: Robert Muir
 Fix For: 5.0, 4.11

 Attachments: LUCENE-5920-silencer1.patch, LUCENE-5920.patch, 
 LUCENE-5920.patch


 Currently, this outputs way too much, e.g. including all test output for 
 every passing run (because this is the behavior when -Dtestcase is set).
 Especially with tests.verbose, this is really annoying as you have output 
 from say 200 runs that you don't care about.
 I think ant beast should only show the interesting output for the failing run 
 and try to suppress unnecessary output as much as possible for passing ones 
 (it should be JUST enough to know your test ran and passed and not ignored, 
 e.g. you didnt screw up).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5920) tweak junit4 output options for 'ant beast'


[ 
https://issues.apache.org/jira/browse/LUCENE-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121040#comment-14121040
 ] 

Dawid Weiss commented on LUCENE-5920:
-

 These 2 facts make the log levels ignored by everyone creating tasks, 
 including Dawid Weiss (also the Ant people themselves don't care).

I do care about log levels and I log through Ant's logging system. The text 
report does not (because it streams underlying output from tests; it'd be a 
killer to push it through so many indirection levels). There is nothing to 
prevent one from writing a custom event listener and format the output in any 
way one likes (I mentioned to Robert that a simple dotted output per test ('.' 
- success, 'F' - failure) would also be doable.

https://github.com/carrotsearch/randomizedtesting/blob/master/junit4-ant/src/main/java/com/carrotsearch/ant/tasks/junit4/listeners/AggregatedEventListener.java

The (example) text listener is here:

https://github.com/carrotsearch/randomizedtesting/blob/master/junit4-ant/src/main/java/com/carrotsearch/ant/tasks/junit4/listeners/TextReport.java

 tweak junit4 output options for 'ant beast'
 ---

 Key: LUCENE-5920
 URL: https://issues.apache.org/jira/browse/LUCENE-5920
 Project: Lucene - Core
  Issue Type: Test
Reporter: Robert Muir
 Fix For: 5.0, 4.11

 Attachments: LUCENE-5920-silencer1.patch, LUCENE-5920.patch, 
 LUCENE-5920.patch


 Currently, this outputs way too much, e.g. including all test output for 
 every passing run (because this is the behavior when -Dtestcase is set).
 Especially with tests.verbose, this is really annoying as you have output 
 from say 200 runs that you don't care about.
 I think ant beast should only show the interesting output for the failing run 
 and try to suppress unnecessary output as much as possible for passing ones 
 (it should be JUST enough to know your test ran and passed and not ignored, 
 e.g. you didnt screw up).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5920) tweak junit4 output options for 'ant beast'


[ 
https://issues.apache.org/jira/browse/LUCENE-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121042#comment-14121042
 ] 

Dawid Weiss commented on LUCENE-5920:
-

I could probably take logging level into account here:

https://github.com/carrotsearch/randomizedtesting/blob/master/junit4-ant/src/main/java/com/carrotsearch/ant/tasks/junit4/listeners/TextReport.java#L340

Don't know; does it make sense to you?

 tweak junit4 output options for 'ant beast'
 ---

 Key: LUCENE-5920
 URL: https://issues.apache.org/jira/browse/LUCENE-5920
 Project: Lucene - Core
  Issue Type: Test
Reporter: Robert Muir
 Fix For: 5.0, 4.11

 Attachments: LUCENE-5920-silencer1.patch, LUCENE-5920.patch, 
 LUCENE-5920.patch


 Currently, this outputs way too much, e.g. including all test output for 
 every passing run (because this is the behavior when -Dtestcase is set).
 Especially with tests.verbose, this is really annoying as you have output 
 from say 200 runs that you don't care about.
 I think ant beast should only show the interesting output for the failing run 
 and try to suppress unnecessary output as much as possible for passing ones 
 (it should be JUST enough to know your test ran and passed and not ignored, 
 e.g. you didnt screw up).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5920) tweak junit4 output options for 'ant beast'

[
https://issues.apache.org/jira/browse/LUCENE-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121053#comment-14121053
]

Uwe Schindler commented on LUCENE-5920:
---

I think this was a misunderstanding. You are talking about listeners to events
and log events in JUnit4.

The fast approach here was to disable logging completely in ANT: Raise the
log level to ERROR. My problem was then caused by the fact that Ant then did
not show anything anymore. The approach here was to let Ant itsself supress
logging. The groovy beaster script can do this easily.

I was referring to this approach:
http://stackoverflow.com/questions/5462732/make-ant-quiet-without-the-q-flag
(although the scripts inside are wrong, because they miss correct checks and
assume that there is only one build listener).

Ant's loggers can only print whole lines, how to work around that?

tweak junit4 output options for 'ant beast'
---

Key: LUCENE-5920
URL: https://issues.apache.org/jira/browse/LUCENE-5920
Project: Lucene - Core
Issue Type: Test
Reporter: Robert Muir
Fix For: 5.0, 4.11

Attachments: LUCENE-5920-silencer1.patch, LUCENE-5920.patch,
LUCENE-5920.patch

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-5920) tweak junit4 output options for 'ant beast'


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

Uwe Schindler updated LUCENE-5920:
--
Attachment: LUCENE-5920-silencer2.patch

This is my idea (disable logging on the ant level).

This is how it looks now when everything goes well:

{noformat}
$ ant beast -Dbeast.iters=10 -Dtestcase=TestVersion
[...]
-init-totals:

-beast:
  [beaster] Beast round: 1
  [beaster] Beast round: 2
  [beaster] Beast round: 3
  [beaster] Beast round: 4
  [beaster] Beast round: 5
  [beaster] Beast round: 6
  [beaster] Beast round: 7
  [beaster] Beast round: 8
  [beaster] Beast round: 9
  [beaster] Beast round: 10
  [beaster] Beasting finished.

-check-totals:

beast:

BUILD SUCCESSFUL
Total time: 23 seconds
{noformat}

Unfortunately this is how it looks when it goes wrong:

{noformat}
$ ant beast -Dbeast.iters=10 -Dtestcase=TestVersion -Dtests.codec=foobar
[...]
-init-totals:

-beast:
  [beaster] Beast round: 1

BUILD FAILED
C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\lucene\common-build.xml:1352: The 
following error occurred while executing this line:
C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\lucene\common-build.xml:1347: The 
following error occurred while executing this line:
C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\lucene\common-build.xml:959: There were 
test failures: 1 suite, 0 tests, 1 suite-level error

Total time: 5 seconds
{noformat}

As you see, you get no idea what was wrong. This looks like caused by junit4 
not logging the error messages with a log level of at minimum WARN.

 tweak junit4 output options for 'ant beast'
 ---

 Key: LUCENE-5920
 URL: https://issues.apache.org/jira/browse/LUCENE-5920
 Project: Lucene - Core
  Issue Type: Test
Reporter: Robert Muir
 Fix For: 5.0, 4.11

 Attachments: LUCENE-5920-silencer1.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920.patch, LUCENE-5920.patch


 Currently, this outputs way too much, e.g. including all test output for 
 every passing run (because this is the behavior when -Dtestcase is set).
 Especially with tests.verbose, this is really annoying as you have output 
 from say 200 runs that you don't care about.
 I think ant beast should only show the interesting output for the failing run 
 and try to suppress unnecessary output as much as possible for passing ones 
 (it should be JUST enough to know your test ran and passed and not ignored, 
 e.g. you didnt screw up).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (LUCENE-5920) tweak junit4 output options for 'ant beast'


[ 
https://issues.apache.org/jira/browse/LUCENE-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121093#comment-14121093
 ] 

Uwe Schindler edited comment on LUCENE-5920 at 9/4/14 8:16 AM:
---

This is my idea (disable logging on the ant level).

This is how it looks now when everything goes well:

{noformat}
$ ant beast -Dbeast.iters=10 -Dtestcase=TestVersion
[...]
-init-totals:

-beast:
  [beaster] Beast round: 1
  [beaster] Beast round: 2
  [beaster] Beast round: 3
  [beaster] Beast round: 4
  [beaster] Beast round: 5
  [beaster] Beast round: 6
  [beaster] Beast round: 7
  [beaster] Beast round: 8
  [beaster] Beast round: 9
  [beaster] Beast round: 10
  [beaster] Beasting finished.

-check-totals:

beast:

BUILD SUCCESSFUL
Total time: 23 seconds
{noformat}

Unfortunately this is how it looks when it goes wrong:

{noformat}
$ ant beast -Dbeast.iters=10 -Dtestcase=TestVersion -Dtests.codec=foobar
[...]
-init-totals:

-beast:
  [beaster] Beast round: 1

BUILD FAILED
C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\lucene\common-build.xml:1352: The 
following error occurred while executing this line:
C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\lucene\common-build.xml:1347: The 
following error occurred while executing this line:
C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\lucene\common-build.xml:959: There were 
test failures: 1 suite, 0 tests, 1 suite-level error

Total time: 5 seconds
{noformat}

As you see, you get no idea what was wrong, nor get you a tests.seed on 
failure. This looks like caused by junit4 not logging the error messages with a 
log level of at minimum WARN, which you explained. Maybe all System.err stuff 
should be printed with error log level.


was (Author: thetaphi):
This is my idea (disable logging on the ant level).

This is how it looks now when everything goes well:

{noformat}
$ ant beast -Dbeast.iters=10 -Dtestcase=TestVersion
[...]
-init-totals:

-beast:
  [beaster] Beast round: 1
  [beaster] Beast round: 2
  [beaster] Beast round: 3
  [beaster] Beast round: 4
  [beaster] Beast round: 5
  [beaster] Beast round: 6
  [beaster] Beast round: 7
  [beaster] Beast round: 8
  [beaster] Beast round: 9
  [beaster] Beast round: 10
  [beaster] Beasting finished.

-check-totals:

beast:

BUILD SUCCESSFUL
Total time: 23 seconds
{noformat}

Unfortunately this is how it looks when it goes wrong:

{noformat}
$ ant beast -Dbeast.iters=10 -Dtestcase=TestVersion -Dtests.codec=foobar
[...]
-init-totals:

-beast:
  [beaster] Beast round: 1

BUILD FAILED
C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\lucene\common-build.xml:1352: The 
following error occurred while executing this line:
C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\lucene\common-build.xml:1347: The 
following error occurred while executing this line:
C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\lucene\common-build.xml:959: There were 
test failures: 1 suite, 0 tests, 1 suite-level error

Total time: 5 seconds
{noformat}

As you see, you get no idea what was wrong. This looks like caused by junit4 
not logging the error messages with a log level of at minimum WARN.

 tweak junit4 output options for 'ant beast'
 ---

 Key: LUCENE-5920
 URL: https://issues.apache.org/jira/browse/LUCENE-5920
 Project: Lucene - Core
  Issue Type: Test
Reporter: Robert Muir
 Fix For: 5.0, 4.11

 Attachments: LUCENE-5920-silencer1.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920.patch, LUCENE-5920.patch


 Currently, this outputs way too much, e.g. including all test output for 
 every passing run (because this is the behavior when -Dtestcase is set).
 Especially with tests.verbose, this is really annoying as you have output 
 from say 200 runs that you don't care about.
 I think ant beast should only show the interesting output for the failing run 
 and try to suppress unnecessary output as much as possible for passing ones 
 (it should be JUST enough to know your test ran and passed and not ignored, 
 e.g. you didnt screw up).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-5920) tweak junit4 output options for 'ant beast'


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

Uwe Schindler updated LUCENE-5920:
--
Attachment: LUCENE-5920-silencer2.patch

New patch that also works around Robert's problem (its a ugly hack: it short 
circuits the submodule counting, which is not applicable here, because beasting 
should never be used to dive into subdirs):

{noformat}
$ ant beast -Dbeast.iters=10 -Dtestcase=foobar
[...]
-init-totals:

-beast:
  [beaster] Beast round: 1

BUILD FAILED
C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\lucene\common-build.xml:1361: The 
following error occurred while executing this line:
C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\lucene\common-build.xml:1356: The 
following error occurred while executing this line:
C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\lucene\common-build.xml:1163: Beasting 
executed no tests (a typo in the filter pattern maybe?)

Total time: 3 seconds
{noformat}

Let me find a better solution for this...

 tweak junit4 output options for 'ant beast'
 ---

 Key: LUCENE-5920
 URL: https://issues.apache.org/jira/browse/LUCENE-5920
 Project: Lucene - Core
  Issue Type: Test
Reporter: Robert Muir
 Fix For: 5.0, 4.11

 Attachments: LUCENE-5920-silencer1.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920-silencer2.patch, LUCENE-5920.patch, 
 LUCENE-5920.patch


 Currently, this outputs way too much, e.g. including all test output for 
 every passing run (because this is the behavior when -Dtestcase is set).
 Especially with tests.verbose, this is really annoying as you have output 
 from say 200 runs that you don't care about.
 I think ant beast should only show the interesting output for the failing run 
 and try to suppress unnecessary output as much as possible for passing ones 
 (it should be JUST enough to know your test ran and passed and not ignored, 
 e.g. you didnt screw up).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5906) Use Files.delete instead of File.delete + made up exception

2014-09-04 Thread Michael McCandless (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121153#comment-14121153
 ] 

Michael McCandless commented on LUCENE-5906:


Wow, this is great: +1 to commit.  Crazy all the places in our sources that we 
had for deleting files...

 Use Files.delete instead of File.delete + made up exception
 ---

 Key: LUCENE-5906
 URL: https://issues.apache.org/jira/browse/LUCENE-5906
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-5906.patch, LUCENE-5906.patch


 We are on java7, if we cannot delete a file, this one returns a real 
 exception as to why.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.7.0_67) - Build # 11032 - Still Failing!

2014-09-04 Thread Michael McCandless

I committed a fix ... the replicator first replicates main index
files, then replicates taxo index files, then copies  fsyncs taxo
index segments_N, then copies  fsyncs main index segments_M.

But if an exc happens on 4th step, it goes and tries to remove all
files it had copied.

Then, virus checker can refuse to remove the taxo index segments_N,
yet succeed in removing other files referenced by segments_N, leaving
a broken latest commit.

It looks like corruption if you run CheckIndex, but not if you open a
reader (the SIS retry logic will succeed in falling back to the last
commit), so it's really a false corruption, and I fixed the test to
detect when this false corruption strikes, forcefully remove the
latest segments_N, and then confirm the index is not corrupt.

The same thing can also happen to a plain Lucene index...

Mike McCandless

http://blog.mikemccandless.com


On Wed, Sep 3, 2014 at 4:47 PM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
 I know what this (false report of exceeded output) is. I filed
 https://issues.apache.org/jira/browse/LUCENE-5921, but it's not really
 a bug; it's a side effect of how test rules and thread exception
 tracking is ordered.

 Dawid

 On Wed, Sep 3, 2014 at 4:55 PM, Robert Muir rcm...@gmail.com wrote:
 Thank you Dawid.


 On Wed, Sep 3, 2014 at 7:58 AM, Dawid Weiss
 dawid.we...@cs.put.poznan.pl wrote:
 I'll take a look at why this is printed:

[junit4] ERROR   0.00s J1 | IndexAndTaxonomyReplicationClientTest 
 (suite) 
[junit4] Throwable #1: java.lang.AssertionError: The test or
 suite printed 20384 bytes to stdout and stderr, even though the limit
 was set to 8192 bytes. Increase the limit with @Limit, ignore it
 completely with @SuppressSysoutChecks or run with -Dtests.verbose=true
[junit4] at __randomizedtesting.SeedInfo.seed([F78E514819F85101]:0)
[junit4] at java.lang.Thread.run(Thread.java:745)
[junit4] Completed on J1 in 4.87s, 5 tests, 1 failure, 1 error  
 FAILURES!

 It shouldn't be (in case of failures/ previous exceptions).

 Dawid

 On Wed, Sep 3, 2014 at 1:34 PM, Robert Muir rcm...@gmail.com wrote:
 It reproduces easily. I will investigate after I review Mike's fix on
 LUCENE-5919

 On Tue, Sep 2, 2014 at 7:53 PM, Policeman Jenkins Server
 jenk...@thetaphi.de wrote:
 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/11032/
 Java: 32bit/jdk1.7.0_67 -server -XX:+UseParallelGC

 2 tests failed.
 FAILED:  
 junit.framework.TestSuite.org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest

 Error Message:
 The test or suite printed 20384 bytes to stdout and stderr, even though 
 the limit was set to 8192 bytes. Increase the limit with @Limit, ignore 
 it completely with @SuppressSysoutChecks or run with -Dtests.verbose=true

 Stack Trace:
 java.lang.AssertionError: The test or suite printed 20384 bytes to stdout 
 and stderr, even though the limit was set to 8192 bytes. Increase the 
 limit with @Limit, ignore it completely with @SuppressSysoutChecks or run 
 with -Dtests.verbose=true
 at __randomizedtesting.SeedInfo.seed([F78E514819F85101]:0)
 at 
 org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:210)
 at 
 com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
 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.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
 at java.lang.Thread.run(Thread.java:745)


 REGRESSION:  
 org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest.testConsistencyOnExceptions

 Error Message:
 Captured an uncaught exception in thread: Thread[id=20, 
 name=ReplicationThread-indexAndTaxo, state=RUNNABLE, 
 group=TGRP-IndexAndTaxonomyReplicationClientTest]

 Stack Trace:
 com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an 
 uncaught exception in thread: Thread[id=20, 
 name=ReplicationThread-indexAndTaxo, state=RUNNABLE, 
 group=TGRP-IndexAndTaxonomyReplicationClientTest]
 at 
 __randomizedtesting.SeedInfo.seed([F78E514819F85101:7800B6E80B94A2FE]:0)
 Caused by: java.lang.RuntimeException: CheckIndex failed
 at __randomizedtesting.SeedInfo.seed([F78E514819F85101]:0)
 at org.apache.lucene.util.TestUtil.checkIndex(TestUtil.java:211)
 at

Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b26) - Build # 11170 - Failure!

2014-09-04 Thread Michael McCandless

Same failure I just committed a fix for ...

BTW, Uwe, how come the reply-to for these failures is
jenk...@thetaphi.de?  It almost bit me ... (i.e. I must remember to do
reply all not just reply).

Mike McCandless

http://blog.mikemccandless.com

On Wed, Sep 3, 2014 at 2:11 PM, Policeman Jenkins Server
jenk...@thetaphi.de wrote:
 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11170/
 Java: 64bit/jdk1.9.0-ea-b26 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

 1 tests failed.
 REGRESSION:  
 org.apache.lucene.replicator.IndexReplicationClientTest.testConsistencyOnExceptions

 Error Message:
 _2.fdt

 Stack Trace:
 java.io.FileNotFoundException: _2.fdt
 at 
 org.apache.lucene.store.RAMDirectory.fileLength(RAMDirectory.java:136)
 at 
 org.apache.lucene.store.NRTCachingDirectory.fileLength(NRTCachingDirectory.java:137)
 at 
 org.apache.lucene.store.MockDirectoryWrapper.fileLength(MockDirectoryWrapper.java:936)
 at 
 org.apache.lucene.index.SegmentCommitInfo.sizeInBytes(SegmentCommitInfo.java:217)
 at org.apache.lucene.index.CheckIndex.checkIndex(CheckIndex.java:546)
 at org.apache.lucene.util.TestUtil.checkIndex(TestUtil.java:207)
 at 
 org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:730)
 at org.apache.lucene.util.IOUtils.close(IOUtils.java:77)
 at 
 org.apache.lucene.replicator.IndexReplicationClientTest.tearDown(IndexReplicationClientTest.java:154)
 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:484)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:885)
 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 
 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

[jira] [Commented] (LUCENE-5920) tweak junit4 output options for 'ant beast'

[
https://issues.apache.org/jira/browse/LUCENE-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121164#comment-14121164
]

Dawid Weiss commented on LUCENE-5920:
-

As you see, you get no idea what was wrong, nor get you a tests.seed on
failure.

You always get the full test stream from this test listener:

{code}
!-- Emits status on errors and failures only. --
junit4:report-text
file=@{junit.output.dir}/tests-failures.txt
{code}

This looks like caused by junit4 not logging the error messages with a log
level of at minimum WARN, which you explained.

Well, I don't consider this a warning. Also, it'll be difficult to separate and
display just the reproduce-info because it's part of a regular stream from a
subprocess. You can always tail tests-failures.txt or tests-report.txt -- it
contains full streams from all tests.

tweak junit4 output options for 'ant beast'
---

Key: LUCENE-5920
URL: https://issues.apache.org/jira/browse/LUCENE-5920
Project: Lucene - Core
Issue Type: Test
Reporter: Robert Muir
Fix For: 5.0, 4.11

Attachments: LUCENE-5920-silencer1.patch,
LUCENE-5920-silencer2.patch, LUCENE-5920-silencer2.patch, LUCENE-5920.patch,
LUCENE-5920.patch

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-650) facet.field should accept field names separated by spaces or commas

2014-09-04 Thread Chris F (JIRA)


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

Chris F updated SOLR-650:
-
Attachment: SOLR-650.patch

 facet.field should accept field names separated by spaces or commas
 ---

 Key: SOLR-650
 URL: https://issues.apache.org/jira/browse/SOLR-650
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.3
Reporter: Lars Kotthoff
Priority: Minor
  Labels: newdev
 Attachments: SOLR-650.patch, SOLR-650.patch, SOLR-650.patch, 
 SOLR-650.patch


 The current version of SimpleFacets does not support specifying several 
 fields to facet on in a single facet.field parameter; it has to be specified 
 for each field. This behaviour is inconcistent with the other parameters 
 which accept field names as arguments -- they allow specifying multiple field 
 names either as a comma- or space-separated list or by specifying the 
 parameter multiple times.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-650) facet.field should accept field names separated by spaces or commas

2014-09-04 Thread Chris F (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121192#comment-14121192
 ] 

Chris F commented on SOLR-650:
--

Added a patch that applies to current trunk. It includes a new option named 
facet.fieldsaslist which defaults to false. When this option is true, it allows 
facet fields to be specified as a comma or space separated list:
{code:xml}
http://127.0.0.1:8983/solr/select?facet.fieldsaslist=truefacet.field=trait_s,name,manu_id_s
http://127.0.0.1:8983/solr/select?facet.fieldsaslist=truefacet.field=trait_s 
name manu_id_s
{code}

 facet.field should accept field names separated by spaces or commas
 ---

 Key: SOLR-650
 URL: https://issues.apache.org/jira/browse/SOLR-650
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.3
Reporter: Lars Kotthoff
Priority: Minor
  Labels: newdev
 Attachments: SOLR-650.patch, SOLR-650.patch, SOLR-650.patch, 
 SOLR-650.patch


 The current version of SimpleFacets does not support specifying several 
 fields to facet on in a single facet.field parameter; it has to be specified 
 for each field. This behaviour is inconcistent with the other parameters 
 which accept field names as arguments -- they allow specifying multiple field 
 names either as a comma- or space-separated list or by specifying the 
 parameter multiple times.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-5920) tweak junit4 output options for 'ant beast'

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

Uwe Schindler updated LUCENE-5920:
--
Attachment: LUCENE-5920-silencer2.patch

New patch:
On a BuildException, the beaster script logs contents of tests-failures.txt
file.

FYI, as the whole beasting is now silent, I can also revert the tophints stuff.
We could also revert the whole patch of Robert, because all log is swallowed
:-) Opinions?

[~dweiss]: The tests-failures file is in UTF-8 or the default encoding of
platform? I need this for the file.forEach(charset...).

tweak junit4 output options for 'ant beast'
---

Key: LUCENE-5920
URL: https://issues.apache.org/jira/browse/LUCENE-5920
Project: Lucene - Core
Issue Type: Test
Reporter: Robert Muir
Fix For: 5.0, 4.11

Attachments: LUCENE-5920-silencer1.patch,
LUCENE-5920-silencer2.patch, LUCENE-5920-silencer2.patch,
LUCENE-5920-silencer2.patch, LUCENE-5920.patch, LUCENE-5920.patch

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.7.0_67) - Build # 11032 - Still Failing!

2014-09-04 Thread Robert Muir

Is segments.gen good enough or should we look into atomic rename?

On Thu, Sep 4, 2014 at 5:16 AM, Michael McCandless
luc...@mikemccandless.com wrote:
 I committed a fix ... the replicator first replicates main index
 files, then replicates taxo index files, then copies  fsyncs taxo
 index segments_N, then copies  fsyncs main index segments_M.

 But if an exc happens on 4th step, it goes and tries to remove all
 files it had copied.

 Then, virus checker can refuse to remove the taxo index segments_N,
 yet succeed in removing other files referenced by segments_N, leaving
 a broken latest commit.

 It looks like corruption if you run CheckIndex, but not if you open a
 reader (the SIS retry logic will succeed in falling back to the last
 commit), so it's really a false corruption, and I fixed the test to
 detect when this false corruption strikes, forcefully remove the
 latest segments_N, and then confirm the index is not corrupt.

 The same thing can also happen to a plain Lucene index...

 Mike McCandless

 http://blog.mikemccandless.com


 On Wed, Sep 3, 2014 at 4:47 PM, Dawid Weiss
 dawid.we...@cs.put.poznan.pl wrote:
 I know what this (false report of exceeded output) is. I filed
 https://issues.apache.org/jira/browse/LUCENE-5921, but it's not really
 a bug; it's a side effect of how test rules and thread exception
 tracking is ordered.

 Dawid

 On Wed, Sep 3, 2014 at 4:55 PM, Robert Muir rcm...@gmail.com wrote:
 Thank you Dawid.


 On Wed, Sep 3, 2014 at 7:58 AM, Dawid Weiss
 dawid.we...@cs.put.poznan.pl wrote:
 I'll take a look at why this is printed:

[junit4] ERROR   0.00s J1 | IndexAndTaxonomyReplicationClientTest 
 (suite) 
[junit4] Throwable #1: java.lang.AssertionError: The test or
 suite printed 20384 bytes to stdout and stderr, even though the limit
 was set to 8192 bytes. Increase the limit with @Limit, ignore it
 completely with @SuppressSysoutChecks or run with -Dtests.verbose=true
[junit4] at __randomizedtesting.SeedInfo.seed([F78E514819F85101]:0)
[junit4] at java.lang.Thread.run(Thread.java:745)
[junit4] Completed on J1 in 4.87s, 5 tests, 1 failure, 1 error  
 FAILURES!

 It shouldn't be (in case of failures/ previous exceptions).

 Dawid

 On Wed, Sep 3, 2014 at 1:34 PM, Robert Muir rcm...@gmail.com wrote:
 It reproduces easily. I will investigate after I review Mike's fix on
 LUCENE-5919

 On Tue, Sep 2, 2014 at 7:53 PM, Policeman Jenkins Server
 jenk...@thetaphi.de wrote:
 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/11032/
 Java: 32bit/jdk1.7.0_67 -server -XX:+UseParallelGC

 2 tests failed.
 FAILED:  
 junit.framework.TestSuite.org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest

 Error Message:
 The test or suite printed 20384 bytes to stdout and stderr, even though 
 the limit was set to 8192 bytes. Increase the limit with @Limit, ignore 
 it completely with @SuppressSysoutChecks or run with -Dtests.verbose=true

 Stack Trace:
 java.lang.AssertionError: The test or suite printed 20384 bytes to 
 stdout and stderr, even though the limit was set to 8192 bytes. Increase 
 the limit with @Limit, ignore it completely with @SuppressSysoutChecks 
 or run with -Dtests.verbose=true
 at __randomizedtesting.SeedInfo.seed([F78E514819F85101]:0)
 at 
 org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:210)
 at 
 com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
 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.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
 at java.lang.Thread.run(Thread.java:745)


 REGRESSION:  
 org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest.testConsistencyOnExceptions

 Error Message:
 Captured an uncaught exception in thread: Thread[id=20, 
 name=ReplicationThread-indexAndTaxo, state=RUNNABLE, 
 group=TGRP-IndexAndTaxonomyReplicationClientTest]

 Stack Trace:
 com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an 
 uncaught exception in thread: Thread[id=20, 
 name=ReplicationThread-indexAndTaxo, state=RUNNABLE, 
 group=TGRP-IndexAndTaxonomyReplicationClientTest]
 at 
 __randomizedtesting.SeedInfo.seed([F78E514819F85101:7800B6E80B94A2FE]:0)
 Caused by: java.lang.RuntimeException: CheckIndex

[jira] [Comment Edited] (LUCENE-5920) tweak junit4 output options for 'ant beast'

[
https://issues.apache.org/jira/browse/LUCENE-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121201#comment-14121201
]

Uwe Schindler edited comment on LUCENE-5920 at 9/4/14 10:21 AM:

New patch:
On a BuildException, the beaster script logs contents of tests-failures.txt
file.

FYI, as the whole beasting is now silent, I can also revert the tophints stuff.
We could also revert the whole patch of Robert, because all log is swallowed
:-) Opinions?

[~dweiss]: The tests-failures file is in UTF-8 or the default encoding of
platform? I need this for the file.eachLine(charset...).

was (Author: thetaphi):
New patch:
On a BuildException, the beaster script logs contents of tests-failures.txt
file.

FYI, as the whole beasting is now silent, I can also revert the tophints stuff.
We could also revert the whole patch of Robert, because all log is swallowed
:-) Opinions?

[~dweiss]: The tests-failures file is in UTF-8 or the default encoding of
platform? I need this for the file.forEach(charset...).

tweak junit4 output options for 'ant beast'
---

Key: LUCENE-5920
URL: https://issues.apache.org/jira/browse/LUCENE-5920
Project: Lucene - Core
Issue Type: Test
Reporter: Robert Muir
Fix For: 5.0, 4.11

Attachments: LUCENE-5920-silencer1.patch,
LUCENE-5920-silencer2.patch, LUCENE-5920-silencer2.patch,
LUCENE-5920-silencer2.patch, LUCENE-5920.patch, LUCENE-5920.patch

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5920) tweak junit4 output options for 'ant beast'


[ 
https://issues.apache.org/jira/browse/LUCENE-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121213#comment-14121213
 ] 

Dawid Weiss commented on LUCENE-5920:
-

UTF-8:
https://github.com/carrotsearch/randomizedtesting/blob/master/junit4-ant/src/main/java/com/carrotsearch/ant/tasks/junit4/listeners/TextReport.java#L326

 tweak junit4 output options for 'ant beast'
 ---

 Key: LUCENE-5920
 URL: https://issues.apache.org/jira/browse/LUCENE-5920
 Project: Lucene - Core
  Issue Type: Test
Reporter: Robert Muir
 Fix For: 5.0, 4.11

 Attachments: LUCENE-5920-silencer1.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920-silencer2.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920.patch, LUCENE-5920.patch


 Currently, this outputs way too much, e.g. including all test output for 
 every passing run (because this is the behavior when -Dtestcase is set).
 Especially with tests.verbose, this is really annoying as you have output 
 from say 200 runs that you don't care about.
 I think ant beast should only show the interesting output for the failing run 
 and try to suppress unnecessary output as much as possible for passing ones 
 (it should be JUST enough to know your test ran and passed and not ignored, 
 e.g. you didnt screw up).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5906) Use Files.delete instead of File.delete + made up exception


[ 
https://issues.apache.org/jira/browse/LUCENE-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121218#comment-14121218
 ] 

Uwe Schindler commented on LUCENE-5906:
---

Maybe we should refactor the IOUtils a bit and provide varargs variants that 
simply delegate to {{Arrays.asList(varargs)}}.

We should also cleanup other code duplication in IOUtils and solely use 
asList()!

 Use Files.delete instead of File.delete + made up exception
 ---

 Key: LUCENE-5906
 URL: https://issues.apache.org/jira/browse/LUCENE-5906
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-5906.patch, LUCENE-5906.patch


 We are on java7, if we cannot delete a file, this one returns a real 
 exception as to why.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5920) tweak junit4 output options for 'ant beast'

[
https://issues.apache.org/jira/browse/LUCENE-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121222#comment-14121222
]

Uwe Schindler commented on LUCENE-5920:
---

Thanks, so the patch is fine. Any comments about reverting the original patches
here? The Ant-level silencer is in my opinion all we need, so we can remove the
crazy {{isset property=beast.iters/}} everywhere.

tweak junit4 output options for 'ant beast'
---

Key: LUCENE-5920
URL: https://issues.apache.org/jira/browse/LUCENE-5920
Project: Lucene - Core
Issue Type: Test
Reporter: Robert Muir
Fix For: 5.0, 4.11

Attachments: LUCENE-5920-silencer1.patch,
LUCENE-5920-silencer2.patch, LUCENE-5920-silencer2.patch,
LUCENE-5920-silencer2.patch, LUCENE-5920.patch, LUCENE-5920.patch

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5920) tweak junit4 output options for 'ant beast'


[ 
https://issues.apache.org/jira/browse/LUCENE-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121224#comment-14121224
 ] 

Robert Muir commented on LUCENE-5920:
-

Thanks Uwe, it just makes it nicer and simplifies the build IMO.

 tweak junit4 output options for 'ant beast'
 ---

 Key: LUCENE-5920
 URL: https://issues.apache.org/jira/browse/LUCENE-5920
 Project: Lucene - Core
  Issue Type: Test
Reporter: Robert Muir
 Fix For: 5.0, 4.11

 Attachments: LUCENE-5920-silencer1.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920-silencer2.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920.patch, LUCENE-5920.patch


 Currently, this outputs way too much, e.g. including all test output for 
 every passing run (because this is the behavior when -Dtestcase is set).
 Especially with tests.verbose, this is really annoying as you have output 
 from say 200 runs that you don't care about.
 I think ant beast should only show the interesting output for the failing run 
 and try to suppress unnecessary output as much as possible for passing ones 
 (it should be JUST enough to know your test ran and passed and not ignored, 
 e.g. you didnt screw up).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5906) Use Files.delete instead of File.delete + made up exception


[ 
https://issues.apache.org/jira/browse/LUCENE-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121225#comment-14121225
 ] 

Robert Muir commented on LUCENE-5906:
-

Yeah, lemme try to fix that.

At first, when looking at lucene-core, i didnt think even IOUtils methods for 
deleting were justified. Then i saw how many places were doing this, but tried 
to keep the minimal set here. And you are right, i didnt want to duplicate with 
varargs. But we should just use asList to avoid this (in close, too).



 Use Files.delete instead of File.delete + made up exception
 ---

 Key: LUCENE-5906
 URL: https://issues.apache.org/jira/browse/LUCENE-5906
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-5906.patch, LUCENE-5906.patch


 We are on java7, if we cannot delete a file, this one returns a real 
 exception as to why.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5920) tweak junit4 output options for 'ant beast'

2014-09-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121228#comment-14121228
 ] 

Uwe Schindler commented on LUCENE-5920:
---

OK, I reverted the previous patches. The whole thing still works.

I will now commit the revert and the new patch.

 tweak junit4 output options for 'ant beast'
 ---

 Key: LUCENE-5920
 URL: https://issues.apache.org/jira/browse/LUCENE-5920
 Project: Lucene - Core
  Issue Type: Test
Reporter: Robert Muir
 Fix For: 5.0, 4.11

 Attachments: LUCENE-5920-silencer1.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920-silencer2.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920.patch, LUCENE-5920.patch


 Currently, this outputs way too much, e.g. including all test output for 
 every passing run (because this is the behavior when -Dtestcase is set).
 Especially with tests.verbose, this is really annoying as you have output 
 from say 200 runs that you don't care about.
 I think ant beast should only show the interesting output for the failing run 
 and try to suppress unnecessary output as much as possible for passing ones 
 (it should be JUST enough to know your test ran and passed and not ignored, 
 e.g. you didnt screw up).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5920) tweak junit4 output options for 'ant beast'


[ 
https://issues.apache.org/jira/browse/LUCENE-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121229#comment-14121229
 ] 

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

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

LUCENE-5920: Revert previous commits (but leave the else attributes)

 tweak junit4 output options for 'ant beast'
 ---

 Key: LUCENE-5920
 URL: https://issues.apache.org/jira/browse/LUCENE-5920
 Project: Lucene - Core
  Issue Type: Test
Reporter: Robert Muir
 Fix For: 5.0, 4.11

 Attachments: LUCENE-5920-silencer1.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920-silencer2.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920.patch, LUCENE-5920.patch


 Currently, this outputs way too much, e.g. including all test output for 
 every passing run (because this is the behavior when -Dtestcase is set).
 Especially with tests.verbose, this is really annoying as you have output 
 from say 200 runs that you don't care about.
 I think ant beast should only show the interesting output for the failing run 
 and try to suppress unnecessary output as much as possible for passing ones 
 (it should be JUST enough to know your test ran and passed and not ignored, 
 e.g. you didnt screw up).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-5920) tweak junit4 output options for 'ant beast'

2014-09-04 Thread ASF subversion and git services (JIRA)


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

Uwe Schindler updated LUCENE-5920:
--
Attachment: LUCENE-5920-silencer2.patch

New patch after revert. Now passes extra property down in antcall for the 
early-exit on wrong testcase pattern.

 tweak junit4 output options for 'ant beast'
 ---

 Key: LUCENE-5920
 URL: https://issues.apache.org/jira/browse/LUCENE-5920
 Project: Lucene - Core
  Issue Type: Test
Reporter: Robert Muir
 Fix For: 5.0, 4.11

 Attachments: LUCENE-5920-silencer1.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920-silencer2.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920-silencer2.patch, LUCENE-5920.patch, 
 LUCENE-5920.patch


 Currently, this outputs way too much, e.g. including all test output for 
 every passing run (because this is the behavior when -Dtestcase is set).
 Especially with tests.verbose, this is really annoying as you have output 
 from say 200 runs that you don't care about.
 I think ant beast should only show the interesting output for the failing run 
 and try to suppress unnecessary output as much as possible for passing ones 
 (it should be JUST enough to know your test ran and passed and not ignored, 
 e.g. you didnt screw up).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5920) tweak junit4 output options for 'ant beast'


[ 
https://issues.apache.org/jira/browse/LUCENE-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121235#comment-14121235
 ] 

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

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

LUCENE-5920: New beasting silencer, variant #2

 tweak junit4 output options for 'ant beast'
 ---

 Key: LUCENE-5920
 URL: https://issues.apache.org/jira/browse/LUCENE-5920
 Project: Lucene - Core
  Issue Type: Test
Reporter: Robert Muir
 Fix For: 5.0, 4.11

 Attachments: LUCENE-5920-silencer1.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920-silencer2.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920-silencer2.patch, LUCENE-5920.patch, 
 LUCENE-5920.patch


 Currently, this outputs way too much, e.g. including all test output for 
 every passing run (because this is the behavior when -Dtestcase is set).
 Especially with tests.verbose, this is really annoying as you have output 
 from say 200 runs that you don't care about.
 I think ant beast should only show the interesting output for the failing run 
 and try to suppress unnecessary output as much as possible for passing ones 
 (it should be JUST enough to know your test ran and passed and not ignored, 
 e.g. you didnt screw up).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5920) tweak junit4 output options for 'ant beast'

2014-09-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121236#comment-14121236
 ] 

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

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

Merged revision(s) 1622449-1622451 from lucene/dev/trunk:
LUCENE-5920: Revert previous commits (but leave the else attributes)
LUCENE-5920: New beasting silencer, variant #2

 tweak junit4 output options for 'ant beast'
 ---

 Key: LUCENE-5920
 URL: https://issues.apache.org/jira/browse/LUCENE-5920
 Project: Lucene - Core
  Issue Type: Test
Reporter: Robert Muir
 Fix For: 5.0, 4.11

 Attachments: LUCENE-5920-silencer1.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920-silencer2.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920-silencer2.patch, LUCENE-5920.patch, 
 LUCENE-5920.patch


 Currently, this outputs way too much, e.g. including all test output for 
 every passing run (because this is the behavior when -Dtestcase is set).
 Especially with tests.verbose, this is really annoying as you have output 
 from say 200 runs that you don't care about.
 I think ant beast should only show the interesting output for the failing run 
 and try to suppress unnecessary output as much as possible for passing ones 
 (it should be JUST enough to know your test ran and passed and not ignored, 
 e.g. you didnt screw up).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-4.x-Windows (64bit/jdk1.7.0_67) - Build # 4198 - Still Failing!

2014-09-04 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/4198/
Java: 64bit/jdk1.7.0_67 -XX:-UseCompressedOops -XX:+UseSerialGC

No tests ran.

Build Log:
[...truncated 41378 lines...]
FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected 
termination of the channel
hudson.remoting.RequestAbortedException: 
hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected 
termination of the channel
at 
hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:41)
at 
hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:34)
at hudson.remoting.Request.call(Request.java:174)
at hudson.remoting.Channel.call(Channel.java:739)
at 
hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:168)
at com.sun.proxy.$Proxy75.join(Unknown Source)
at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:978)
at hudson.Launcher$ProcStarter.join(Launcher.java:387)
at hudson.tasks.Ant.perform(Ant.java:217)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770)
at hudson.model.Build$BuildExecution.build(Build.java:199)
at hudson.model.Build$BuildExecution.doRun(Build.java:160)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:533)
at hudson.model.Run.execute(Run.java:1740)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)
Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: 
Unexpected termination of the channel
at hudson.remoting.Request.abort(Request.java:299)
at hudson.remoting.Channel.terminate(Channel.java:802)
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69)
Caused by: java.io.IOException: Unexpected termination of the channel
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50)
Caused by: java.io.EOFException
at 
java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2325)
at 
java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2794)
at 
java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:801)
at java.io.ObjectInputStream.init(ObjectInputStream.java:299)
at 
hudson.remoting.ObjectInputStreamEx.init(ObjectInputStreamEx.java:40)
at 
hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34)
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)



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

[jira] [Commented] (LUCENE-5920) tweak junit4 output options for 'ant beast'


[ 
https://issues.apache.org/jira/browse/LUCENE-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121239#comment-14121239
 ] 

Uwe Schindler commented on LUCENE-5920:
---

OK, done. I did not reopen, so no Resolve.

 tweak junit4 output options for 'ant beast'
 ---

 Key: LUCENE-5920
 URL: https://issues.apache.org/jira/browse/LUCENE-5920
 Project: Lucene - Core
  Issue Type: Test
Reporter: Robert Muir
 Fix For: 5.0, 4.11

 Attachments: LUCENE-5920-silencer1.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920-silencer2.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920-silencer2.patch, LUCENE-5920.patch, 
 LUCENE-5920.patch


 Currently, this outputs way too much, e.g. including all test output for 
 every passing run (because this is the behavior when -Dtestcase is set).
 Especially with tests.verbose, this is really annoying as you have output 
 from say 200 runs that you don't care about.
 I think ant beast should only show the interesting output for the failing run 
 and try to suppress unnecessary output as much as possible for passing ones 
 (it should be JUST enough to know your test ran and passed and not ignored, 
 e.g. you didnt screw up).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-5906) Use Files.delete instead of File.delete + made up exception


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

Robert Muir updated LUCENE-5906:

Attachment: LUCENE-5906.patch

Updated patch removing Arrays.asList/singleton stuff with varargs sugar instead.

 Use Files.delete instead of File.delete + made up exception
 ---

 Key: LUCENE-5906
 URL: https://issues.apache.org/jira/browse/LUCENE-5906
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-5906.patch, LUCENE-5906.patch, LUCENE-5906.patch


 We are on java7, if we cannot delete a file, this one returns a real 
 exception as to why.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5906) Use Files.delete instead of File.delete + made up exception

2014-09-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121244#comment-14121244
 ] 

Uwe Schindler commented on LUCENE-5906:
---

+1, thanks!

 Use Files.delete instead of File.delete + made up exception
 ---

 Key: LUCENE-5906
 URL: https://issues.apache.org/jira/browse/LUCENE-5906
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-5906.patch, LUCENE-5906.patch, LUCENE-5906.patch


 We are on java7, if we cannot delete a file, this one returns a real 
 exception as to why.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LUCENE-5923) cannot re-use Field in 4.7.2

2014-09-04 Thread Sam Halliday (JIRA)

Sam Halliday created LUCENE-5923:


 Summary: cannot re-use Field in 4.7.2
 Key: LUCENE-5923
 URL: https://issues.apache.org/jira/browse/LUCENE-5923
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Sam Halliday


I get an exception first position increment must be  0 (got 0) for field ... 
when I try to re-use a Field as an entry in a Document. Snippet below.

This works ok on lucene 4.9, but I have to go back to 4.7 for Java 6 
compatibility.

Workaround is to not re-use the same object in each Document.

(this is Scala)

private val TypeField = new StringField(TYPE, clazz.getSimpleName, 
Store.YES)

final def toDocument(t: T): Document = {
  val doc = new Document
  // Lucene 4.7.2 bug: re-using the common object gives
  // first position increment must be  0 (got 0) for field 'TYPE'
  //doc.add(TypeField)
  doc.add(new StringField(TYPE, clazz.getSimpleName, Store.YES))
  doc.add(new StringField(ID, id(t), Store.NO))
  doc
}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5923) cannot re-use Field in 4.7.2

2014-09-04 Thread Sam Halliday (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121249#comment-14121249
 ] 

Sam Halliday commented on LUCENE-5923:
--

another workaround appears to be to synchronize all writes :-/

 cannot re-use Field in 4.7.2
 

 Key: LUCENE-5923
 URL: https://issues.apache.org/jira/browse/LUCENE-5923
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Sam Halliday

 I get an exception first position increment must be  0 (got 0) for field 
 ... when I try to re-use a Field as an entry in a Document. Snippet below.
 This works ok on lucene 4.9, but I have to go back to 4.7 for Java 6 
 compatibility.
 Workaround is to not re-use the same object in each Document.
 (this is Scala)
 private val TypeField = new StringField(TYPE, clazz.getSimpleName, 
 Store.YES)
 final def toDocument(t: T): Document = {
   val doc = new Document
   // Lucene 4.7.2 bug: re-using the common object gives
   // first position increment must be  0 (got 0) for field 'TYPE'
   //doc.add(TypeField)
   doc.add(new StringField(TYPE, clazz.getSimpleName, Store.YES))
   doc.add(new StringField(ID, id(t), Store.NO))
   doc
 }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5920) tweak junit4 output options for 'ant beast'


[ 
https://issues.apache.org/jira/browse/LUCENE-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121273#comment-14121273
 ] 

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

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

LUCENE-5920: More elegant (groovy-like) task creation

 tweak junit4 output options for 'ant beast'
 ---

 Key: LUCENE-5920
 URL: https://issues.apache.org/jira/browse/LUCENE-5920
 Project: Lucene - Core
  Issue Type: Test
Reporter: Robert Muir
 Fix For: 5.0, 4.11

 Attachments: LUCENE-5920-silencer1.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920-silencer2.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920-silencer2.patch, LUCENE-5920.patch, 
 LUCENE-5920.patch


 Currently, this outputs way too much, e.g. including all test output for 
 every passing run (because this is the behavior when -Dtestcase is set).
 Especially with tests.verbose, this is really annoying as you have output 
 from say 200 runs that you don't care about.
 I think ant beast should only show the interesting output for the failing run 
 and try to suppress unnecessary output as much as possible for passing ones 
 (it should be JUST enough to know your test ran and passed and not ignored, 
 e.g. you didnt screw up).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5920) tweak junit4 output options for 'ant beast'

2014-09-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121275#comment-14121275
 ] 

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

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

Merged revision(s) 1622463 from lucene/dev/trunk:
LUCENE-5920: More elegant (groovy-like) task creation

 tweak junit4 output options for 'ant beast'
 ---

 Key: LUCENE-5920
 URL: https://issues.apache.org/jira/browse/LUCENE-5920
 Project: Lucene - Core
  Issue Type: Test
Reporter: Robert Muir
 Fix For: 5.0, 4.11

 Attachments: LUCENE-5920-silencer1.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920-silencer2.patch, 
 LUCENE-5920-silencer2.patch, LUCENE-5920-silencer2.patch, LUCENE-5920.patch, 
 LUCENE-5920.patch


 Currently, this outputs way too much, e.g. including all test output for 
 every passing run (because this is the behavior when -Dtestcase is set).
 Especially with tests.verbose, this is really annoying as you have output 
 from say 200 runs that you don't care about.
 I think ant beast should only show the interesting output for the failing run 
 and try to suppress unnecessary output as much as possible for passing ones 
 (it should be JUST enough to know your test ran and passed and not ignored, 
 e.g. you didnt screw up).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-5147) Support Block Join documents in DIH

2014-09-04 Thread Thomas Champagne (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14118098#comment-14118098
 ] 

Thomas Champagne edited comment on SOLR-5147 at 9/4/14 12:40 PM:
-

I have updated the patch.  There were only problems in the new unit test 
TestHierarchicalDocBuilder : 
* adding the field _root_ in the dataimport schema.
* the parent filter for the query is now a FixedBitSetCachingWrapperFilter.

You can apply this patch in the trunk. 

All unit tests about dih are OK after applying the patch.

If you want to test, you can add an attribute child at true in the entity tag 
in the data config file. The entities taggued with child will be added with the 
addChildDocument method.
For example :
{code:xml}
dataConfig
  dataSource type=JdbcDataSource /
  document
entity name=PARENT query=select * from PARENT
  field column=id /
  field column=desc /
  field column=type_s /
  entity child=true name=CHILD query=select * from CHILD where 
parent_id='${PARENT.id}'
field column=id /
field column=desc /
field column=type_s /
  /entity
/entity
  /document
/dataConfig
{code}


was (Author: lafeuil):
I have updated the patch.  There were only problems in the new unit test 
TestHierarchicalDocBuilder : 
* adding the field _root_ in the dataimport schema.
* the parent filter for the query is now a FixedBitSetCachingWrapperFilter.

You can apply this patch in the trunk. 

All unit tests about dih are OK after applying the patch.

If you want to test, you can add an attribute child at true in the entity tag 
in the data config file. The entities taggued with child will be added with the 
addChildDocument method.
For example :
{code:xml}
dataConfig
  dataSource type=JdbcDataSource /
  document
entity name=PARENT' query=select * from PARENT
  field column=id /
  field column=desc /
  field column=type_s /
  entity child=true name=CHILD query=select * from CHILD where 
parent_id='${PARENT.id}'
field column=id /
field column=desc /
field column=type_s /
  /entity
/entity
  /document
/dataConfig
{code}

 Support Block Join documents in DIH
 ---

 Key: SOLR-5147
 URL: https://issues.apache.org/jira/browse/SOLR-5147
 Project: Solr
  Issue Type: Sub-task
Reporter: Vadim Kirilchuk
 Fix For: 4.9, 5.0

 Attachments: SOLR-5147.patch


 DIH should be able to index hierarchical documents, i.e. it should be able to 
 work with SolrInputDocuments#addChildDocument.
 There was patch in SOLR-3076: 
 https://issues.apache.org/jira/secure/attachment/12576960/dih-3076.patch
 But it is not uptodate and far from being complete.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-6478) need docs / tests of the rules as far as collection names go

2014-09-04 Thread Grant Ingersoll (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-6478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121305#comment-14121305
]

Grant Ingersoll edited comment on SOLR-6478 at 9/4/14 12:44 PM:

I suspect some of the URLs, etc. get a little wonky when you allow things like
spaces, etc. in the names. Not sure if we should allow them or not.

was (Author: gsingers):
I suspect ome of the URLs, etc. get a little wonky when you allow things like
spaces, etc. in the names. Not sure if we should allow them or not.

need docs / tests of the rules as far as collection names go
--

Key: SOLR-6478
URL: https://issues.apache.org/jira/browse/SOLR-6478
Project: Solr
Issue Type: Improvement
Reporter: Hoss Man

historically, the rules for core names have been vague but implicitly
defined based on the rule that it had to be a valid directory path name - but
i don't know that we've ever documented anywhere what the rules are for a
collection name when dealing with the Collections API.
I haven't had a chance to try this, but i suspect that using the Collections
API you can create any collection name you want, and the zk/clusterstate.json
data will all be fine, and you'll then be able to request anything you want
from that collection as long as you properly URL escape it in your request
URLs ... but we should have a test that tries to do this, and document any
actual limitations that pop up and/or fix those limitations so we really can
have arbitrary collection names.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6478) need docs / tests of the rules as far as collection names go

2014-09-04 Thread Grant Ingersoll (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121305#comment-14121305
 ] 

Grant Ingersoll commented on SOLR-6478:
---

I suspect ome of the URLs, etc. get a little wonky when you allow things like 
spaces, etc. in the names.  Not sure if we should allow them or not.

 need docs / tests of the rules as far as collection names go
 --

 Key: SOLR-6478
 URL: https://issues.apache.org/jira/browse/SOLR-6478
 Project: Solr
  Issue Type: Improvement
Reporter: Hoss Man

 historically, the rules for core names have been vague but implicitly 
 defined based on the rule that it had to be a valid directory path name - but 
 i don't know that we've ever documented anywhere what the rules are for a 
 collection name when dealing with the Collections API.
 I haven't had a chance to try this, but i suspect that using the Collections 
 API you can create any collection name you want, and the zk/clusterstate.json 
 data will all be fine, and you'll then be able to request anything you want 
 from that collection as long as you properly URL escape it in your request 
 URLs ... but we should have a test that tries to do this, and document any 
 actual limitations that pop up and/or fix those limitations so we really can 
 have arbitrary collection names.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5895) Add per-segment and per-commit id to help replication

2014-09-04 Thread Michael McCandless (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-5895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121314#comment-14121314
]

Michael McCandless commented on LUCENE-5895:

Hmm, it depends on how merging works b/w primary replica? E.g. we could
merge only on primary and copy merged segments out. Yes, this is added
bandwidth, but then merging is also CPU / IO intensive, so saving that work for
the replicas may net/net be worthwhile. And copying out a merged segment to a
replica can be a lowish priority thing, e.g. it need not gate NRT reopen time
(just like how IW's merged segment warmer doesn't either).

But yeah if the replicas do their own merging, somehow with a merge policy
that's guaranteed to precisely match what the primary does (despite e.g.
ConcurrentMergeScheduler causing merges to complete in different orders), then
we would need to somehow set the IDs of the merged segments on the replicas to
match the corresponding merged segments on the primaries. Or, perhaps ... we
compute the ID of a merged segment by hashing the IDs of the N segments that
were merged ... hmm risky because if there were different deleted docs then the
IDs should differ, so maybe we hash on that too ... tricky.

Add per-segment and per-commit id to help replication
-

Key: LUCENE-5895
URL: https://issues.apache.org/jira/browse/LUCENE-5895
Project: Lucene - Core
Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 5.0, 4.11

Attachments: LUCENE-5895.patch, LUCENE-5895.patch

It would be useful if Lucene recorded a unique id for each segment written
and each commit point. This way, file-based replicators can use this to
know whether the segment/commit they are looking at on a source machine and
dest machine are in fact that same.
I know this would have been very useful when I was playing with NRT
replication (LUCENE-5438).

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-5147) Support Block Join documents in DIH

2014-09-04 Thread Thomas Champagne (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121321#comment-14121321
 ] 

Thomas Champagne commented on SOLR-5147:


No, it's not mandatorty to add a rootEntity=true to the root element because 
by default the entities falling under the document are root entities. 

About that is marked as required in the schema is required both in the Parent 
Doc and the Child Doc, the block join documents works like this. So, it is ok.

And about your last problem, I don't understand it. Give us an exemple. 

 Support Block Join documents in DIH
 ---

 Key: SOLR-5147
 URL: https://issues.apache.org/jira/browse/SOLR-5147
 Project: Solr
  Issue Type: Sub-task
Reporter: Vadim Kirilchuk
 Fix For: 4.9, 5.0

 Attachments: SOLR-5147.patch


 DIH should be able to index hierarchical documents, i.e. it should be able to 
 work with SolrInputDocuments#addChildDocument.
 There was patch in SOLR-3076: 
 https://issues.apache.org/jira/secure/attachment/12576960/dih-3076.patch
 But it is not uptodate and far from being complete.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-5922) DocValuesDocIdSet is not cacheable

2014-09-04 Thread Adrien Grand (JIRA)


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

Adrien Grand updated LUCENE-5922:
-
Attachment: LUCENE-5922.patch

Here is a patch.

 DocValuesDocIdSet is not cacheable
 --

 Key: LUCENE-5922
 URL: https://issues.apache.org/jira/browse/LUCENE-5922
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 4.10
Reporter: Adrien Grand
 Fix For: 4.11

 Attachments: LUCENE-5922.patch


 This DocIdSet claims it is cacheable although bad things could happen if it 
 was cached since it is not thread-safe and keeps handles to open files.
 The fix is simple, especially given that this doc id set is cheap to create. 
 But I'm wondering if there is a way we could protect ourselves from such bugs 
 in the future.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.8.0_20) - Build # 11043 - Failure!

2014-09-04 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/11043/
Java: 32bit/jdk1.8.0_20 -server -XX:+UseParallelGC

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

Error Message:
After invoking OVERSEERSTATUS, SplitShard task [2000] was still supposed to be 
in [running] but isn't.It is [completed]

Stack Trace:
java.lang.AssertionError: After invoking OVERSEERSTATUS, SplitShard task [2000] 
was still supposed to be in [running] but isn't.It is [completed]
at 
__randomizedtesting.SeedInfo.seed([664CC000CE992E97:E7AA4E18B9C64EAB]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.MultiThreadedOCPTest.testLongAndShortRunningParallelApiCalls(MultiThreadedOCPTest.java:253)
at 
org.apache.solr.cloud.MultiThreadedOCPTest.doTest(MultiThreadedOCPTest.java:75)
at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:871)
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)

[jira] [Commented] (LUCENE-5906) Use Files.delete instead of File.delete + made up exception


[ 
https://issues.apache.org/jira/browse/LUCENE-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121344#comment-14121344
 ] 

Uwe Schindler commented on LUCENE-5906:
---

For me Lucene tests worked in windows.

Solr failed one test:

{noformat}
   [junit4]   2 NOTE: reproduce with: ant test  
-Dtestcase=TestArbitraryIndexDir -Dtests.method=testLoadNewIndexDir 
-Dtests.seed=269DADB350875937 -Dtests.directory=NIOFSDirectory 
-Dtests.locale=ro_RO -Dtests.timezone=PST -Dtests.file.encoding=UTF-8
   [junit4] ERROR   1.55s J1 | TestArbitraryIndexDir.testLoadNewIndexDir 
   [junit4] Throwable #1: java.io.IOException: Could not remove the 
following files (in the order of attempts):
   [junit4]C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\solr\build\solr-core\test\J1\.\temp\solr.core.TestArbitraryIndexDir-269DADB350875937-001\tempDir-001\index_temp:
 C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\solr\build\solr-core\test\J1\.\temp\solr.core.TestArbitraryIndexDir-269DADB350875937-001\tempDir-001\index_temp
   [junit4]at 
__randomizedtesting.SeedInfo.seed([269DADB350875937:CFC7168BCE1EC99F]:0)
   [junit4]at org.apache.lucene.util.IOUtils.rm(IOUtils.java:315)
   [junit4]at 
org.apache.solr.core.TestArbitraryIndexDir.testLoadNewIndexDir(TestArbitraryIndexDir.java:135)
   [junit4]at java.lang.Thread.run(Thread.java:745)
{noformat}

 Use Files.delete instead of File.delete + made up exception
 ---

 Key: LUCENE-5906
 URL: https://issues.apache.org/jira/browse/LUCENE-5906
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-5906.patch, LUCENE-5906.patch, LUCENE-5906.patch


 We are on java7, if we cannot delete a file, this one returns a real 
 exception as to why.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5906) Use Files.delete instead of File.delete + made up exception


[ 
https://issues.apache.org/jira/browse/LUCENE-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121363#comment-14121363
 ] 

Uwe Schindler commented on LUCENE-5906:
---

This reproduces, it is not caused by virus scanner!

The problem here is two:
- the Exception message is broken
- the test is broken on windows (should reproduce on jenkins)

 Use Files.delete instead of File.delete + made up exception
 ---

 Key: LUCENE-5906
 URL: https://issues.apache.org/jira/browse/LUCENE-5906
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-5906.patch, LUCENE-5906.patch, LUCENE-5906.patch


 We are on java7, if we cannot delete a file, this one returns a real 
 exception as to why.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5906) Use Files.delete instead of File.delete + made up exception

2014-09-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121364#comment-14121364
 ] 

Robert Muir commented on LUCENE-5906:
-

Previously the test just ignored the return value from delete.

Maybe it doesn't need to delete at all. But i saw this newDir created as:
{code}
File newDir = new File(h.getCore().getDataDir() + index_temp);
{code}

So I was afraid to remove the delete() (and replaced it with a picky one), 
because i don't know if this directory is a child of one called from 
LuceneTestCase (which is guaranteed to be cleaned up correctly) or instead 
created in some arbitrary way.

 Use Files.delete instead of File.delete + made up exception
 ---

 Key: LUCENE-5906
 URL: https://issues.apache.org/jira/browse/LUCENE-5906
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-5906.patch, LUCENE-5906.patch, LUCENE-5906.patch


 We are on java7, if we cannot delete a file, this one returns a real 
 exception as to why.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-6479) ExtendedDismax does not recognize operators followed by a parenthesis without space

2014-09-04 Thread Pierre Salagnac (JIRA)

Pierre Salagnac created SOLR-6479:
-

 Summary: ExtendedDismax does not recognize operators followed by a 
parenthesis without space
 Key: SOLR-6479
 URL: https://issues.apache.org/jira/browse/SOLR-6479
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 4.9
 Environment: Java 7
Linux
Reporter: Pierre Salagnac
Priority: Minor


Before doing through the syntax parser, edismax does a pre-analysis of the 
query to applies some parameters, like whether lower case operators are 
recognized.

This basic analysis in {{splitIntoClauses()}} pseudo-tokenizes the query string 
on whitespaces. An operator directly followed by a parenthesis is not 
recognized because only one token is created.

{code}
foo AND (bar) - foo ; AND ; (bar)
foo AND(bar)  - foo ; AND(bar)
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6297) Distributed spellcheck with WordBreakSpellchecker can lose suggestions


[ 
https://issues.apache.org/jira/browse/SOLR-6297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121366#comment-14121366
 ] 

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

Commit 1622476 from jd...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1622476 ]

SOLR-6297: Fix for Distributed WordBreakSolrSpellChecker

 Distributed spellcheck with WordBreakSpellchecker can lose suggestions
 --

 Key: SOLR-6297
 URL: https://issues.apache.org/jira/browse/SOLR-6297
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.9
Reporter: Steve Molloy
 Attachments: SOLR-6297.patch, SOLR-6297.patch, SOLR-6297.patch, 
 SOLR-6297.patch


 When performing a spellcheck request in distributed environment with the 
 WordBreakSpellChecker configured, the shard response merging logic can lose 
 some suggestions. Basically, the merging logic ensures that all shards marked 
 the query as not being correctly spelled, which is good, but also expects all 
 shards to return some suggestions, which isn't necessarily the case. So if 
 shard 1 returns 10 suggestions but shard 2 returns none, the final result 
 will contain no suggestions because the term has suggestions from only 1 of 2 
 shards.
 This isn't the case with the DirectSolrSpellChecker which works properly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6297) Distributed spellcheck with WordBreakSpellchecker can lose suggestions

2014-09-04 Thread James Dyer (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121373#comment-14121373
 ] 

James Dyer commented on SOLR-6297:
--

Working on backport for 4.11 . 

cc: Steve Molloy - are you able to verify this trunk version fixes your 
particular problem?

 Distributed spellcheck with WordBreakSpellchecker can lose suggestions
 --

 Key: SOLR-6297
 URL: https://issues.apache.org/jira/browse/SOLR-6297
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.9
Reporter: Steve Molloy
 Attachments: SOLR-6297.patch, SOLR-6297.patch, SOLR-6297.patch, 
 SOLR-6297.patch


 When performing a spellcheck request in distributed environment with the 
 WordBreakSpellChecker configured, the shard response merging logic can lose 
 some suggestions. Basically, the merging logic ensures that all shards marked 
 the query as not being correctly spelled, which is good, but also expects all 
 shards to return some suggestions, which isn't necessarily the case. So if 
 shard 1 returns 10 suggestions but shard 2 returns none, the final result 
 will contain no suggestions because the term has suggestions from only 1 of 2 
 shards.
 This isn't the case with the DirectSolrSpellChecker which works properly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-5906) Use Files.delete instead of File.delete + made up exception


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

Robert Muir updated LUCENE-5906:

Attachment: LUCENE-5906.patch

I removed this delete (its unnecessary, if it wants to do it, should be in 
tearDown anyway, and test cleanup will take care correctly).

I also fixed exception messages for IOUtils.rm, thanks!

 Use Files.delete instead of File.delete + made up exception
 ---

 Key: LUCENE-5906
 URL: https://issues.apache.org/jira/browse/LUCENE-5906
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-5906.patch, LUCENE-5906.patch, LUCENE-5906.patch, 
 LUCENE-5906.patch


 We are on java7, if we cannot delete a file, this one returns a real 
 exception as to why.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5906) Use Files.delete instead of File.delete + made up exception


[ 
https://issues.apache.org/jira/browse/LUCENE-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121404#comment-14121404
 ] 

Uwe Schindler commented on LUCENE-5906:
---

New patch fails in datacorrumpterhandler:

{noformat}
   [junit4]   2 NOTE: reproduce with: ant test  
-Dtestcase=TestNonWritablePersistFile -Dtests.method=testNonWritablePersistFile 
-Dtests.seed=CA8991891E1876AB -Dtests.locale=mt -Dtests.timezone=Asia/Tokyo 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   0.55s J2 | 
TestNonWritablePersistFile.testNonWritablePersistFile 
   [junit4] Throwable #1: java.nio.file.AccessDeniedException: 
C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\solr\build\contrib\solr-dataimporthandler\test\J2\.\temp\solr.handler.dataimport.TestNonWritablePersistFile-CA8991891E1876AB-001\tempDir-001\collection1\conf\dataimport.properties
   [junit4]at 
__randomizedtesting.SeedInfo.seed([CA8991891E1876AB:7C810C466217C87E]:0)
   [junit4]at 
sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:83)
   [junit4]at 
sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
   [junit4]at 
sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
   [junit4]at 
sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
   [junit4]at 
sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
   [junit4]at java.nio.file.Files.delete(Files.java:1079)
   [junit4]at 
org.apache.solr.handler.dataimport.TestNonWritablePersistFile.testNonWritablePersistFile(TestNonWritablePersistFile.java:96)
   [junit4]at java.lang.Thread.run(Thread.java:745)
{noformat}

 Use Files.delete instead of File.delete + made up exception
 ---

 Key: LUCENE-5906
 URL: https://issues.apache.org/jira/browse/LUCENE-5906
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-5906.patch, LUCENE-5906.patch, LUCENE-5906.patch, 
 LUCENE-5906.patch


 We are on java7, if we cannot delete a file, this one returns a real 
 exception as to why.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-5906) Use Files.delete instead of File.delete + made up exception


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

Robert Muir updated LUCENE-5906:

Attachment: LUCENE-5906.patch

Updated patch, same issue as the other one. Thanks Uwe

 Use Files.delete instead of File.delete + made up exception
 ---

 Key: LUCENE-5906
 URL: https://issues.apache.org/jira/browse/LUCENE-5906
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-5906.patch, LUCENE-5906.patch, LUCENE-5906.patch, 
 LUCENE-5906.patch, LUCENE-5906.patch


 We are on java7, if we cannot delete a file, this one returns a real 
 exception as to why.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-5961) Solr gets crazy on /overseer/queue state change

2014-09-04 Thread Ugo Matrangolo (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121411#comment-14121411
 ] 

Ugo Matrangolo commented on SOLR-5961:
--

Hi,

we got same behaviour that caused major outage. After a rolling restart of our 
production zk cluster the /overseer/queue started to be spammed by events and 
the Overseer was looping on the following:

2014-08-28 22:43:06,753 [main-EventThread] INFO  
org.apache.solr.cloud.DistributedQueue  - LatchChildWatcher fired on path: 
/overseer/queue state: SyncConnected type NodeChildrenChanged
2014-08-28 22:43:06,820 [Thread-125] INFO  org.apache.solr.cloud.Overseer  - 
Update state numShards=3 message={
  operation:state,
  state:recovering,
  base_url:http://{ip}:{port};,
  core:warehouse-skus_shard2_replica2,
  roles:null,
  node_name:{ip}:{port}_,
  shard:shard2,
  collection:warehouse-skus,
  numShards:3,
  core_node_name:core_node4}

The fix was to:
1. Shutdown completely the cluster
2. Using zkCli we rmr-ed all the /queue(s) under the /overseer
3. Restarted

Solr started fine after that as nothing has happened.

The outage was caused by clusterstate.json being in an inconsistent state (most 
of the nodes were incorrectly marked as down) with no chance to get things 
right given that the Overseer was too busy processing the spammed queues (more 
than 13k+ msgs in there) to fix the clusterstate.json with the latest situation.

 Solr gets crazy on /overseer/queue state change
 ---

 Key: SOLR-5961
 URL: https://issues.apache.org/jira/browse/SOLR-5961
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.7.1
 Environment: CentOS, 1 shard - 3 replicas, ZK cluster with 3 nodes 
 (separate machines)
Reporter: Maxim Novikov
Priority: Critical

 No idea how to reproduce it, but sometimes Solr stars littering the log with 
 the following messages:
 419158 [localhost-startStop-1-EventThread] INFO  
 org.apache.solr.cloud.DistributedQueue  ? LatchChildWatcher fired on path: 
 /overseer/queue state: SyncConnected type NodeChildrenChanged
 419190 [Thread-3] INFO  org.apache.solr.cloud.Overseer  ? Update state 
 numShards=1 message={
   operation:state,
   state:recovering,
   base_url:http://${IP_ADDRESS}/solr;,
   core:${CORE_NAME},
   roles:null,
   node_name:${NODE_NAME}_solr,
   shard:shard1,
   collection:${COLLECTION_NAME},
   numShards:1,
   core_node_name:core_node2}
 It continues spamming these messages with no delay and the restarting of all 
 the nodes does not help. I have even tried to stop all the nodes in the 
 cluster first, but then when I start one, the behavior doesn't change, it 
 gets crazy nuts with this  /overseer/queue state again.
 PS The only way to handle this was to stop everything, manually clean up all 
 the data in ZooKeeper related to Solr, and then rebuild everything from 
 scratch. As you should understand, it is kinda unbearable in the production 
 environment.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-6479) ExtendedDismax does not recognize operators followed by a parenthesis without space

2014-09-04 Thread Pierre Salagnac (JIRA)


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

Pierre Salagnac updated SOLR-6479:
--
Attachment: SOLR-6479.patch

Proposing a patch for this. All feedback welcome.

 ExtendedDismax does not recognize operators followed by a parenthesis without 
 space
 ---

 Key: SOLR-6479
 URL: https://issues.apache.org/jira/browse/SOLR-6479
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 4.9
 Environment: Java 7
 Linux
Reporter: Pierre Salagnac
Priority: Minor
  Labels: patch
 Attachments: SOLR-6479.patch


 Before doing through the syntax parser, edismax does a pre-analysis of the 
 query to applies some parameters, like whether lower case operators are 
 recognized.
 This basic analysis in {{splitIntoClauses()}} pseudo-tokenizes the query 
 string on whitespaces. An operator directly followed by a parenthesis is not 
 recognized because only one token is created.
 {code}
 foo AND (bar) - foo ; AND ; (bar)
 foo AND(bar)  - foo ; AND(bar)
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-6480) Too Many Open files trying to ask a replica to recover

2014-09-04 Thread Ugo Matrangolo (JIRA)

Ugo Matrangolo created SOLR-6480:


 Summary: Too Many Open files trying to ask a replica to recover
 Key: SOLR-6480
 URL: https://issues.apache.org/jira/browse/SOLR-6480
 Project: Solr
  Issue Type: Bug
Reporter: Ugo Matrangolo


After the DistributedUpdateProcessor tries to ask multiple times a replica to 
recover it eventually starts to fail with the following error:

{code}
2014-08-28 22:42:46,285 [updateExecutor-1-thread-2334] ERROR 
org.apache.solr.update.processor.DistributedUpdateProcessor  - 
http://10.140.4.246:9765: Could not tell a replica to 
recover:org.apache.solr.client.solrj.SolrServerException: IOException occured 
when talking to server at: http://10.140.4.246:9765
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:507)
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:199)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor$1.run(DistributedUpdateProcessor.java:685)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.net.SocketException: Too many open files
at java.net.Socket.createImpl(Socket.java:397)
at java.net.Socket.getImpl(Socket.java:460)
at java.net.Socket.setSoTimeout(Socket.java:1017)
at 
org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:116)
at 
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:178)
at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
at 
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:610)
at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:445)
at 
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57)
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:395)
... 5 more
{code}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-6480) Too Many Open files trying to ask a replica to recover

2014-09-04 Thread Ugo Matrangolo (JIRA)


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

Ugo Matrangolo updated SOLR-6480:
-
Affects Version/s: 4.7.2

 Too Many Open files trying to ask a replica to recover
 --

 Key: SOLR-6480
 URL: https://issues.apache.org/jira/browse/SOLR-6480
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.7.2
Reporter: Ugo Matrangolo

 After the DistributedUpdateProcessor tries to ask multiple times a replica to 
 recover it eventually starts to fail with the following error:
 {code}
 2014-08-28 22:42:46,285 [updateExecutor-1-thread-2334] ERROR 
 org.apache.solr.update.processor.DistributedUpdateProcessor  - 
 http://10.140.4.246:9765: Could not tell a replica to 
 recover:org.apache.solr.client.solrj.SolrServerException: IOException occured 
 when talking to server at: http://10.140.4.246:9765
 at 
 org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:507)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:199)
 at 
 org.apache.solr.update.processor.DistributedUpdateProcessor$1.run(DistributedUpdateProcessor.java:685)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)
 Caused by: java.net.SocketException: Too many open files
 at java.net.Socket.createImpl(Socket.java:397)
 at java.net.Socket.getImpl(Socket.java:460)
 at java.net.Socket.setSoTimeout(Socket.java:1017)
 at 
 org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:116)
 at 
 org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:178)
 at 
 org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
 at 
 org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:610)
 at 
 org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:445)
 at 
 org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863)
 at 
 org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
 at 
 org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106)
 at 
 org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:395)
 ... 5 more
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [jira] [Commented] (LUCENE-5906) Use Files.delete instead of File.delete + made up exception

FYI, I'm working on an improvement (SOLR-5322) that adds a number of
tests that explicitly set a directory or file to r/o. As far as I know
they properly set the perms back to r/w before they're done and they
pass on OS X (after failing before I reset the perms). But just in
case  you see some weirdness after I check it in on the windows
machines you'll know who to blame.

Erick

On Thu, Sep 4, 2014 at 8:09 AM, Uwe Schindler (JIRA) j...@apache.org wrote:

 [ 
 https://issues.apache.org/jira/browse/LUCENE-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121447#comment-14121447
  ]

 Uwe Schindler commented on LUCENE-5906:
 ---

 Hi the patch did not pass, too. The problem here is simple: the file was made 
 read-only, so cannot be deleted. You need to add {{f.setWritable(true);}} at 
 the end of test.

 Otherwise it passes on windows, I ran the whole test suite ignoring failures 
 and this was the only one broken.

 Use Files.delete instead of File.delete + made up exception
 ---

 Key: LUCENE-5906
 URL: https://issues.apache.org/jira/browse/LUCENE-5906
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-5906.patch, LUCENE-5906.patch, 
 LUCENE-5906.patch, LUCENE-5906.patch, LUCENE-5906.patch


 We are on java7, if we cannot delete a file, this one returns a real 
 exception as to why.



 --
 This message was sent by Atlassian JIRA
 (v6.3.4#6332)

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


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

RE: [jira] [Commented] (LUCENE-5906) Use Files.delete instead of File.delete + made up exception

2014-09-04 Thread Uwe Schindler

Hi Erick,

it would be good, if you use the new Java 7 methods to set/unset perms. Because 
those fail hardly with exceptions. So in future we should deprecate/disallow 
the whole broken java.io.File class.

So use java.io.nio.file package to do this stuff - we just did not fix this for 
DIH, but its non-ideal how it's currently done, because you get no good 
exceptions if something with setting perms is not working!

Uwe

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


 -Original Message-
 From: Erick Erickson [mailto:erickerick...@gmail.com]
 Sent: Thursday, September 04, 2014 5:13 PM
 To: dev@lucene.apache.org
 Subject: Re: [jira] [Commented] (LUCENE-5906) Use Files.delete instead of
 File.delete + made up exception
 
 FYI, I'm working on an improvement (SOLR-5322) that adds a number of tests
 that explicitly set a directory or file to r/o. As far as I know they 
 properly set
 the perms back to r/w before they're done and they pass on OS X (after
 failing before I reset the perms). But just in case  you see some weirdness
 after I check it in on the windows machines you'll know who to blame.
 
 Erick
 
 On Thu, Sep 4, 2014 at 8:09 AM, Uwe Schindler (JIRA) j...@apache.org
 wrote:
 
  [
  https://issues.apache.org/jira/browse/LUCENE-5906?page=com.atlassian.j
  ira.plugin.system.issuetabpanels:comment-
 tabpanelfocusedCommentId=141
  21447#comment-14121447 ]
 
  Uwe Schindler commented on LUCENE-5906:
  ---
 
  Hi the patch did not pass, too. The problem here is simple: the file was
 made read-only, so cannot be deleted. You need to add
 {{f.setWritable(true);}} at the end of test.
 
  Otherwise it passes on windows, I ran the whole test suite ignoring failures
 and this was the only one broken.
 
  Use Files.delete instead of File.delete + made up exception
  ---
 
  Key: LUCENE-5906
  URL: https://issues.apache.org/jira/browse/LUCENE-5906
  Project: Lucene - Core
   Issue Type: Bug
 Reporter: Robert Muir
  Attachments: LUCENE-5906.patch, LUCENE-5906.patch,
  LUCENE-5906.patch, LUCENE-5906.patch, LUCENE-5906.patch
 
 
  We are on java7, if we cannot delete a file, this one returns a real
 exception as to why.
 
 
 
  --
  This message was sent by Atlassian JIRA
  (v6.3.4#6332)
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
  additional commands, e-mail: dev-h...@lucene.apache.org
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
 commands, e-mail: dev-h...@lucene.apache.org


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

[jira] [Commented] (LUCENE-5906) Use Files.delete instead of File.delete + made up exception


[ 
https://issues.apache.org/jira/browse/LUCENE-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121456#comment-14121456
 ] 

Robert Muir commented on LUCENE-5906:
-

Thanks for debugging this Uwe! I'll add setWriteable and commit.

 Use Files.delete instead of File.delete + made up exception
 ---

 Key: LUCENE-5906
 URL: https://issues.apache.org/jira/browse/LUCENE-5906
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-5906.patch, LUCENE-5906.patch, LUCENE-5906.patch, 
 LUCENE-5906.patch, LUCENE-5906.patch


 We are on java7, if we cannot delete a file, this one returns a real 
 exception as to why.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5914) More options for stored fields compression

2014-09-04 Thread Erick Erickson (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121459#comment-14121459
 ] 

Erick Erickson commented on LUCENE-5914:


Here's an example of what I was remembering. I haven't verified, could be 
totally unrelated to compression. The use-case seems to be very large documents 
(up to 50M) indexing time going from 3 hours to 3 days. There may very well be 
stuff going on here that is unrelated, but...

Skipping the discussion about what the point of 50M docs is ;)

http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201409.mbox/%3C27589A9FF2E7CC42B56140FD01CEC3A2EF794C56%40clrc-nt-mbx01p.corp.org.local%3E

 More options for stored fields compression
 --

 Key: LUCENE-5914
 URL: https://issues.apache.org/jira/browse/LUCENE-5914
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
 Fix For: 4.11

 Attachments: LUCENE-5914.patch


 Since we added codec-level compression in Lucene 4.1 I think I got about the 
 same amount of users complaining that compression was too aggressive and that 
 compression was too light.
 I think it is due to the fact that we have users that are doing very 
 different things with Lucene. For example if you have a small index that fits 
 in the filesystem cache (or is close to), then you might never pay for actual 
 disk seeks and in such a case the fact that the current stored fields format 
 needs to over-decompress data can sensibly slow search down on cheap queries.
 On the other hand, it is more and more common to use Lucene for things like 
 log analytics, and in that case you have huge amounts of data for which you 
 don't care much about stored fields performance. However it is very 
 frustrating to notice that the data that you store takes several times less 
 space when you gzip it compared to your index although Lucene claims to 
 compress stored fields.
 For that reason, I think it would be nice to have some kind of options that 
 would allow to trade speed for compression in the default codec.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [jira] [Commented] (LUCENE-5906) Use Files.delete instead of File.delete + made up exception

Thanks Uwe! I'll make it so.

Erick

On Thu, Sep 4, 2014 at 8:27 AM, Robert Muir (JIRA) j...@apache.org wrote:

 [ 
 https://issues.apache.org/jira/browse/LUCENE-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121456#comment-14121456
  ]

 Robert Muir commented on LUCENE-5906:
 -

 Thanks for debugging this Uwe! I'll add setWriteable and commit.

 Use Files.delete instead of File.delete + made up exception
 ---

 Key: LUCENE-5906
 URL: https://issues.apache.org/jira/browse/LUCENE-5906
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-5906.patch, LUCENE-5906.patch, 
 LUCENE-5906.patch, LUCENE-5906.patch, LUCENE-5906.patch


 We are on java7, if we cannot delete a file, this one returns a real 
 exception as to why.



 --
 This message was sent by Atlassian JIRA
 (v6.3.4#6332)

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


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

[jira] [Updated] (SOLR-6266) Couchbase plug-in for Solr


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

Joel Bernstein updated SOLR-6266:
-
Description: 
It would be great users could connect Couchbase and Solr so that updates to 
Couchbase can automatically flow to Solr. Couchbase provide some very nice 
API's which allow applications mimic the behavior of a Couchbase server so that 
it can recieve update via the normal cross data center replication (XDCR).

Once possible design for this it to create a CouchbaseUpdateHandler that 
extends the DirectUpdateHandler2. This new handler would embed the couchbase 
api's and listen for incoming updates from couchbase, then marshal the 
couchbase updates to Solr updates and call the DirectUpdateHandler methods 
directly with the update requests.

  was:
Can solr listen for updates on couchbase buckets and pull the recent changes 
into solr index. 

Something similar to elastic search couchbase plugin 
http://docs.couchbase.com/couchbase-elastic-search/

Also in enterprise solr world companies have tried plugins which can pull 
recent updates from cassandra and HBase. We need to develop such functionality 
in opensource solr.


 Couchbase plug-in for Solr
 --

 Key: SOLR-6266
 URL: https://issues.apache.org/jira/browse/SOLR-6266
 Project: Solr
  Issue Type: New Feature
Reporter: Varun
Assignee: Joel Bernstein

 It would be great users could connect Couchbase and Solr so that updates to 
 Couchbase can automatically flow to Solr. Couchbase provide some very nice 
 API's which allow applications mimic the behavior of a Couchbase server so 
 that it can recieve update via the normal cross data center replication 
 (XDCR).
 Once possible design for this it to create a CouchbaseUpdateHandler that 
 extends the DirectUpdateHandler2. This new handler would embed the couchbase 
 api's and listen for incoming updates from couchbase, then marshal the 
 couchbase updates to Solr updates and call the DirectUpdateHandler methods 
 directly with the update requests.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-6266) Couchbase plug-in for Solr


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

Joel Bernstein updated SOLR-6266:
-
Description: 
It would be great if users could connect Couchbase and Solr so that updates to 
Couchbase can automatically flow to Solr. Couchbase provide some very nice 
API's which allow applications mimic the behavior of a Couchbase server so that 
it can recieve update via the normal cross data center replication (XDCR).

Once possible design for this it to create a CouchbaseUpdateHandler that 
extends the DirectUpdateHandler2. This new handler would embed the couchbase 
api's and listen for incoming updates from couchbase, then marshal the 
couchbase updates to Solr updates and call the DirectUpdateHandler methods 
directly with the update requests.

  was:
It would be great users could connect Couchbase and Solr so that updates to 
Couchbase can automatically flow to Solr. Couchbase provide some very nice 
API's which allow applications mimic the behavior of a Couchbase server so that 
it can recieve update via the normal cross data center replication (XDCR).

Once possible design for this it to create a CouchbaseUpdateHandler that 
extends the DirectUpdateHandler2. This new handler would embed the couchbase 
api's and listen for incoming updates from couchbase, then marshal the 
couchbase updates to Solr updates and call the DirectUpdateHandler methods 
directly with the update requests.


 Couchbase plug-in for Solr
 --

 Key: SOLR-6266
 URL: https://issues.apache.org/jira/browse/SOLR-6266
 Project: Solr
  Issue Type: New Feature
Reporter: Varun
Assignee: Joel Bernstein

 It would be great if users could connect Couchbase and Solr so that updates 
 to Couchbase can automatically flow to Solr. Couchbase provide some very nice 
 API's which allow applications mimic the behavior of a Couchbase server so 
 that it can recieve update via the normal cross data center replication 
 (XDCR).
 Once possible design for this it to create a CouchbaseUpdateHandler that 
 extends the DirectUpdateHandler2. This new handler would embed the couchbase 
 api's and listen for incoming updates from couchbase, then marshal the 
 couchbase updates to Solr updates and call the DirectUpdateHandler methods 
 directly with the update requests.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-6266) Couchbase plug-in for Solr


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

Joel Bernstein updated SOLR-6266:
-
Description: 
It would be great if users could connect Couchbase and Solr so that updates to 
Couchbase can automatically flow to Solr. Couchbase provides some very nice 
API's which allow applications mimic the behavior of a Couchbase server so that 
it can recieve update via the normal cross data center replication (XDCR).

Once possible design for this it to create a CouchbaseUpdateHandler that 
extends the DirectUpdateHandler2. This new handler would embed the couchbase 
api's and listen for incoming updates from couchbase, then marshal the 
couchbase updates to Solr updates and call the DirectUpdateHandler methods 
directly with the update requests.

  was:
It would be great if users could connect Couchbase and Solr so that updates to 
Couchbase can automatically flow to Solr. Couchbase provide some very nice 
API's which allow applications mimic the behavior of a Couchbase server so that 
it can recieve update via the normal cross data center replication (XDCR).

Once possible design for this it to create a CouchbaseUpdateHandler that 
extends the DirectUpdateHandler2. This new handler would embed the couchbase 
api's and listen for incoming updates from couchbase, then marshal the 
couchbase updates to Solr updates and call the DirectUpdateHandler methods 
directly with the update requests.


 Couchbase plug-in for Solr
 --

 Key: SOLR-6266
 URL: https://issues.apache.org/jira/browse/SOLR-6266
 Project: Solr
  Issue Type: New Feature
Reporter: Varun
Assignee: Joel Bernstein

 It would be great if users could connect Couchbase and Solr so that updates 
 to Couchbase can automatically flow to Solr. Couchbase provides some very 
 nice API's which allow applications mimic the behavior of a Couchbase server 
 so that it can recieve update via the normal cross data center replication 
 (XDCR).
 Once possible design for this it to create a CouchbaseUpdateHandler that 
 extends the DirectUpdateHandler2. This new handler would embed the couchbase 
 api's and listen for incoming updates from couchbase, then marshal the 
 couchbase updates to Solr updates and call the DirectUpdateHandler methods 
 directly with the update requests.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-6266) Couchbase plug-in for Solr


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

Joel Bernstein updated SOLR-6266:
-
Description: 
It would be great if users could connect Couchbase and Solr so that updates to 
Couchbase can automatically flow to Solr. Couchbase provides some very nice 
API's which allow applications to mimic the behavior of a Couchbase server so 
that it can receive updates via Couchbase's normal cross data center 
replication (XDCR).

One possible design for this is to create a CouchbaseUpdateHandler that extends 
the DirectUpdateHandler2. This new handler would embed the couchbase api's and 
listen for incoming updates from couchbase, then marshal the couchbase updates 
to Solr updates and call the DirectUpdateHandler2 methods directly with the 
update requests.

  was:
It would be great if users could connect Couchbase and Solr so that updates to 
Couchbase can automatically flow to Solr. Couchbase provides some very nice 
API's which allow applications to mimic the behavior of a Couchbase server so 
that it can receive updates via the normal cross data center replication (XDCR).

One possible design for this is to create a CouchbaseUpdateHandler that extends 
the DirectUpdateHandler2. This new handler would embed the couchbase api's and 
listen for incoming updates from couchbase, then marshal the couchbase updates 
to Solr updates and call the DirectUpdateHandler2 methods directly with the 
update requests.


 Couchbase plug-in for Solr
 --

 Key: SOLR-6266
 URL: https://issues.apache.org/jira/browse/SOLR-6266
 Project: Solr
  Issue Type: New Feature
Reporter: Varun
Assignee: Joel Bernstein

 It would be great if users could connect Couchbase and Solr so that updates 
 to Couchbase can automatically flow to Solr. Couchbase provides some very 
 nice API's which allow applications to mimic the behavior of a Couchbase 
 server so that it can receive updates via Couchbase's normal cross data 
 center replication (XDCR).
 One possible design for this is to create a CouchbaseUpdateHandler that 
 extends the DirectUpdateHandler2. This new handler would embed the couchbase 
 api's and listen for incoming updates from couchbase, then marshal the 
 couchbase updates to Solr updates and call the DirectUpdateHandler2 methods 
 directly with the update requests.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-6266) Couchbase plug-in for Solr

2014-09-04 Thread ASF subversion and git services (JIRA)


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

Joel Bernstein updated SOLR-6266:
-
Description: 
It would be great if users could connect Couchbase and Solr so that updates to 
Couchbase can automatically flow to Solr. Couchbase provides some very nice 
API's which allow applications to mimic the behavior of a Couchbase server so 
that it can receive updates via the normal cross data center replication (XDCR).

One possible design for this is to create a CouchbaseUpdateHandler that extends 
the DirectUpdateHandler2. This new handler would embed the couchbase api's and 
listen for incoming updates from couchbase, then marshal the couchbase updates 
to Solr updates and call the DirectUpdateHandler2 methods directly with the 
update requests.

  was:
It would be great if users could connect Couchbase and Solr so that updates to 
Couchbase can automatically flow to Solr. Couchbase provides some very nice 
API's which allow applications mimic the behavior of a Couchbase server so that 
it can recieve update via the normal cross data center replication (XDCR).

Once possible design for this it to create a CouchbaseUpdateHandler that 
extends the DirectUpdateHandler2. This new handler would embed the couchbase 
api's and listen for incoming updates from couchbase, then marshal the 
couchbase updates to Solr updates and call the DirectUpdateHandler methods 
directly with the update requests.


 Couchbase plug-in for Solr
 --

 Key: SOLR-6266
 URL: https://issues.apache.org/jira/browse/SOLR-6266
 Project: Solr
  Issue Type: New Feature
Reporter: Varun
Assignee: Joel Bernstein

 It would be great if users could connect Couchbase and Solr so that updates 
 to Couchbase can automatically flow to Solr. Couchbase provides some very 
 nice API's which allow applications to mimic the behavior of a Couchbase 
 server so that it can receive updates via the normal cross data center 
 replication (XDCR).
 One possible design for this is to create a CouchbaseUpdateHandler that 
 extends the DirectUpdateHandler2. This new handler would embed the couchbase 
 api's and listen for incoming updates from couchbase, then marshal the 
 couchbase updates to Solr updates and call the DirectUpdateHandler2 methods 
 directly with the update requests.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5906) Use Files.delete instead of File.delete + made up exception


[ 
https://issues.apache.org/jira/browse/LUCENE-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121491#comment-14121491
 ] 

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

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

LUCENE-5906: Use Files.delete everywhere instead of File.delete

 Use Files.delete instead of File.delete + made up exception
 ---

 Key: LUCENE-5906
 URL: https://issues.apache.org/jira/browse/LUCENE-5906
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-5906.patch, LUCENE-5906.patch, LUCENE-5906.patch, 
 LUCENE-5906.patch, LUCENE-5906.patch


 We are on java7, if we cannot delete a file, this one returns a real 
 exception as to why.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [jira] [Commented] (LUCENE-5906) Use Files.delete instead of File.delete + made up exception

Wait. A quick look at the nio.files.Files class and...

In the brave new world here are we requiring that we test first to see
what the filesystem is? Because there's Posix and Dos varieties that
seem to be invoked separately. I don't see anywhere else in the code
base where we do this, am I the first or am I just dense?

On Thu, Sep 4, 2014 at 8:56 AM, ASF subversion and git services (JIRA)
j...@apache.org wrote:

 [ 
 https://issues.apache.org/jira/browse/LUCENE-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121491#comment-14121491
  ]

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

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

 LUCENE-5906: Use Files.delete everywhere instead of File.delete

 Use Files.delete instead of File.delete + made up exception
 ---

 Key: LUCENE-5906
 URL: https://issues.apache.org/jira/browse/LUCENE-5906
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-5906.patch, LUCENE-5906.patch, 
 LUCENE-5906.patch, LUCENE-5906.patch, LUCENE-5906.patch


 We are on java7, if we cannot delete a file, this one returns a real 
 exception as to why.



 --
 This message was sent by Atlassian JIRA
 (v6.3.4#6332)

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


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

Re: NearSpansOrdered semantics

2014-09-04 Thread Paul Elschot

By the way, in case you need more complex positional relations between fields, 
have a look at LUCENE-5627 .
A spanwithinquery is also used in the test code there as an unordered spannear 
with 2 arguments and distance -1.

Regards, 
Paul Elschot

On 3 september 2014 20:23:46 CEST, Shai Erera ser...@gmail.com wrote:
Thanks Hoss, this is very useful information, especially
FieldMaskingSpanQuery :).

So according to those issues, it seems others also think that end1 =
end2
is also a correct behavior of SNQ (in case ordered=true, and
start1==start2). Was there a reason these issues were not resolved
(e.g.
LUCENE-3120)? I'm asking if there was additional discussion where
people
raised objections against this, or was it just a matter of lack of
time/focus?

Shai


On Wed, Sep 3, 2014 at 8:47 PM, Chris Hostetter
hossman_luc...@fucit.org
wrote:

 : I then implemented a variation of a span query which I call
 SpanWithinQuery
 : which allows me to search for fox WITHIN nickname. The way it's
 : implemented is a SpanNearQuery on annot:nick and annot:/nick, and
 whenever
 : a match is found for 'fox', it makes sure that the position falls
within
 : the range of the nick annotation. Quite simple.

 FWIW: i think what you are describing is just a special case of
 FieldMaskingSpanQuery, might save you some custom code -- but that's
a
 tangent.

 : If you forget about all the preface I wrote above, I have a basic
 question
 : about the semantics of SNQ. I tried a simple case -- SNQ(fox,
fox)
 and
 : I get 0 results. Is this a bug in SNQ itself, or it's not built to
find
 : spans that are identical in their start/end positions, and I should
use
 : another variant of SpanQuery?

 I'm not lookin at the code, and i'ts been a long while since i
thouht
 about phrases/spans in depth, but i seem to recall this being a known
 aspect of the behavior ... similar to how PhraseQuery behaves i
think?

 since you have ordered=true then the 2nd span must come *after* the
 first span, and after is defined based on the end position of hte
spans
 (aparently?)

 You'll find a couple issues in jira (both closed and open) discussing
what
 the right behavior of SpanNearQuery should be.  Some particularly
 on-point issues based on a quick skim...

 https://issues.apache.org/jira/browse/LUCENE-3120
 https://issues.apache.org/jira/browse/LUCENE-3371
 https://issues.apache.org/jira/browse/LUCENE-3229


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

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

Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b26) - Build # 11170 - Failure!

2014-09-04 Thread Chris Hostetter


: BTW, Uwe, how come the reply-to for these failures is
: jenk...@thetaphi.de?  It almost bit me ... (i.e. I must remember to do
: reply all not just reply).

Are you sure that's not a quirk of your client?

 
0) the normal Reply-To 'list' header is added by ezmlm (documented) 

1) as recent committer the mail was CC'ed directly to you by jenkins 
(observed)

2) you use gmail as your MTA (suspected)

3) you recieved 2 copies of the email, one direct from jenkins and one via 
the mailing list (implied by #1)

4) gmail ignores dup messages, even if they've been modified by a mailing 
list and/or you sent the original message (documented)

5) gmail got the direct mail first, which didn't have the Reply-To set by 
the list. (conclusion drawn from #3 + #4)



: Mike McCandless
: 
: http://blog.mikemccandless.com
: 
: On Wed, Sep 3, 2014 at 2:11 PM, Policeman Jenkins Server
: jenk...@thetaphi.de wrote:
:  Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11170/
:  Java: 64bit/jdk1.9.0-ea-b26 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC
: 
:  1 tests failed.
:  REGRESSION:  
org.apache.lucene.replicator.IndexReplicationClientTest.testConsistencyOnExceptions
: 
:  Error Message:
:  _2.fdt
: 
:  Stack Trace:
:  java.io.FileNotFoundException: _2.fdt
:  at 
org.apache.lucene.store.RAMDirectory.fileLength(RAMDirectory.java:136)
:  at 
org.apache.lucene.store.NRTCachingDirectory.fileLength(NRTCachingDirectory.java:137)
:  at 
org.apache.lucene.store.MockDirectoryWrapper.fileLength(MockDirectoryWrapper.java:936)
:  at 
org.apache.lucene.index.SegmentCommitInfo.sizeInBytes(SegmentCommitInfo.java:217)
:  at 
org.apache.lucene.index.CheckIndex.checkIndex(CheckIndex.java:546)
:  at org.apache.lucene.util.TestUtil.checkIndex(TestUtil.java:207)
:  at 
org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:730)
:  at org.apache.lucene.util.IOUtils.close(IOUtils.java:77)
:  at 
org.apache.lucene.replicator.IndexReplicationClientTest.tearDown(IndexReplicationClientTest.java:154)
:  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:484)
:  at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
:  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:885)
:  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 
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

Re: [jira] [Commented] (LUCENE-5906) Use Files.delete instead of File.delete + made up exception

2014-09-04 Thread Robert Muir

Erick, I dont think you looked at the commit or patch. There is no
such thing for Files.delete.

So maybe you are discussing something unrelated to the issue (i
recommend a separate thread).

On Thu, Sep 4, 2014 at 12:00 PM, Erick Erickson erickerick...@gmail.com wrote:
 Wait. A quick look at the nio.files.Files class and...

 In the brave new world here are we requiring that we test first to see
 what the filesystem is? Because there's Posix and Dos varieties that
 seem to be invoked separately. I don't see anywhere else in the code
 base where we do this, am I the first or am I just dense?

 On Thu, Sep 4, 2014 at 8:56 AM, ASF subversion and git services (JIRA)
 j...@apache.org wrote:

 [ 
 https://issues.apache.org/jira/browse/LUCENE-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121491#comment-14121491
  ]

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

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

 LUCENE-5906: Use Files.delete everywhere instead of File.delete

 Use Files.delete instead of File.delete + made up exception
 ---

 Key: LUCENE-5906
 URL: https://issues.apache.org/jira/browse/LUCENE-5906
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-5906.patch, LUCENE-5906.patch, 
 LUCENE-5906.patch, LUCENE-5906.patch, LUCENE-5906.patch


 We are on java7, if we cannot delete a file, this one returns a real 
 exception as to why.



 --
 This message was sent by Atlassian JIRA
 (v6.3.4#6332)

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


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


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

[jira] [Updated] (SOLR-6266) Couchbase plug-in for Solr

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

Joel Bernstein updated SOLR-6266:
-
Description:
It would be great if users could connect Couchbase and Solr so that updates to
Couchbase can automatically flow to Solr. Couchbase provides some very nice
API's which allow applications to mimic the behavior of a Couchbase server so
that it can receive updates via Couchbase's normal cross data center
replication (XDCR).

One possible design for this is to create a CouchbaseLoader that extends
ContentStreamLoader. This new loader would embed the couchbase api's that
listen for incoming updates from couchbase, then marshal the couchbase updates
to Solr updates.

was:
It would be great if users could connect Couchbase and Solr so that updates to
Couchbase can automatically flow to Solr. Couchbase provides some very nice
API's which allow applications to mimic the behavior of a Couchbase server so
that it can receive updates via Couchbase's normal cross data center
replication (XDCR).

One possible design for this is to create a CouchbaseUpdateHandler that extends
the DirectUpdateHandler2. This new handler would embed the couchbase api's and
listen for incoming updates from couchbase, then marshal the couchbase updates
to Solr updates and call the DirectUpdateHandler2 methods directly with the
update requests.

Couchbase plug-in for Solr
--

Key: SOLR-6266
URL: https://issues.apache.org/jira/browse/SOLR-6266
Project: Solr
Issue Type: New Feature
Reporter: Varun
Assignee: Joel Bernstein

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-6266) Couchbase plug-in for Solr

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

Couchbase plug-in for Solr
--

Key: SOLR-6266
URL: https://issues.apache.org/jira/browse/SOLR-6266
Project: Solr
Issue Type: New Feature
Reporter: Varun
Assignee: Joel Bernstein

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-Tests-4.x-Java7 - Build # 2086 - Failure

2014-09-04 Thread Apache Jenkins Server

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

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandlerBackup

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.handler.TestReplicationHandlerBackup: 1) Thread[id=16679, 
name=Thread-2385, state=RUNNABLE, group=TGRP-TestReplicationHandlerBackup]  
   at java.net.PlainSocketImpl.socketConnect(Native Method) at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
 at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
 at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)  
   at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at 
java.net.Socket.connect(Socket.java:579) at 
java.net.Socket.connect(Socket.java:528) at 
sun.net.NetworkClient.doConnect(NetworkClient.java:180) at 
sun.net.www.http.HttpClient.openServer(HttpClient.java:432) at 
sun.net.www.http.HttpClient.openServer(HttpClient.java:527) at 
sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:652) at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1323)
 at java.net.URL.openStream(URL.java:1037) at 
org.apache.solr.handler.TestReplicationHandlerBackup$BackupThread.run(TestReplicationHandlerBackup.java:313)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.handler.TestReplicationHandlerBackup: 
   1) Thread[id=16679, name=Thread-2385, state=RUNNABLE, 
group=TGRP-TestReplicationHandlerBackup]
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at java.net.Socket.connect(Socket.java:528)
at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:432)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:527)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:652)
at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1323)
at java.net.URL.openStream(URL.java:1037)
at 
org.apache.solr.handler.TestReplicationHandlerBackup$BackupThread.run(TestReplicationHandlerBackup.java:313)
at __randomizedtesting.SeedInfo.seed([DDE04D87070FE716]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandlerBackup

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=16679, name=Thread-2385, state=RUNNABLE, 
group=TGRP-TestReplicationHandlerBackup] at 
java.net.PlainSocketImpl.socketConnect(Native Method) at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
 at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
 at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)  
   at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at 
java.net.Socket.connect(Socket.java:579) at 
java.net.Socket.connect(Socket.java:528) at 
sun.net.NetworkClient.doConnect(NetworkClient.java:180) at 
sun.net.www.http.HttpClient.openServer(HttpClient.java:432) at 
sun.net.www.http.HttpClient.openServer(HttpClient.java:527) at 
sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:652) at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1323)
 at java.net.URL.openStream(URL.java:1037) at 
org.apache.solr.handler.TestReplicationHandlerBackup$BackupThread.run(TestReplicationHandlerBackup.java:313)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   1) Thread[id=16679, name=Thread-2385, state=RUNNABLE, 
group=TGRP-TestReplicationHandlerBackup]
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at java.net.Socket.connect(Socket.java:528)
at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
at

[jira] [Updated] (SOLR-6266) Couchbase plug-in for Solr

2014-09-04 Thread ASF subversion and git services (JIRA)

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

Instead of marshaling couchbase updates into the normal Solr update process, we
could also embed a SolrJ client to relay the request through the http
interfaces. This may be necessary if we have to handle mapping couchbase
buckets to Solr collections on the Solr side.

Couchbase plug-in for Solr
--

Key: SOLR-6266
URL: https://issues.apache.org/jira/browse/SOLR-6266
Project: Solr
Issue Type: New Feature
Reporter: Varun
Assignee: Joel Bernstein

It would be great if users could connect Couchbase and Solr so that updates
to Couchbase can automatically flow to Solr. Couchbase provides some very
nice API's which allow applications to mimic the behavior of a Couchbase
server so that it can receive updates via Couchbase's normal cross data
center replication (XDCR).
One possible design for this is to create a CouchbaseLoader that extends
ContentStreamLoader. This new loader would embed the couchbase api's that
listen for incoming updates from couchbase, then marshal the couchbase
updates into the normal Solr update process.
Instead of marshaling couchbase updates into the normal Solr update process,
we could also embed a SolrJ client to relay the request through the http
interfaces. This may be necessary if we have to handle mapping couchbase
buckets to Solr collections on the Solr side.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5906) Use Files.delete instead of File.delete + made up exception


[ 
https://issues.apache.org/jira/browse/LUCENE-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121531#comment-14121531
 ] 

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

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

LUCENE-5906: Use Files.delete everywhere instead of File.delete

 Use Files.delete instead of File.delete + made up exception
 ---

 Key: LUCENE-5906
 URL: https://issues.apache.org/jira/browse/LUCENE-5906
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-5906.patch, LUCENE-5906.patch, LUCENE-5906.patch, 
 LUCENE-5906.patch, LUCENE-5906.patch


 We are on java7, if we cannot delete a file, this one returns a real 
 exception as to why.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (LUCENE-5906) Use Files.delete instead of File.delete + made up exception


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

Robert Muir resolved LUCENE-5906.
-
   Resolution: Fixed
Fix Version/s: 4.11
   5.0

Thanks Uwe for all the testing and debugging on windows!

 Use Files.delete instead of File.delete + made up exception
 ---

 Key: LUCENE-5906
 URL: https://issues.apache.org/jira/browse/LUCENE-5906
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Fix For: 5.0, 4.11

 Attachments: LUCENE-5906.patch, LUCENE-5906.patch, LUCENE-5906.patch, 
 LUCENE-5906.patch, LUCENE-5906.patch


 We are on java7, if we cannot delete a file, this one returns a real 
 exception as to why.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: NearSpansOrdered semantics

2014-09-04 Thread Chris Hostetter


: So according to those issues, it seems others also think that end1 = end2
: is also a correct behavior of SNQ (in case ordered=true, and

A more accurate way ot put it may be that *some* people felt like it was 
the lest counter-intuitive behavior they could think of, and everybody 
else either didn't have an opinion, didn't share an opinion, or didn't 
understand spans enough to know if they had an opinion.

: start1==start2). Was there a reason these issues were not resolved (e.g.
: LUCENE-3120)? I'm asking if there was additional discussion where people
: raised objections against this, or was it just a matter of lack of
: time/focus?

you could probably find more wisps of discussion about spans and nearness 
in general in the list archives, but i don't remember anything really 
concrete beyond the thread mentioned in LUCENE-3120 (and the earlier 
thread linked ot from it) ... and the only reason i remember that is 
because it wsa easy to find from the jira...

https://mail-archives.apache.org/mod_mbox/lucene-dev/201105.mbox/%3c614c529d389a5944b351f7dfb7594f240126d...@uksrpblkexb01.detica.com%3E

https://mail-archives.apache.org/mod_mbox/lucene-dev/200612.mbox/%3c45788e3d.20...@istandfor.com%3E

:  https://issues.apache.org/jira/browse/LUCENE-3120
:  https://issues.apache.org/jira/browse/LUCENE-3371
:  https://issues.apache.org/jira/browse/LUCENE-3229


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

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

Re: [jira] [Commented] (LUCENE-5906) Use Files.delete instead of File.delete + made up exception

I was responding to Uwe's comment about using nio for file perms. It's
tangential though I agree. And I missed the fact that this patch
wasn't committed yet when looking at the code. Well, it is as I write
this...

For the nonce I'm going to pass on this issue though. I think it needs
some more thought on my part and we're using  File.setWriteable() in
other places so this'll be part of a bigger migration I think.

On Thu, Sep 4, 2014 at 9:09 AM, Robert Muir rcm...@gmail.com wrote:
 Erick, I dont think you looked at the commit or patch. There is no
 such thing for Files.delete.

 So maybe you are discussing something unrelated to the issue (i
 recommend a separate thread).

 On Thu, Sep 4, 2014 at 12:00 PM, Erick Erickson erickerick...@gmail.com 
 wrote:
 Wait. A quick look at the nio.files.Files class and...

 In the brave new world here are we requiring that we test first to see
 what the filesystem is? Because there's Posix and Dos varieties that
 seem to be invoked separately. I don't see anywhere else in the code
 base where we do this, am I the first or am I just dense?

 On Thu, Sep 4, 2014 at 8:56 AM, ASF subversion and git services (JIRA)
 j...@apache.org wrote:

 [ 
 https://issues.apache.org/jira/browse/LUCENE-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121491#comment-14121491
  ]

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

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

 LUCENE-5906: Use Files.delete everywhere instead of File.delete

 Use Files.delete instead of File.delete + made up exception
 ---

 Key: LUCENE-5906
 URL: https://issues.apache.org/jira/browse/LUCENE-5906
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-5906.patch, LUCENE-5906.patch, 
 LUCENE-5906.patch, LUCENE-5906.patch, LUCENE-5906.patch


 We are on java7, if we cannot delete a file, this one returns a real 
 exception as to why.



 --
 This message was sent by Atlassian JIRA
 (v6.3.4#6332)

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


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


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


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

[jira] [Resolved] (SOLR-4206) Solr server should have the self start/stop script

2014-09-04 Thread Timothy Potter (JIRA)


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

Timothy Potter resolved SOLR-4206.
--
Resolution: Duplicate

This was addressed with SOLR-3617

 Solr server should have the self start/stop script
 --

 Key: SOLR-4206
 URL: https://issues.apache.org/jira/browse/SOLR-4206
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0
 Environment: Linux
Reporter: Raintung Li
 Attachments: solr.properties, solr.sh


 Start the solr server, need manual shell command to start.
 The start/stop script easy to let admin deploy and control server, especial 
 stop solr server. Directly kill the process, that doesn't good choice. 
 Shell script can let the start/stop more easy, and some parameter can be 
 configuration in the properties file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (SOLR-6467) solr start script puts log files in bin directory

2014-09-04 Thread Timothy Potter (JIRA)


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

Timothy Potter reassigned SOLR-6467:


Assignee: Timothy Potter

 solr start script puts log files in bin directory
 -

 Key: SOLR-6467
 URL: https://issues.apache.org/jira/browse/SOLR-6467
 Project: Solr
  Issue Type: Improvement
  Components: scripts and tools
Affects Versions: 4.10
 Environment: Mac/Linux
Reporter: Alexandre Rafalovitch
Assignee: Timothy Potter
Priority: Minor

 When running the new bin/solr script, by default it runs Solr in background 
 mode and redirects stdout/stderr to a log file.
 That log file is placed in the bin directory even if the command is invoked 
 from outside. It should probably go to a log directory as defined by the 
 configuration file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

2014-09-04 Thread ASF subversion and git services (JIRA)


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

Hoss Man commented on SOLR-6024:


bq. This patch includes the last changes in trunk plus the changes needed for 
branch 4x.
It also include DocValuesStats (should probably be merged from trunk instead)

thanks tomas, looks good to me - currently running precommit (and another round 
of tests just to be safe) on 4x and then i'll commit.

FWIW, here's my backporting steps...

{noformat}
# NOTE: working dir is 4x checkout, ../dev is trunk checkout...

svn merge -c 1622386 ../dev/

# manually massaged schema11.xml, StatsComponent.java per Tomas's 4x patch
# confirm all tests *except* the new StatsComponentTest pass

# manually copy DocValuesStats.java from Tomas's 4x patch
# confirm StatsComponentTest passes now

svn add solr/core/src/java/org/apache/solr/request/DocValuesStats.java

svn merge --record-only -c 1594441 ../dev 
solr/core/src/java/org/apache/solr/request/DocValuesStats.java
svn merge --record-only -c 1594445 ../dev 
solr/core/src/java/org/apache/solr/request/DocValuesStats.java
svn merge --record-only -c 1595259 ../dev 
solr/core/src/java/org/apache/solr/request/DocValuesStats.java
svn merge --record-only -c 1600688 ../dev 
solr/core/src/java/org/apache/solr/request/DocValuesStats.java
svn merge --record-only -c 1602997 ../dev 
solr/core/src/java/org/apache/solr/request/DocValuesStats.java
{noformat}



 StatsComponent does not work for docValues enabled multiValued fields
 -

 Key: SOLR-6024
 URL: https://issues.apache.org/jira/browse/SOLR-6024
 Project: Solr
  Issue Type: Bug
  Components: SearchComponents - other
Affects Versions: 4.8
 Environment: java version 1.7.0_45
 Mac OS X Version 10.7.5
Reporter: Ahmet Arslan
  Labels: StatsComponent, docValues, multiValued
 Fix For: 4.9

 Attachments: SOLR-6024-branch_4x.patch, SOLR-6024-trunk.patch, 
 SOLR-6024-trunk.patch, SOLR-6024-trunk.patch, SOLR-6024-trunk.patch, 
 SOLR-6024-trunk.patch, SOLR-6024.patch, SOLR-6024.patch


 Harish Agarwal reported this in solr user mailing list : 
 http://search-lucene.com/m/QTPaoTJXV1
 It is east to re-produce with default example solr setup. Following types are 
 added example schema.xml. And exampledocs are indexed.
 {code:xml}
  field name=cat type=string indexed=true stored=true 
 docValues=true multiValued=true/
   field name=popularity type=int indexed=true stored=false 
 docValues=true multiValued=true/
 {code}
 When {{docValues=true}} *and* {{multiValued=true}} are used at the same 
 time, StatsComponent throws :
 {noformat}
 ERROR org.apache.solr.core.SolrCore  – org.apache.solr.common.SolrException: 
 Type mismatch: popularity was indexed as SORTED_SET
   at 
 org.apache.solr.request.UnInvertedField.init(UnInvertedField.java:193)
   at 
 org.apache.solr.request.UnInvertedField.getUnInvertedField(UnInvertedField.java:699)
   at 
 org.apache.solr.handler.component.SimpleStats.getStatsFields(StatsComponent.java:319)
   at 
 org.apache.solr.handler.component.SimpleStats.getStatsCounts(StatsComponent.java:290)
   at 
 org.apache.solr.handler.component.StatsComponent.process(StatsComponent.java:78)
   at 
 org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:221)
   at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1964)
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5914) More options for stored fields compression

2014-09-04 Thread Ryan Ernst (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121721#comment-14121721
 ] 

Ryan Ernst commented on LUCENE-5914:


[~erickerickson] That example doesn't appear to even have stored fields enabled?

{quote}
field name=majorTextSignalStem type=text_stem indexed=true 
*stored=false* multiValued=true
omitNorms=false/
{quote}

 More options for stored fields compression
 --

 Key: LUCENE-5914
 URL: https://issues.apache.org/jira/browse/LUCENE-5914
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
 Fix For: 4.11

 Attachments: LUCENE-5914.patch


 Since we added codec-level compression in Lucene 4.1 I think I got about the 
 same amount of users complaining that compression was too aggressive and that 
 compression was too light.
 I think it is due to the fact that we have users that are doing very 
 different things with Lucene. For example if you have a small index that fits 
 in the filesystem cache (or is close to), then you might never pay for actual 
 disk seeks and in such a case the fact that the current stored fields format 
 needs to over-decompress data can sensibly slow search down on cheap queries.
 On the other hand, it is more and more common to use Lucene for things like 
 log analytics, and in that case you have huge amounts of data for which you 
 don't care much about stored fields performance. However it is very 
 frustrating to notice that the data that you store takes several times less 
 space when you gzip it compared to your index although Lucene claims to 
 compress stored fields.
 For that reason, I think it would be nice to have some kind of options that 
 would allow to trade speed for compression in the default codec.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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


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

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

Commit 1622525 from hoss...@apache.org in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1622525 ]

SOLR-6024: Fix StatsComponent when using docValues=true multiValued=true (merge 
r1622386, and DocValuesStats.java specific changes from r1594441, r1594445, 
r1595259, r1600688, r1602997)

 StatsComponent does not work for docValues enabled multiValued fields
 -

 Key: SOLR-6024
 URL: https://issues.apache.org/jira/browse/SOLR-6024
 Project: Solr
  Issue Type: Bug
  Components: SearchComponents - other
Affects Versions: 4.8
 Environment: java version 1.7.0_45
 Mac OS X Version 10.7.5
Reporter: Ahmet Arslan
  Labels: StatsComponent, docValues, multiValued
 Fix For: 4.9

 Attachments: SOLR-6024-branch_4x.patch, SOLR-6024-trunk.patch, 
 SOLR-6024-trunk.patch, SOLR-6024-trunk.patch, SOLR-6024-trunk.patch, 
 SOLR-6024-trunk.patch, SOLR-6024.patch, SOLR-6024.patch


 Harish Agarwal reported this in solr user mailing list : 
 http://search-lucene.com/m/QTPaoTJXV1
 It is east to re-produce with default example solr setup. Following types are 
 added example schema.xml. And exampledocs are indexed.
 {code:xml}
  field name=cat type=string indexed=true stored=true 
 docValues=true multiValued=true/
   field name=popularity type=int indexed=true stored=false 
 docValues=true multiValued=true/
 {code}
 When {{docValues=true}} *and* {{multiValued=true}} are used at the same 
 time, StatsComponent throws :
 {noformat}
 ERROR org.apache.solr.core.SolrCore  – org.apache.solr.common.SolrException: 
 Type mismatch: popularity was indexed as SORTED_SET
   at 
 org.apache.solr.request.UnInvertedField.init(UnInvertedField.java:193)
   at 
 org.apache.solr.request.UnInvertedField.getUnInvertedField(UnInvertedField.java:699)
   at 
 org.apache.solr.handler.component.SimpleStats.getStatsFields(StatsComponent.java:319)
   at 
 org.apache.solr.handler.component.SimpleStats.getStatsCounts(StatsComponent.java:290)
   at 
 org.apache.solr.handler.component.StatsComponent.process(StatsComponent.java:78)
   at 
 org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:221)
   at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1964)
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

2014-09-04 Thread ASF subversion and git services (JIRA)


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

Hoss Man resolved SOLR-6024.

   Resolution: Fixed
Fix Version/s: (was: 4.9)
   4.11
 Assignee: Tomás Fernández Löbbe

I think we're all good.

 StatsComponent does not work for docValues enabled multiValued fields
 -

 Key: SOLR-6024
 URL: https://issues.apache.org/jira/browse/SOLR-6024
 Project: Solr
  Issue Type: Bug
  Components: SearchComponents - other
Affects Versions: 4.8
 Environment: java version 1.7.0_45
 Mac OS X Version 10.7.5
Reporter: Ahmet Arslan
Assignee: Tomás Fernández Löbbe
  Labels: StatsComponent, docValues, multiValued
 Fix For: 4.11

 Attachments: SOLR-6024-branch_4x.patch, SOLR-6024-trunk.patch, 
 SOLR-6024-trunk.patch, SOLR-6024-trunk.patch, SOLR-6024-trunk.patch, 
 SOLR-6024-trunk.patch, SOLR-6024.patch, SOLR-6024.patch


 Harish Agarwal reported this in solr user mailing list : 
 http://search-lucene.com/m/QTPaoTJXV1
 It is east to re-produce with default example solr setup. Following types are 
 added example schema.xml. And exampledocs are indexed.
 {code:xml}
  field name=cat type=string indexed=true stored=true 
 docValues=true multiValued=true/
   field name=popularity type=int indexed=true stored=false 
 docValues=true multiValued=true/
 {code}
 When {{docValues=true}} *and* {{multiValued=true}} are used at the same 
 time, StatsComponent throws :
 {noformat}
 ERROR org.apache.solr.core.SolrCore  – org.apache.solr.common.SolrException: 
 Type mismatch: popularity was indexed as SORTED_SET
   at 
 org.apache.solr.request.UnInvertedField.init(UnInvertedField.java:193)
   at 
 org.apache.solr.request.UnInvertedField.getUnInvertedField(UnInvertedField.java:699)
   at 
 org.apache.solr.handler.component.SimpleStats.getStatsFields(StatsComponent.java:319)
   at 
 org.apache.solr.handler.component.SimpleStats.getStatsCounts(StatsComponent.java:290)
   at 
 org.apache.solr.handler.component.StatsComponent.process(StatsComponent.java:78)
   at 
 org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:221)
   at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1964)
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6297) Distributed spellcheck with WordBreakSpellchecker can lose suggestions


[ 
https://issues.apache.org/jira/browse/SOLR-6297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121733#comment-14121733
 ] 

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

Commit 1622526 from jd...@apache.org in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1622526 ]

SOLR-6297: Fix for Distributed WordBreakSolrSpellChecker

 Distributed spellcheck with WordBreakSpellchecker can lose suggestions
 --

 Key: SOLR-6297
 URL: https://issues.apache.org/jira/browse/SOLR-6297
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.9
Reporter: Steve Molloy
 Attachments: SOLR-6297.patch, SOLR-6297.patch, SOLR-6297.patch, 
 SOLR-6297.patch


 When performing a spellcheck request in distributed environment with the 
 WordBreakSpellChecker configured, the shard response merging logic can lose 
 some suggestions. Basically, the merging logic ensures that all shards marked 
 the query as not being correctly spelled, which is good, but also expects all 
 shards to return some suggestions, which isn't necessarily the case. So if 
 shard 1 returns 10 suggestions but shard 2 returns none, the final result 
 will contain no suggestions because the term has suggestions from only 1 of 2 
 shards.
 This isn't the case with the DirectSolrSpellChecker which works properly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5922) DocValuesDocIdSet is not cacheable

2014-09-04 Thread Ryan Ernst (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121734#comment-14121734
 ] 

Ryan Ernst commented on LUCENE-5922:


LGTM.

 DocValuesDocIdSet is not cacheable
 --

 Key: LUCENE-5922
 URL: https://issues.apache.org/jira/browse/LUCENE-5922
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 4.10
Reporter: Adrien Grand
 Fix For: 4.11

 Attachments: LUCENE-5922.patch


 This DocIdSet claims it is cacheable although bad things could happen if it 
 was cached since it is not thread-safe and keeps handles to open files.
 The fix is simple, especially given that this doc id set is cheap to create. 
 But I'm wondering if there is a way we could protect ourselves from such bugs 
 in the future.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-6297) Distributed spellcheck with WordBreakSpellchecker can lose suggestions

2014-09-04 Thread James Dyer (JIRA)


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

James Dyer resolved SOLR-6297.
--
   Resolution: Fixed
Fix Version/s: 4.11
 Assignee: James Dyer

 Distributed spellcheck with WordBreakSpellchecker can lose suggestions
 --

 Key: SOLR-6297
 URL: https://issues.apache.org/jira/browse/SOLR-6297
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.9
Reporter: Steve Molloy
Assignee: James Dyer
 Fix For: 4.11

 Attachments: SOLR-6297.patch, SOLR-6297.patch, SOLR-6297.patch, 
 SOLR-6297.patch


 When performing a spellcheck request in distributed environment with the 
 WordBreakSpellChecker configured, the shard response merging logic can lose 
 some suggestions. Basically, the merging logic ensures that all shards marked 
 the query as not being correctly spelled, which is good, but also expects all 
 shards to return some suggestions, which isn't necessarily the case. So if 
 shard 1 returns 10 suggestions but shard 2 returns none, the final result 
 will contain no suggestions because the term has suggestions from only 1 of 2 
 shards.
 This isn't the case with the DirectSolrSpellChecker which works properly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: VOTE: Solr Reference Guide for 4.10

2014-09-04 Thread Timothy Potter

+1

On Wed, Sep 3, 2014 at 2:00 PM, Shalin Shekhar Mangar
shalinman...@gmail.com wrote:
 +1


 On Tue, Sep 2, 2014 at 2:38 PM, Cassandra Targett ctarg...@apache.org
 wrote:

 Please vote to release the PDF of the Apache Solr Reference Guide for Solr
 4.10.


 https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-4.10-RC0

 $ cat apache-solr-ref-guide-4.10-RC0/apache-solr-ref-guide-4.10.pdf.sha1
 e7a43acbc3da06f4c65af9067a3850557c665666  apache-solr-ref-guide-4.10.pdf

 +1 from me

 - Cassandra




 --
 Regards,
 Shalin Shekhar Mangar.

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

[jira] [Created] (LUCENE-5924) Rename checkindex's -fix option

2014-09-04 Thread ASF subversion and git services (JIRA)

Robert Muir created LUCENE-5924:
---

 Summary: Rename checkindex's -fix option
 Key: LUCENE-5924
 URL: https://issues.apache.org/jira/browse/LUCENE-5924
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir


This option is dangerous. It sounds so good though that people are quick to use 
it, but it definitely drops entire segments.

The commandline flag should be someting other than -fix (e.g. -exorcise).

I dont agree with the current description of the option either. True, it does 
have **WARNING** but I think it should read more like the scary options in 'man 
hdparm'.

Like hdparm, we could fail if you provide it with an even more ridiculous 
warning, and make you run again with --yes-i-really-know-what-i-am-doing as 
well.





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5924) Rename checkindex's -fix option

2014-09-04 Thread Michael McCandless (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121802#comment-14121802
 ] 

Michael McCandless commented on LUCENE-5924:


+1, this badly needs to be renamed.

And +1 for -exorcise.

 Rename checkindex's -fix option
 ---

 Key: LUCENE-5924
 URL: https://issues.apache.org/jira/browse/LUCENE-5924
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir

 This option is dangerous. It sounds so good though that people are quick to 
 use it, but it definitely drops entire segments.
 The commandline flag should be someting other than -fix (e.g. -exorcise).
 I dont agree with the current description of the option either. True, it does 
 have **WARNING** but I think it should read more like the scary options in 
 'man hdparm'.
 Like hdparm, we could fail if you provide it with an even more ridiculous 
 warning, and make you run again with --yes-i-really-know-what-i-am-doing as 
 well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-6481) CLUSTERSTATUS action should consult /live_nodes when reporting the state of a replica

2014-09-04 Thread Timothy Potter (JIRA)

Timothy Potter created SOLR-6481:


 Summary: CLUSTERSTATUS action should consult /live_nodes when 
reporting the state of a replica
 Key: SOLR-6481
 URL: https://issues.apache.org/jira/browse/SOLR-6481
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Timothy Potter


CLUSTERSTATUS action reports the state of replicas but it doesn't check 
/live_nodes, which means it might show a replica as active but the node is 
down, so the real state is down.

Ideally, we need a helper method that gets replica status that consults live 
nodes so this error doesn't keep cropping up all over the code base.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5902) Add bumpVersion script to increment version after release branch creation


[ 
https://issues.apache.org/jira/browse/LUCENE-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121888#comment-14121888
 ] 

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

Commit 1622546 from [~rjernst] in branch 'dev/trunk'
[ https://svn.apache.org/r1622546 ]

LUCENE-5902: Add bumpVersion.py script

 Add bumpVersion script to increment version after release branch creation
 -

 Key: LUCENE-5902
 URL: https://issues.apache.org/jira/browse/LUCENE-5902
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Ryan Ernst
 Attachments: LUCENE-5902.patch, LUCENE-5902.patch


 Thanks to LUCENE-5898 there are many less places to increment version.  
 However, I still think this script can be useful in automating the entire 
 process (minus the commit).  This would:
 * Add new sections to {{lucene/CHANGES.txt}} and {{solr/CHANGES.txt}}
 * Add new version constant
 * Change {{LATEST}} value
 * Change {{version.base}} in {{lucene/version.properties}}
 * Change version used in solr example configs
 * Create a BWC index and test if necessary



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: VOTE: Solr Reference Guide for 4.10

2014-09-04 Thread Anshum Gupta

+1


On Tue, Sep 2, 2014 at 2:38 PM, Cassandra Targett ctarg...@apache.org
wrote:

 Please vote to release the PDF of the Apache Solr Reference Guide for Solr
 4.10.


 https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-4.10-RC0

 $ cat apache-solr-ref-guide-4.10-RC0/apache-solr-ref-guide-4.10.pdf.sha1
 e7a43acbc3da06f4c65af9067a3850557c665666  apache-solr-ref-guide-4.10.pdf

 +1 from me

 - Cassandra




-- 

Anshum Gupta
http://www.anshumgupta.net

Re: VOTE: Solr Reference Guide for 4.10

2014-09-04 Thread Tomás Fernández Löbbe

+1


On Thu, Sep 4, 2014 at 12:58 PM, Anshum Gupta ans...@anshumgupta.net
wrote:

 +1


 On Tue, Sep 2, 2014 at 2:38 PM, Cassandra Targett ctarg...@apache.org
 wrote:

 Please vote to release the PDF of the Apache Solr Reference Guide for
 Solr 4.10.


 https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-4.10-RC0

 $ cat apache-solr-ref-guide-4.10-RC0/apache-solr-ref-guide-4.10.pdf.sha1
 e7a43acbc3da06f4c65af9067a3850557c665666  apache-solr-ref-guide-4.10.pdf

 +1 from me

 - Cassandra




 --

 Anshum Gupta
 http://www.anshumgupta.net

[jira] [Commented] (LUCENE-5914) More options for stored fields compression

2014-09-04 Thread Erick Erickson (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121916#comment-14121916
 ] 

Erick Erickson commented on LUCENE-5914:


[~rjernst]] Right, that particular field doesn't, I was assuming that other 
fields did.

Hmmm, let me ping him back and we'll see if we can get him to experiment for us.



 More options for stored fields compression
 --

 Key: LUCENE-5914
 URL: https://issues.apache.org/jira/browse/LUCENE-5914
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
 Fix For: 4.11

 Attachments: LUCENE-5914.patch


 Since we added codec-level compression in Lucene 4.1 I think I got about the 
 same amount of users complaining that compression was too aggressive and that 
 compression was too light.
 I think it is due to the fact that we have users that are doing very 
 different things with Lucene. For example if you have a small index that fits 
 in the filesystem cache (or is close to), then you might never pay for actual 
 disk seeks and in such a case the fact that the current stored fields format 
 needs to over-decompress data can sensibly slow search down on cheap queries.
 On the other hand, it is more and more common to use Lucene for things like 
 log analytics, and in that case you have huge amounts of data for which you 
 don't care much about stored fields performance. However it is very 
 frustrating to notice that the data that you store takes several times less 
 space when you gzip it compared to your index although Lucene claims to 
 compress stored fields.
 For that reason, I think it would be nice to have some kind of options that 
 would allow to trade speed for compression in the default codec.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-5814) CoreContainer reports incorrect missleading path for solrconfig.xml when there are loading problems


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

Hoss Man updated SOLR-5814:
---
Attachment: SOLR-5814.patch

updated patch to trunk - some code moved around a bit.

this also fixes TestLazyCores which had a test for the error condition (yeah!) 
but was asserting that the bad path was in the error message (booo!)

running more tests and then i'll commit  backport.

 CoreContainer reports incorrect  missleading path for solrconfig.xml when 
 there are loading problems
 -

 Key: SOLR-5814
 URL: https://issues.apache.org/jira/browse/SOLR-5814
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
 Attachments: SOLR-5814.patch, SOLR-5814.patch


 The error messages thrown by CoreContainer when there is a problem loading 
 solrconfig.xml refer to the wrong path (leaves out conf/).
 This is missleading users (who may not notice the root cause) into thinking 
 they need to move their solrconfig.xml from 
 {{collection_name/conf/solrconfig.xml}} to {{collection_name/solrconfig.xml}} 
 at which point they still get the same error message because solr still can't 
 find the file in the conf dir



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (SOLR-5814) CoreContainer reports incorrect missleading path for solrconfig.xml when there are loading problems