[jira] [Commented] (SOLR-4794) UI is broken on browsers for Android

[Raja Nagendra Kumar (JIRA)]

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

Raja Nagendra Kumar commented on SOLR-4794:
---

One issue found is Content overlapping due to zoom or scrolling.

This is because of CSS div format of position: fixed
The following lines can be removed

solr\webapp\web\css\styles\common.css 
line 194   position: fixed;

solr\webapp\web\css\styles\menu.css 
line 22   position: fixed;

then re-order of div element in  file solr\admin.html

 div id=content-wrapper
div id=content
nbsp;
/div
  /div

this should be move below menu-wrapper div. i.e from line 80 to line 135. This 
way default position of static would work fine.
http://www.w3schools.com/cssref/pr_class_position.asp

With this change android version on Samsung S4 default and chrome browsers work 
without overlap on scroll or during zoom.

However content is appearing below the left menu i.e y position is non zero. 
Some more changes would be needed at CSS to make sure content window is 
positioned with y position as zero. May be CSS experts would be able to make 
rest of the adjustments needed for y to be zero.

 UI is broken on browsers for Android
 

 Key: SOLR-4794
 URL: https://issues.apache.org/jira/browse/SOLR-4794
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.3
 Environment: HTC Amaze 4G
Reporter: Shawn Heisey
Priority: Minor
 Fix For: 5.0


 I've tried three browsers for my Android phone, an Amaze 4G by HTC.  All of 
 them have problems.
 One problem common to all of them is that the stuff on the left-hand side of 
 the screen always stays put and will cover up the rest of the page if you 
 zoom in and/or scroll around.
 1) Built-in browser: I think this is probably provided or modified by HTC.  
 This one is extremely broken. By clicking in what looks like incorrect 
 places, you can select a core, but you can't get to any of the good stuff 
 like the query or analysis UI.
 2) Chrome for Android: Better than the HTC/Android browser.  I can get to the 
 query UI, but when I try to execute a query, it goes back to the dashboard.
 3) Firefox for Android: Works fairly well on the few things I tested, except 
 for the left-hand stuff covering the rest of the page as mentioned above.  I 
 don't know if everything is working, but this is the only one that let me use 
 the query UI.



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

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

[jira] [Comment Edited] (SOLR-4794) UI is broken on browsers for Android

[Raja Nagendra Kumar (JIRA)]

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

Raja Nagendra Kumar edited comment on SOLR-4794 at 4/2/14 7:03 AM:
---

One issue found is Content overlapping due to zoom or scrolling.

This is because of CSS div format of position: fixed
The following lines can be removed

solr\webapp\web\css\styles\common.css 
line 194   position: fixed;

solr\webapp\web\css\styles\menu.css 
line 22   position: fixed;

then re-order of div element in  file solr\admin.html

 div id=content-wrapper
div id=content
nbsp;
/div
  /div

this should be moved below menu-wrapper div. i.e from line 80 to line 135. This 
way default position of static would work fine.
http://www.w3schools.com/cssref/pr_class_position.asp

With this change android version on Samsung S4 default and chrome browsers work 
without overlap on scroll or during zoom.

However content is appearing below the left menu i.e y position is non zero. 
Some more changes would be needed at CSS to make sure content window is 
positioned with y position as zero. May be CSS experts would be able to make 
rest of the adjustments needed for y to be zero.


was (Author: nagkumar):
One issue found is Content overlapping due to zoom or scrolling.

This is because of CSS div format of position: fixed
The following lines can be removed

solr\webapp\web\css\styles\common.css 
line 194   position: fixed;

solr\webapp\web\css\styles\menu.css 
line 22   position: fixed;

then re-order of div element in  file solr\admin.html

 div id=content-wrapper
div id=content
nbsp;
/div
  /div

this should be move below menu-wrapper div. i.e from line 80 to line 135. This 
way default position of static would work fine.
http://www.w3schools.com/cssref/pr_class_position.asp

With this change android version on Samsung S4 default and chrome browsers work 
without overlap on scroll or during zoom.

However content is appearing below the left menu i.e y position is non zero. 
Some more changes would be needed at CSS to make sure content window is 
positioned with y position as zero. May be CSS experts would be able to make 
rest of the adjustments needed for y to be zero.

 UI is broken on browsers for Android
 

 Key: SOLR-4794
 URL: https://issues.apache.org/jira/browse/SOLR-4794
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.3
 Environment: HTC Amaze 4G
Reporter: Shawn Heisey
Priority: Minor
 Fix For: 5.0


 I've tried three browsers for my Android phone, an Amaze 4G by HTC.  All of 
 them have problems.
 One problem common to all of them is that the stuff on the left-hand side of 
 the screen always stays put and will cover up the rest of the page if you 
 zoom in and/or scroll around.
 1) Built-in browser: I think this is probably provided or modified by HTC.  
 This one is extremely broken. By clicking in what looks like incorrect 
 places, you can select a core, but you can't get to any of the good stuff 
 like the query or analysis UI.
 2) Chrome for Android: Better than the HTC/Android browser.  I can get to the 
 query UI, but when I try to execute a query, it goes back to the dashboard.
 3) Firefox for Android: Works fairly well on the few things I tested, except 
 for the left-hand stuff covering the rest of the page as mentioned above.  I 
 don't know if everything is working, but this is the only one that let me use 
 the query UI.



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

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

[jira] [Commented] (SOLR-5556) Allow class of CollectionsHandler and InfoHandler to be specified in solr.xml

[zengjie (JIRA)]

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

zengjie commented on SOLR-5556:
---

nice feature!

 Allow class of CollectionsHandler and InfoHandler to be specified in solr.xml
 -

 Key: SOLR-5556
 URL: https://issues.apache.org/jira/browse/SOLR-5556
 Project: Solr
  Issue Type: New Feature
Affects Versions: 4.7, 5.0
Reporter: Gregory Chanan
Assignee: Alan Woodward
Priority: Minor
 Fix For: 4.7, 5.0

 Attachments: SOLR-5556.patch, SOLR-5556.patch


 Currently, you can specify the CoreAdminHandler class name in solr.xml, but 
 not the CollectionsHandler nor the InfoHandler.
 I want to run some (access control) checks around the administrative 
 commands.  I can do this with the CoreAdminHandler, but not the other two.



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

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

[jira] [Commented] (SOLR-5844) Backward Compatibility Has Broken For deleteById() at Solrj

[Ismael Juma (JIRA)]

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

Ismael Juma commented on SOLR-5844:
---

The original message says that there is no error though, it just does not work.

 Backward Compatibility Has Broken For deleteById() at Solrj
 ---

 Key: SOLR-5844
 URL: https://issues.apache.org/jira/browse/SOLR-5844
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.6, 4.6.1, 4.7
Reporter: Furkan KAMACI
Assignee: Noble Paul
 Fix For: 4.8


 I have started up a SolrCloud of 4.5.1 
 * When I use deleteById method of CloudSolrServer via 4.5.1 Solrj it works.
 * When I use deleteById method of CloudSolrServer via 4.6.0 Solrj it does not 
 work and does not throw error.
 * When I use deleteById method of CloudSolrServer via 4.6.1 Solrj it does not 
 work and does not throw error.
 * When I use deleteById method of CloudSolrServer via 4.7.0 Solrj it does not 
 work and does not throw error.
 So it seems that backward compatibility has broken since 4.6.0 



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

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

[jira] [Commented] (SOLR-5947) solr doesnt work

[Ramkumar Aiyengar (JIRA)]

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

Ramkumar Aiyengar commented on SOLR-5947:
-

Please ask the mailing list first as this is potentially an user error, you are 
likely to get better support there. We would also need more information here 
including your Solr configuration, and logs on the server side which might be 
showing the errors you are looking for.

 solr doesnt work
 

 Key: SOLR-5947
 URL: https://issues.apache.org/jira/browse/SOLR-5947
 Project: Solr
  Issue Type: Bug
  Components: contrib - Solr Cell (Tika extraction)
Affects Versions: 4.7
 Environment: Win7 64x
 Tomcat 8
Reporter: Ian Ding
   Original Estimate: 48h
  Remaining Estimate: 48h

 i can see the icon of solr, the sunny icon, while nothing is working, 
 including the dashboard. 
 if it does work, I could read the system monitor on the right side of the 
 interface, at least..but it did't show any number.



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

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

[jira] [Updated] (SOLR-5943) SolrCmdDistributor does not distribute the openSearcher parameter

[ludovic Boutros (JIRA)]

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

ludovic Boutros updated SOLR-5943:
--

Attachment: SOLR-5943.patch

A first small patch with unit test on branch lucene_solr_4_7.


 SolrCmdDistributor does not distribute the openSearcher parameter
 -

 Key: SOLR-5943
 URL: https://issues.apache.org/jira/browse/SOLR-5943
 Project: Solr
  Issue Type: Bug
  Components: update
Affects Versions: 4.6.1, 4.7
Reporter: ludovic Boutros
Assignee: Shalin Shekhar Mangar
 Fix For: 4.8, 5.0

 Attachments: SOLR-5943.patch


 The openSearcher parameter in a commit command is totally ignored by the 
 SolrCmdDistributor :
 {code:title=SolrCmdDistributor.java|borderStyle=solid}
  void addCommit(UpdateRequest ureq, CommitUpdateCommand cmd) {
 if (cmd == null) return;
 ureq.setAction(cmd.optimize ? AbstractUpdateRequest.ACTION.OPTIMIZE
 : AbstractUpdateRequest.ACTION.COMMIT, false, cmd.waitSearcher, 
 cmd.maxOptimizeSegments, cmd.softCommit, cmd.expungeDeletes);
   }{code}
 I think the SolrJ API should take this parameter in account as well.



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

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

[jira] [Updated] (SOLR-5473) Make one state.json per collection

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-5473:
-

Attachment: SOLR-5473-74.patch

The ExternalCollectionsTest was missing in the last patch

 Make one state.json per collection
 --

 Key: SOLR-5473
 URL: https://issues.apache.org/jira/browse/SOLR-5473
 Project: Solr
  Issue Type: Sub-task
  Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
 Attachments: SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, ec2-23-20-119-52_solr.log, 
 ec2-50-16-38-73_solr.log


 As defined in the parent issue, store the states of each collection under 
 /collections/collectionname/state.json node



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

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

[jira] [Updated] (SOLR-4864) RegexReplaceProcessorFactory should support pattern capture group substitution in replacement string

[Sunil Srinivasan (JIRA)]

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

Sunil Srinivasan updated SOLR-4864:
---

Attachment: SOLR-4864.patch

Here is a patch for the functionality that Hoss/Jack wanted. Please review. 
I've added the additional tests as part of the testRegexReplace. Please let me 
know if they need to be separated out. 

 RegexReplaceProcessorFactory should support pattern capture group 
 substitution in replacement string
 

 Key: SOLR-4864
 URL: https://issues.apache.org/jira/browse/SOLR-4864
 Project: Solr
  Issue Type: Improvement
  Components: update
Affects Versions: 4.3
Reporter: Jack Krupansky
 Attachments: SOLR-4864.patch


 It is unfortunate the the replacement string for RegexReplaceProcessorFactory 
 is a pure, quoted (escaped) literal and does not support pattern capture 
 group substitution. This processor should be enhanced to support full, 
 standard pattern capture group substitution.
 The test case I used:
 {code}
   updateRequestProcessorChain name=regex-mark-special-words
 processor class=solr.RegexReplaceProcessorFactory
   str name=fieldRegex.*/str
   str name=pattern([^a-zA-Z]|^)(cat|dog|fox)([^a-zA-Z]|$)/str
   str name=replacement$1lt;lt;$2gt;gt;$3/str
 /processor
 processor class=solr.LogUpdateProcessorFactory /
 processor class=solr.RunUpdateProcessorFactory /
   /updateRequestProcessorChain
 {code}
 Indexing with this command against the standard Solr example with the above 
 addition to solrconfig:
 {code}
   curl 
 http://localhost:8983/solr/update?commit=trueupdate.chain=regex-mark-special-words;
  \
   -H 'Content-type:application/json' -d '
   [{id: doc-1,
 title: Hello World,
 content: The cat and the dog jumped over the fox.,
 other_ss: [cat,cat bird, lazy dog, red fox den]}]'
 {code}
 Alas, the resulting document consists of:
 {code}
   id:doc-1,
   title:[Hello World],
   content:[The$1$2$3and the$1$2$3jumped over the$1$2$3],
   other_ss:[$1$2$3,
 $1$2$3bird,
 lazy$1$2$3,
 red$1$2$3den],
 {code}
 The Javadoc for RegexReplaceProcessorFactory uses the exact same terminology 
 of  replacement string, as does Java's Matcher.replaceAll, but clearly the 
 semantics are distinct, with replaceAll supporting pattern capture group 
 substitution for its replacement string, while RegexReplaceProcessorFactory 
 interprets replacement string as being a literal. At a minimum, the 
 RegexReplaceProcessorFactory Javadoc should explicitly state that the string 
 is a literal that does not support pattern capture group substitution.
 The relevant code in RegexReplaceProcessorFactory#init:
 {code}
 replacement = Matcher.quoteReplacement(replacementParam.toString());
 {code}
 Possible options for the enhancement:
 1. Simply skip the quoteReplacement and fully support pattern capture group 
 substitution with no additional changes. Does have a minor backcompat issue.
 2. Add an alternative to replacement, say nonQuotedReplacement that is 
 not quoted as replacement is.
 3. Add an option, say quotedReplacement that defaults to true for 
 backcompat, but can be set to false to support full replaceAll pattern 
 capture group substitution.



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

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

Welcome Alan Woodward to the PMC

[Steve Rowe]

I'm pleased to announce that Alan Woodward has accepted the PMC's invitation to 
join.

Welcome Alan!

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

[jira] [Commented] (SOLR-3862) add remove as update option for atomically removing a value from a multivalued field

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-3862:
--

Don't quite know. In case you're wondering, I've been a bit under the weather 
so haven't been looking for a couple of days.

Even though I mentioned that back references are not supported, I'd rank 
supporting that over multiple regexes. 

Its not clear to me how useful multiple regexes really would be though. I 
suppose if we're trying to get the interface in place it would be best to 
clarify that up front though. Straw-man. Let's put multiple regexes in as in my 
example.

[~yo...@apache.org] got an opinion here?

 add remove as update option for atomically removing a value from a 
 multivalued field
 --

 Key: SOLR-3862
 URL: https://issues.apache.org/jira/browse/SOLR-3862
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Affects Versions: 4.0-BETA
Reporter: Jim Musil
Assignee: Erick Erickson
 Attachments: SOLR-3862-2.patch, SOLR-3862-3.patch, SOLR-3862-4.patch, 
 SOLR-3862.patch, SOLR-3862.patch


 Currently you can atomically add a value to a multivalued field. It would 
 be useful to be able to remove a value from a multivalued field. 
 When you set a multivalued field to null, it destroys all values.



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

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

[jira] [Comment Edited] (SOLR-3862) add remove as update option for atomically removing a value from a multivalued field

[Erick Erickson (JIRA)]

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

Erick Erickson edited comment on SOLR-3862 at 4/2/14 12:45 PM:
---

Right, it would look something like this:
{code}

Regular expressions can also be used to remove values by specifying 
removeregex, as:

activity : {removeregex : run.+}

Given a document with a field having values

[run, running, runs runner], the above would leave only [run].

Multiple regexes can be specified, as
activity : {removeregex : [run.+, ran.*] }

So a document with field values [run runner ran ransack] would be reduced to
[run]

There are two new commands, replace and replaceregex

activity : {replace : {pat1 : replacement1}  }

A document with activity of [pat, pat1, pat1more] would result in

[pat, replacement1, pat1more]

Note that order is preserved. That is, if the pattern being replaced is the 
third value in a multivalued field with 6 values, the replacement will also be 
in the third position.

Multiple patterns and replacements can be specified, as
activity : {replace :  [ {pat1 : replacement1}, {pat2 : 
replacement2} ]  }

replaceregex is similar, but all the pat* examples above may be regular 
expressions, as

activity : {replaceregex : {pat.+ : replacement1}  }
and
activity : {replaceregex :   [ {pat.+ : replacement1}, {part.* : 
replacement2} ]  }

Currently, back references are _not_ supported.

Patterns and replacements are _not_ chained. That is, the following

activity : {replaceregex :   [ {pat.+ : replacement1}, {repl.+ : 
replacement2} ]  }
applied to a field containing
[patterns]
would yield [replacement1] rather than [replacement2]

{code}

H, altogether I'm not sure how I feel about allowing multiple 
replaceregex's to be specified, the syntax is kinda ugly.

I'm not particularly wedded to the regex stuff but I can imagine it to be 
useful. I'd also be fine if the replace were left out.


was (Author: erickerickson):
Right, it would look something like this:
{code}

Regular expressions can also be used to remove values by specifying 
removeregex, as:

activity : {removeregex : run.+}

Given a document with a field having values

[run, running, runs runner], the above would leave only [run].

Multiple regexes can be specified, as
activity : {removeregex : [run.+, ran.*] }

So a document with field values [run runner ran ransack] would be reduced to
[run]

There are two new commands, replace and replaceregex

activity : {replace : {pat1 : replacement1}  }

A document with activity of [pat, pat1, pat1more] would result in

[pat, replacement1, pat1more]

Note that order is preserved. That is, if the pattern being replaced is the 
third value in a multivalued field with 6 values, the replacement will also be 
in the third position.

Multiple patterns and replacements can be specified, as
activity : {replace :  [ {pat1 : replacement1}, {pat2 : 
replacement2} ]  }

replaceregex is similar, but all the pat* examples above may be regular 
expressions, as

activity : {replaceregex : {pat.+ : replacement1}  }
and
activity : {replaceregex :   [ {pat.+ : replacement1}, {part.* : 
{replacement2} ]  }

Currently, back references are _not_ supported.

Patterns and replacements are _not_ chained. That is, the following

activity : {replaceregex :   [ {pat.+ : replacement1}, {repl.+ : 
{replacement2} ]  }
applied to a field containing
[patterns]
would yield [replacement1] rather than [replacement2]

{code}

H, altogether I'm not sure how I feel about allowing multiple 
replaceregex's to be specified, the syntax is kinda ugly.

I'm not particularly wedded to the regex stuff but I can imagine it to be 
useful. I'd also be fine if the replace were left out.

 add remove as update option for atomically removing a value from a 
 multivalued field
 --

 Key: SOLR-3862
 URL: https://issues.apache.org/jira/browse/SOLR-3862
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Affects Versions: 4.0-BETA
Reporter: Jim Musil
Assignee: Erick Erickson
 Attachments: SOLR-3862-2.patch, SOLR-3862-3.patch, SOLR-3862-4.patch, 
 SOLR-3862.patch, SOLR-3862.patch


 Currently you can atomically add a value to a multivalued field. It would 
 be useful to be able to remove a value from a multivalued field. 
 When you set a multivalued field to null, it destroys all values.



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

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

[JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 81259 - Failure!

[builder]

Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/81259/

8 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.lucene.codecs.lucene45.TestLucene45DocValuesFormat

Error Message:
Suite timeout exceeded (= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (= 720 msec).
at __randomizedtesting.SeedInfo.seed([7362FE36DE729D42]:0)


REGRESSION:  
org.apache.lucene.codecs.lucene45.TestLucene45DocValuesFormat.testSortedSetVariableLengthVsUninvertedField

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([7362FE36DE729D42]:0)


REGRESSION:  
org.apache.lucene.util.junitcompat.TestFailOnFieldCacheInsanity.testFailOnFieldCacheInsanity

Error Message:


Stack Trace:
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.lucene.util.junitcompat.TestFailOnFieldCacheInsanity.testFailOnFieldCacheInsanity(TestFailOnFieldCacheInsanity.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
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.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:180)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:276)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:12)


REGRESSION:  
org.apache.lucene.util.junitcompat.TestLeaveFilesIfTestFails.testLeaveFilesIfTestFails

Error Message:
expected:1 but was:0

Stack Trace:
java.lang.AssertionError: expected:1 but was:0
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.lucene.util.junitcompat.TestLeaveFilesIfTestFails.testLeaveFilesIfTestFails(TestLeaveFilesIfTestFails.java:45)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at 

Re: Welcome Alan Woodward to the PMC

[Stefan Matheis]

Welcome Alan! 

-Stefan 


On Wednesday, April 2, 2014 at 2:23 PM, Steve Rowe wrote:

 I'm pleased to announce that Alan Woodward has accepted the PMC's invitation 
 to join.
 
 Welcome Alan!
 
 - Steve
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
 (mailto:dev-unsubscr...@lucene.apache.org)
 For additional commands, e-mail: dev-h...@lucene.apache.org 
 (mailto:dev-h...@lucene.apache.org)
 
 

Re: Welcome Alan Woodward to the PMC

[Yonik Seeley]

Welcome Alan!


-Yonik
http://heliosearch.org - solve Solr GC pauses with off-heap filters
and fieldcache


On Wed, Apr 2, 2014 at 8:23 AM, Steve Rowe sar...@gmail.com wrote:
 I'm pleased to announce that Alan Woodward has accepted the PMC's invitation 
 to join.

 Welcome Alan!

 - Steve

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

Re: [JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 81259 - Failure!

[Robert Muir]

what happened here...

On Wed, Apr 2, 2014 at 8:47 AM,  buil...@flonkings.com wrote:
 Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/81259/

 8 tests failed.
 FAILED:  
 junit.framework.TestSuite.org.apache.lucene.codecs.lucene45.TestLucene45DocValuesFormat

 Error Message:
 Suite timeout exceeded (= 720 msec).

 Stack Trace:
 java.lang.Exception: Suite timeout exceeded (= 720 msec).
 at __randomizedtesting.SeedInfo.seed([7362FE36DE729D42]:0)


 REGRESSION:  
 org.apache.lucene.codecs.lucene45.TestLucene45DocValuesFormat.testSortedSetVariableLengthVsUninvertedField

 Error Message:
 Test abandoned because suite timeout was reached.

 Stack Trace:
 java.lang.Exception: Test abandoned because suite timeout was reached.
 at __randomizedtesting.SeedInfo.seed([7362FE36DE729D42]:0)


 REGRESSION:  
 org.apache.lucene.util.junitcompat.TestFailOnFieldCacheInsanity.testFailOnFieldCacheInsanity

 Error Message:


 Stack Trace:
 java.lang.AssertionError
 at org.junit.Assert.fail(Assert.java:92)
 at org.junit.Assert.assertTrue(Assert.java:43)
 at org.junit.Assert.assertTrue(Assert.java:54)
 at 
 org.apache.lucene.util.junitcompat.TestFailOnFieldCacheInsanity.testFailOnFieldCacheInsanity(TestFailOnFieldCacheInsanity.java:75)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
 at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
 at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
 at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
 at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
 at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
 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.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
 at org.junit.rules.RunRules.evaluate(RunRules.java:18)
 at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
 at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
 at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
 at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
 at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
 at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
 at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
 at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at org.junit.rules.RunRules.evaluate(RunRules.java:18)
 at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
 at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:180)
 at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:276)
 at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:12)


 REGRESSION:  
 org.apache.lucene.util.junitcompat.TestLeaveFilesIfTestFails.testLeaveFilesIfTestFails

 Error Message:
 expected:1 but was:0

 Stack Trace:
 java.lang.AssertionError: expected:1 but was:0
 at org.junit.Assert.fail(Assert.java:93)
 at org.junit.Assert.failNotEquals(Assert.java:647)
 at org.junit.Assert.assertEquals(Assert.java:128)
 at org.junit.Assert.assertEquals(Assert.java:472)
 at org.junit.Assert.assertEquals(Assert.java:456)
 at 
 org.apache.lucene.util.junitcompat.TestLeaveFilesIfTestFails.testLeaveFilesIfTestFails(TestLeaveFilesIfTestFails.java:45)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
 at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
 at 
 

Re: Welcome Alan Woodward to the PMC

[Shalin Shekhar Mangar]

Welcome Alan!

On Wed, Apr 2, 2014 at 5:53 PM, Steve Rowe sar...@gmail.com wrote:
 I'm pleased to announce that Alan Woodward has accepted the PMC's invitation 
 to join.

 Welcome Alan!

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




-- 
Regards,
Shalin Shekhar Mangar.

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

Re: Welcome Alan Woodward to the PMC

[Michael McCandless]

Welcome Alan!

Mike McCandless

http://blog.mikemccandless.com


On Wed, Apr 2, 2014 at 9:11 AM, Shalin Shekhar Mangar
shalinman...@gmail.com wrote:
 Welcome Alan!

 On Wed, Apr 2, 2014 at 5:53 PM, Steve Rowe sar...@gmail.com wrote:
 I'm pleased to announce that Alan Woodward has accepted the PMC's invitation 
 to join.

 Welcome Alan!

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




 --
 Regards,
 Shalin Shekhar Mangar.

 -
 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: Welcome Alan Woodward to the PMC

[Uwe Schindler]

Welcome Alan!

Uwe

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


 -Original Message-
 From: Steve Rowe [mailto:sar...@gmail.com]
 Sent: Wednesday, April 02, 2014 2:23 PM
 To: lucene dev
 Subject: Welcome Alan Woodward to the PMC
 
 I'm pleased to announce that Alan Woodward has accepted the PMC's
 invitation to join.
 
 Welcome Alan!
 
 - Steve
 -
 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: Welcome Alan Woodward to the PMC

[Koji Sekiguchi]

Welcome Alan!

koji

(2014/04/02 21:23), Steve Rowe wrote:

I'm pleased to announce that Alan Woodward has accepted the PMC's invitation to 
join.

Welcome Alan!

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





--
http://soleami.com/blog/comparing-document-classification-functions-of-lucene-and-mahout.html

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

Re: Welcome Alan Woodward to the PMC

[Mark Miller]

Welcome!

-- 
Mark Miller
about.me/markrmiller

On April 2, 2014 at 8:23:53 AM, Steve Rowe (sar...@gmail.com) wrote:

I'm pleased to announce that Alan Woodward has accepted the PMC's invitation to 
join.  

Welcome Alan!  

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

Re: Welcome Alan Woodward to the PMC

[Adrien Grand]

Welcome Alan!

On Wed, Apr 2, 2014 at 3:46 PM, Mark Miller markrmil...@gmail.com wrote:
 Welcome!

 --
 Mark Miller
 about.me/markrmiller

 On April 2, 2014 at 8:23:53 AM, Steve Rowe (sar...@gmail.com) wrote:

 I'm pleased to announce that Alan Woodward has accepted the PMC's invitation
 to join.

 Welcome Alan!

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




-- 
Adrien

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

Re: Welcome Alan Woodward to the PMC

[david.w.smi...@gmail.com]

Welcome Alan!
~ David


On Wed, Apr 2, 2014 at 8:23 AM, Steve Rowe sar...@gmail.com wrote:

 I'm pleased to announce that Alan Woodward has accepted the PMC's
 invitation to join.

 Welcome Alan!

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

[ANNOUNCE] Apache Solr 4.7.1 released

[Steve Rowe]

April 2014, Apache Solr™ 4.7.1 available

The Lucene PMC is pleased to announce the release of Apache Solr 4.7.1

Solr is the popular, blazing fast, open source NoSQL search platform from the 
Apache Lucene project. Its major features include powerful full-text search, 
hit highlighting, faceted search, dynamic clustering, database integration, 
rich document (e.g., Word, PDF) handling, and geospatial search. Solr is highly 
scalable, providing fault tolerant distributed search and indexing, and powers 
the search and navigation features of many of the world's largest internet 
sites.

Solr 4.7.1 is available for immediate download at:

http://lucene.apache.org/solr/mirrors-solr-latest-redir.html 

Solr 4.7.1 includes 28 bug fixes and one new configuration setting, as well as 
Lucene 4.7.1 and its bug fixes.

See the CHANGES.txt file included with the release for a full list of changes 
and further details.

Please report any feedback to the mailing lists 
(http://lucene.apache.org/solr/discussion.html)

Note: The Apache Software Foundation uses an extensive mirroring network for 
distributing releases. It is possible that the mirror you are using may not 
have replicated the release yet. If that is the case, please try another 
mirror. This also goes for Maven access.


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

[ANNOUNCE] Apache Lucene 4.7.1 released

[Steve Rowe]

April 2014, Apache Lucene™ 4.7.1 available 

The Lucene PMC is pleased to announce the release of Apache Lucene 4.7.1

Apache Lucene is a high-performance, full-featured text search engine library 
written entirely in Java. It is a technology suitable for nearly any 
application that requires full-text search, especially cross-platform.

The release is available for immediate download at:

http://lucene.apache.org/core/mirrors-core-latest-redir.html 

Lucene 4.7.1 includes 14 bug fixes; one build improvement; and one change in 
runtime behavior: AutomatonQuery.equals is no longer implemented as accepts 
same language.

See the CHANGES.txt file included with the release for a full list of changes 
and further details.

Please report any feedback to the mailing lists 
(http://lucene.apache.org/core/discussion.html)

Note: The Apache Software Foundation uses an extensive mirroring network for 
distributing releases. It is possible that the mirror you are using may not 
have replicated the release yet. If that is the case, please try another 
mirror. This also goes for Maven access.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Alan Woodward to the PMC

[Shai Erera]

Welcome!


On Wed, Apr 2, 2014 at 5:03 PM, david.w.smi...@gmail.com 
david.w.smi...@gmail.com wrote:

 Welcome Alan!
 ~ David


 On Wed, Apr 2, 2014 at 8:23 AM, Steve Rowe sar...@gmail.com wrote:

 I'm pleased to announce that Alan Woodward has accepted the PMC's
 invitation to join.

 Welcome Alan!

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

[jira] [Closed] (SOLR-5947) solr doesnt work

[Erick Erickson (JIRA)]

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

Erick Erickson closed SOLR-5947.


Resolution: Invalid

 solr doesnt work
 

 Key: SOLR-5947
 URL: https://issues.apache.org/jira/browse/SOLR-5947
 Project: Solr
  Issue Type: Bug
  Components: contrib - Solr Cell (Tika extraction)
Affects Versions: 4.7
 Environment: Win7 64x
 Tomcat 8
Reporter: Ian Ding
   Original Estimate: 48h
  Remaining Estimate: 48h

 i can see the icon of solr, the sunny icon, while nothing is working, 
 including the dashboard. 
 if it does work, I could read the system monitor on the right side of the 
 interface, at least..but it did't show any number.



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

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

[jira] [Commented] (LUCENE-4246) Fix IndexWriter.close() to not commit or wait for pending merges

[Simon Willnauer (JIRA)]

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

Simon Willnauer commented on LUCENE-4246:
-

I want to revisit this for 4.8! We recently fixed rollback and given what 
rollback looks like now I think it should actually be called close since this 
is what it does it flushes all stuff and shuts IW down. IMO that is exactly 
what I would expect close to do. Yet, the simplest solution to this issue would 
be rename close to commitAndClose() and rollback to close() and we are good to 
go. I guess it's not going to be that simple but after I ran into the issue 
today that somebody used a NoMergeScheduler and IW#close() was waiting forever 
right here:

{code}
- timed waiting on org.apache.lucene.index.IndexWriter@439740e3
at org.apache.lucene.index.IndexWriter.doWait(IndexWriter.java:4366)
at 
org.apache.lucene.index.IndexWriter.waitForMerges(IndexWriter.java:2289)
at 
org.apache.lucene.index.IndexWriter.finishMerges(IndexWriter.java:2273)
at 
org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1015)
at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:932)
{code}

I am even more convinced that we have to fix this soon though.

 Fix IndexWriter.close() to not commit or wait for pending merges
 

 Key: LUCENE-4246
 URL: https://issues.apache.org/jira/browse/LUCENE-4246
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Assignee: Robert Muir
 Fix For: 4.8






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

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

[jira] [Updated] (SOLR-5868) HttpClient should be configured to use ALLOW_ALL_HOSTNAME hostname verifier to simplify SSL setup

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-5868:
-

Fix Version/s: (was: 4.7.1)

 HttpClient should be configured to use ALLOW_ALL_HOSTNAME hostname verifier 
 to simplify SSL setup
 -

 Key: SOLR-5868
 URL: https://issues.apache.org/jira/browse/SOLR-5868
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.7
Reporter: Steve Davids
Assignee: Mark Miller
 Fix For: 4.8, 5.0

 Attachments: SOLR-5868.patch, SOLR-5868.patch


 The default HttpClient hostname verifier is the 
 BROWSER_COMPATIBLE_HOSTNAME_VERIFIER which verifies the hostname that is 
 being connected to matches the hostname presented within the certificate. 
 This is meant to protect clients that are making external requests out across 
 the internet, but requests within the the SOLR cluster should be trusted and 
 can be relaxed to simplify the SSL/certificate setup process.



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

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

[jira] [Resolved] (SOLR-5824) Merge up Solr MapReduce contrib code to latest external changes.

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-5824.
--

Resolution: Fixed

 Merge up Solr MapReduce contrib code to latest external changes.
 

 Key: SOLR-5824
 URL: https://issues.apache.org/jira/browse/SOLR-5824
 Project: Solr
  Issue Type: Task
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.8, 5.0, 4.7.1

 Attachments: SOLR-5824.patch


 There are a variety of changes in the mapreduce contrib code that have 
 occurred while getting the initial stuff committed - they need to be merged 
 in.



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

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

[jira] [Resolved] (SOLR-5907) The hdfs write cache can still cause a reader to see a corrupted state.

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-5907.
--

Resolution: Fixed

 The hdfs write cache can still cause a reader to see a corrupted state.
 ---

 Key: SOLR-5907
 URL: https://issues.apache.org/jira/browse/SOLR-5907
 Project: Solr
  Issue Type: Bug
  Components: hdfs
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Critical
 Fix For: 4.8, 5.0, 4.7.1

 Attachments: SOLR-5907.patch, SOLR-5907.patch


 We should disable it by default and probably take it out of the default 
 configs until we can track down the issues with it.



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

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

[jira] [Resolved] (SOLR-5811) The Overseer will retry work items until success.

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-5811.
--

Resolution: Fixed

 The Overseer will retry work items until success.
 -

 Key: SOLR-5811
 URL: https://issues.apache.org/jira/browse/SOLR-5811
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.8, 5.0, 4.7.1

 Attachments: SOLR-5811.patch, SOLR-5811.patch


 This means that if you get a bad item in the ZK distributed queue, it can 
 lock up your Overseer as it continuously retries the bad command. The 
 workaround is to manually clear the Overseer ZK queue.



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

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

[jira] [Resolved] (SOLR-5734) We should use System.nanoTime rather than System.currentTimeMillis when calculating elapsed time.

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-5734.
--

Resolution: Fixed

 We should use System.nanoTime rather than System.currentTimeMillis when 
 calculating elapsed time. 
 --

 Key: SOLR-5734
 URL: https://issues.apache.org/jira/browse/SOLR-5734
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.8, 5.0, 4.7.1

 Attachments: SOLR-5734.patch


 As brought up by [~andyetitmoves] in SOLR-5721.



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

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

Re: Welcome Alan Woodward to the PMC

[Erick Erickson]

Hey hey hey! Welcome Alan.

On Wed, Apr 2, 2014 at 10:25 AM, Shai Erera ser...@gmail.com wrote:
 Welcome!


 On Wed, Apr 2, 2014 at 5:03 PM, david.w.smi...@gmail.com
 david.w.smi...@gmail.com wrote:

 Welcome Alan!
 ~ David


 On Wed, Apr 2, 2014 at 8:23 AM, Steve Rowe sar...@gmail.com wrote:

 I'm pleased to announce that Alan Woodward has accepted the PMC's
 invitation to join.

 Welcome Alan!

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




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

[jira] [Commented] (SOLR-5859) Harden the Overseer restart mechanism

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-5859 Harden Overseer restart

 Harden the Overseer restart mechanism
 -

 Key: SOLR-5859
 URL: https://issues.apache.org/jira/browse/SOLR-5859
 Project: Solr
  Issue Type: Improvement
Reporter: Noble Paul
Assignee: Noble Paul
 Attachments: SOLR-5859.patch, SOLR-5859.patch, SOLR-5859.patch


 SOLR-5476 depends on Overseer restart.The current strategy is to remove the 
 zk node for leader election and wait for STATUS_UPDATE_DELAY +100 ms and  
 start the new overseer.
 Though overseer ops are short running,  it is not a 100% foolproof strategy 
 because if an operation takes longer than the wait period there can be race 
 condition. 



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

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

[jira] [Updated] (SOLR-5859) Harden the Overseer restart mechanism

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-5859:
-

Attachment: SOLR-5859.patch

moved the final check in Overseer loop to a new thread to avoid interrupted 
exceptions

 Harden the Overseer restart mechanism
 -

 Key: SOLR-5859
 URL: https://issues.apache.org/jira/browse/SOLR-5859
 Project: Solr
  Issue Type: Improvement
Reporter: Noble Paul
Assignee: Noble Paul
 Attachments: SOLR-5859.patch, SOLR-5859.patch, SOLR-5859.patch, 
 SOLR-5859.patch


 SOLR-5476 depends on Overseer restart.The current strategy is to remove the 
 zk node for leader election and wait for STATUS_UPDATE_DELAY +100 ms and  
 start the new overseer.
 Though overseer ops are short running,  it is not a 100% foolproof strategy 
 because if an operation takes longer than the wait period there can be race 
 condition. 



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

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

[jira] [Updated] (SOLR-5943) SolrCmdDistributor does not distribute the openSearcher parameter

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-5943:


Attachment: SOLR-5943.patch

Thanks Ludovic.

I reverted your changes to the public methods because we need to preserve 
back-compatibility. I added a new method which accepts a openSearcher boolean 
value instead. This patch applies to trunk. I'll commit shortly.

 SolrCmdDistributor does not distribute the openSearcher parameter
 -

 Key: SOLR-5943
 URL: https://issues.apache.org/jira/browse/SOLR-5943
 Project: Solr
  Issue Type: Bug
  Components: update
Affects Versions: 4.6.1, 4.7
Reporter: ludovic Boutros
Assignee: Shalin Shekhar Mangar
 Fix For: 4.8, 5.0

 Attachments: SOLR-5943.patch, SOLR-5943.patch


 The openSearcher parameter in a commit command is totally ignored by the 
 SolrCmdDistributor :
 {code:title=SolrCmdDistributor.java|borderStyle=solid}
  void addCommit(UpdateRequest ureq, CommitUpdateCommand cmd) {
 if (cmd == null) return;
 ureq.setAction(cmd.optimize ? AbstractUpdateRequest.ACTION.OPTIMIZE
 : AbstractUpdateRequest.ACTION.COMMIT, false, cmd.waitSearcher, 
 cmd.maxOptimizeSegments, cmd.softCommit, cmd.expungeDeletes);
   }{code}
 I think the SolrJ API should take this parameter in account as well.



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

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

[jira] [Commented] (LUCENE-4246) Fix IndexWriter.close() to not commit or wait for pending merges

[Shai Erera (JIRA)]

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

Shai Erera commented on LUCENE-4246:


bq. I ran into the issue today that somebody used a NoMergeScheduler and 
IW#close() was waiting forever

I've been struck by that too!! and therefore I stopped using NoMergeScheduler, 
and I use NoMergePolicy instead.

bq. We recently fixed rollback and given what rollback looks like now I think 
it should actually be called close since this is what it does it flushes all 
stuff and shuts IW down

I think we should separate rollback()/commit() from close(). When you call 
close, you should not silently lose changes -- you have to be explicit about 
losing them (rollback()) or committing them (commit()). And we should 
definitely not break existing apps who call close() relying on committing 
stuff. So if we:

* Detect in close() that you have uncommitted changes or running merges and 
throw an exception
* Let you separately call commit/rollback, waitForMerges/abortMerges and close
* Add a sugar commitAndClose (which waits for merges? or takes a boolean?)

Then I think we can make close() just close and releases resources, including 
the lock, at all costs (basically what was done just recently). We give 
existing apps a very easy migration path -- call commitAndClose(). And we let 
more expert apps to decide what to do about merges and pending changes 
separately from each other and closing the writer.

 Fix IndexWriter.close() to not commit or wait for pending merges
 

 Key: LUCENE-4246
 URL: https://issues.apache.org/jira/browse/LUCENE-4246
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Assignee: Robert Muir
 Fix For: 4.8






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

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

Re: Welcome Alan Woodward to the PMC

[Alan Woodward]

Thanks everyone.  I'll try and use my newly-acquired superpowers for good. :-)

Alan Woodward
www.flax.co.uk


On 2 Apr 2014, at 15:25, Shai Erera wrote:

 Welcome!
 
 
 On Wed, Apr 2, 2014 at 5:03 PM, david.w.smi...@gmail.com 
 david.w.smi...@gmail.com wrote:
 Welcome Alan!
 ~ David
 
 
 On Wed, Apr 2, 2014 at 8:23 AM, Steve Rowe sar...@gmail.com wrote:
 I'm pleased to announce that Alan Woodward has accepted the PMC's invitation 
 to join.
 
 Welcome Alan!
 
 - Steve
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 
 
 

[jira] [Commented] (SOLR-5943) SolrCmdDistributor does not distribute the openSearcher parameter

[ASF subversion and git services (JIRA)]

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

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

Commit 1584083 from sha...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1584083 ]

SOLR-5943: SolrCmdDistributor does not distribute the openSearcher parameter

 SolrCmdDistributor does not distribute the openSearcher parameter
 -

 Key: SOLR-5943
 URL: https://issues.apache.org/jira/browse/SOLR-5943
 Project: Solr
  Issue Type: Bug
  Components: update
Affects Versions: 4.6.1, 4.7
Reporter: ludovic Boutros
Assignee: Shalin Shekhar Mangar
 Fix For: 4.8, 5.0

 Attachments: SOLR-5943.patch, SOLR-5943.patch


 The openSearcher parameter in a commit command is totally ignored by the 
 SolrCmdDistributor :
 {code:title=SolrCmdDistributor.java|borderStyle=solid}
  void addCommit(UpdateRequest ureq, CommitUpdateCommand cmd) {
 if (cmd == null) return;
 ureq.setAction(cmd.optimize ? AbstractUpdateRequest.ACTION.OPTIMIZE
 : AbstractUpdateRequest.ACTION.COMMIT, false, cmd.waitSearcher, 
 cmd.maxOptimizeSegments, cmd.softCommit, cmd.expungeDeletes);
   }{code}
 I think the SolrJ API should take this parameter in account as well.



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

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

[jira] [Commented] (SOLR-5943) SolrCmdDistributor does not distribute the openSearcher parameter

[ASF subversion and git services (JIRA)]

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

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

Commit 1584084 from sha...@apache.org in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1584084 ]

SOLR-5943: SolrCmdDistributor does not distribute the openSearcher parameter

 SolrCmdDistributor does not distribute the openSearcher parameter
 -

 Key: SOLR-5943
 URL: https://issues.apache.org/jira/browse/SOLR-5943
 Project: Solr
  Issue Type: Bug
  Components: update
Affects Versions: 4.6.1, 4.7
Reporter: ludovic Boutros
Assignee: Shalin Shekhar Mangar
 Fix For: 4.8, 5.0

 Attachments: SOLR-5943.patch, SOLR-5943.patch


 The openSearcher parameter in a commit command is totally ignored by the 
 SolrCmdDistributor :
 {code:title=SolrCmdDistributor.java|borderStyle=solid}
  void addCommit(UpdateRequest ureq, CommitUpdateCommand cmd) {
 if (cmd == null) return;
 ureq.setAction(cmd.optimize ? AbstractUpdateRequest.ACTION.OPTIMIZE
 : AbstractUpdateRequest.ACTION.COMMIT, false, cmd.waitSearcher, 
 cmd.maxOptimizeSegments, cmd.softCommit, cmd.expungeDeletes);
   }{code}
 I think the SolrJ API should take this parameter in account as well.



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

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

[jira] [Commented] (LUCENE-4246) Fix IndexWriter.close() to not commit or wait for pending merges

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-4246:


bq. I want to revisit this for 4.8! 

+1 to have close really close nomatter what, just like rollback really 
rollsback nomatter what (throw first exc), except I think the user must 
separately (explicitly) discard pending changes / abort running merges.

 Fix IndexWriter.close() to not commit or wait for pending merges
 

 Key: LUCENE-4246
 URL: https://issues.apache.org/jira/browse/LUCENE-4246
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Assignee: Robert Muir
 Fix For: 4.8






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

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

[jira] [Commented] (SOLR-5859) Harden the Overseer restart mechanism

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-5859 Harden Overseer restart

 Harden the Overseer restart mechanism
 -

 Key: SOLR-5859
 URL: https://issues.apache.org/jira/browse/SOLR-5859
 Project: Solr
  Issue Type: Improvement
Reporter: Noble Paul
Assignee: Noble Paul
 Attachments: SOLR-5859.patch, SOLR-5859.patch, SOLR-5859.patch, 
 SOLR-5859.patch


 SOLR-5476 depends on Overseer restart.The current strategy is to remove the 
 zk node for leader election and wait for STATUS_UPDATE_DELAY +100 ms and  
 start the new overseer.
 Though overseer ops are short running,  it is not a 100% foolproof strategy 
 because if an operation takes longer than the wait period there can be race 
 condition. 



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

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

[jira] [Resolved] (SOLR-5943) SolrCmdDistributor does not distribute the openSearcher parameter

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar resolved SOLR-5943.
-

Resolution: Fixed

Thanks Ludovic!

 SolrCmdDistributor does not distribute the openSearcher parameter
 -

 Key: SOLR-5943
 URL: https://issues.apache.org/jira/browse/SOLR-5943
 Project: Solr
  Issue Type: Bug
  Components: update
Affects Versions: 4.6.1, 4.7
Reporter: ludovic Boutros
Assignee: Shalin Shekhar Mangar
 Fix For: 4.8, 5.0

 Attachments: SOLR-5943.patch, SOLR-5943.patch


 The openSearcher parameter in a commit command is totally ignored by the 
 SolrCmdDistributor :
 {code:title=SolrCmdDistributor.java|borderStyle=solid}
  void addCommit(UpdateRequest ureq, CommitUpdateCommand cmd) {
 if (cmd == null) return;
 ureq.setAction(cmd.optimize ? AbstractUpdateRequest.ACTION.OPTIMIZE
 : AbstractUpdateRequest.ACTION.COMMIT, false, cmd.waitSearcher, 
 cmd.maxOptimizeSegments, cmd.softCommit, cmd.expungeDeletes);
   }{code}
 I think the SolrJ API should take this parameter in account as well.



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

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

[jira] [Resolved] (SOLR-5859) Harden the Overseer restart mechanism

[Noble Paul (JIRA)]

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

Noble Paul resolved SOLR-5859.
--

   Resolution: Fixed
Fix Version/s: 5.0
   4.8

 Harden the Overseer restart mechanism
 -

 Key: SOLR-5859
 URL: https://issues.apache.org/jira/browse/SOLR-5859
 Project: Solr
  Issue Type: Improvement
Reporter: Noble Paul
Assignee: Noble Paul
 Fix For: 4.8, 5.0

 Attachments: SOLR-5859.patch, SOLR-5859.patch, SOLR-5859.patch, 
 SOLR-5859.patch


 SOLR-5476 depends on Overseer restart.The current strategy is to remove the 
 zk node for leader election and wait for STATUS_UPDATE_DELAY +100 ms and  
 start the new overseer.
 Though overseer ops are short running,  it is not a 100% foolproof strategy 
 because if an operation takes longer than the wait period there can be race 
 condition. 



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

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

[jira] [Commented] (SOLR-5943) SolrCmdDistributor does not distribute the openSearcher parameter

[ludovic Boutros (JIRA)]

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

ludovic Boutros commented on SOLR-5943:
---

Excellent, thank you Shalin.

 SolrCmdDistributor does not distribute the openSearcher parameter
 -

 Key: SOLR-5943
 URL: https://issues.apache.org/jira/browse/SOLR-5943
 Project: Solr
  Issue Type: Bug
  Components: update
Affects Versions: 4.6.1, 4.7
Reporter: ludovic Boutros
Assignee: Shalin Shekhar Mangar
 Fix For: 4.8, 5.0

 Attachments: SOLR-5943.patch, SOLR-5943.patch


 The openSearcher parameter in a commit command is totally ignored by the 
 SolrCmdDistributor :
 {code:title=SolrCmdDistributor.java|borderStyle=solid}
  void addCommit(UpdateRequest ureq, CommitUpdateCommand cmd) {
 if (cmd == null) return;
 ureq.setAction(cmd.optimize ? AbstractUpdateRequest.ACTION.OPTIMIZE
 : AbstractUpdateRequest.ACTION.COMMIT, false, cmd.waitSearcher, 
 cmd.maxOptimizeSegments, cmd.softCommit, cmd.expungeDeletes);
   }{code}
 I think the SolrJ API should take this parameter in account as well.



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

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

[jira] [Updated] (SOLR-5473) Make one state.json per collection

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-5473:


Attachment: SOLR-5473-74.patch

Patch updated to trunk after SOLR-5859 commit.

 Make one state.json per collection
 --

 Key: SOLR-5473
 URL: https://issues.apache.org/jira/browse/SOLR-5473
 Project: Solr
  Issue Type: Sub-task
  Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
 Attachments: SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 ec2-23-20-119-52_solr.log, ec2-50-16-38-73_solr.log


 As defined in the parent issue, store the states of each collection under 
 /collections/collectionname/state.json node



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

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

Re: [JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.7.0_51) - Build # 3917 - Failure!

[Chris Hostetter]

This is a new test (committed yesterday) but it does't create/write/modify 
any files on disk directly -- just using the regular distributed test 
setup.

Can anyone with a windows machine reproduce this failure to cleanup the 
workspace?

: 1 tests failed. FAILED:  
: 
junit.framework.TestSuite.org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest
: 
: Error Message:  WARNING: best effort to remove 
: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\.\solrtest-DistribDocExpirationUpdateProcessorTest-1396449841389
 
: FAILED !

Possibly related is that at one point one node attempts to do log replay 
and encounteres a FileNotFoundException: _0.si ... no idea why/how that 
could happen, but it definitley smells fishy.  And of course: right after 
the FNFE start, we start seeing lots of 500 errors from other nodes trying 
to communicate with this node whose index is missing files.




(FWIW: There's also an NPE getting logged here indicating that there is no 
Leader at one point with the processor runs.  That NPE shouldn't have 
caused any sort of problem -- it's in an islated Runable that logs the 
error and ignores -- but i'll fix the code to be more careful.  In 
anycase, the lack of a leader at that point may be indicitive of some 
underlying problem that also then lead to the FNFE and ultimatley the 
cleanup failure?



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

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

[jira] [Created] (SOLR-5948) Strange jenkins failure: *.si file not found in the middle of cloud test

[Hoss Man (JIRA)]

Hoss Man created SOLR-5948:
--

 Summary: Strange jenkins failure: *.si file not found in the 
middle of cloud test
 Key: SOLR-5948
 URL: https://issues.apache.org/jira/browse/SOLR-5948
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man






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

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

[jira] [Updated] (SOLR-5948) Strange jenkins failure: *.si file not found in the middle of cloud test

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-5948:
---

Attachment: SOLR-5948.jenkins.log.txt

http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/3917/
Java: 32bit/jdk1.7.0_51 -server -XX:+UseConcMarkSweepGC
Revision: 1583802

Ultimate failure was...

{noformat}
java.lang.AssertionError:  WARNING: best effort to remove
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\.\solrtest-DistribDocExpirati
onUpdateProcessorTest-1396449841389 FAILED !
at __randomizedtesting.SeedInfo.seed([F5058863C2A67238]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:217)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
{noformat}

But in the middle of the test we start seeing problems do to index files not 
being found that probably cascaded into other problems...

{noformat}
   [junit4]   2 221731 T442 C271 P49333 oasup.LogUpdateProcessor.finish 
[collection1] webapp= path=/update params={CONTROL=TRUEwt=javabinversion=2} 
{add=[72 (1464283821849444352)]} 0 1
   [junit4]   2 221731 T548 C273 P49381 oasu.UpdateLog$LogReplayer.doReplay 
WARN Starting log replay 
tlog{file=.\solrtest-DistribDocExpirationUpdateProcessorTest-1396449841389\org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest-1396449841399\jetty4\tlog\tlog.000
 refcount=2} active=true starting pos=1472
   [junit4]   2 221742 T548 C273 P49381 oasu.DirectUpdateHandler2.commit start 
commit{flags=2,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
   [junit4]   2 221745 T548 C273 P49381 oasu.UpdateLog$LogReplayer.doReplay 
ERROR Replay exception: final commit. java.io.FileNotFoundException: _0.si
   [junit4]   2at 
org.apache.lucene.store.RAMDirectory.fileLength(RAMDirectory.java:134)
   [junit4]   2at 
org.apache.lucene.store.MockDirectoryWrapper.fileLength(MockDirectoryWrapper.java:886)
   [junit4]   2at 
org.apache.lucene.index.SegmentCommitInfo.sizeInBytes(SegmentCommitInfo.java:139)
   [junit4]   2at 
org.apache.lucene.index.LogMergePolicy.sizeBytes(LogMergePolicy.java:175)
   [junit4]   2at 
org.apache.lucene.index.LogByteSizeMergePolicy.size(LogByteSizeMergePolicy.java:47)
   [junit4]   2at 
org.apache.lucene.index.LogMergePolicy.findMerges(LogMergePolicy.java:478)
   [junit4]   2at 
org.apache.solr.util.RandomMergePolicy.findMerges(RandomMergePolicy.java:84)
   [junit4]   2at 
org.apache.lucene.index.IndexWriter.updatePendingMerges(IndexWriter.java:2016)
   [junit4]   2at 
org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1985)
   [junit4]   2at 
org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2923)
   [junit4]   2at 
org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3032)
   [junit4]   2at 
org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2999)
   [junit4]   2at 
org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:578)
{noformat}

 Strange jenkins failure: *.si file not found in the middle of cloud test
 

 Key: SOLR-5948
 URL: https://issues.apache.org/jira/browse/SOLR-5948
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
 Attachments: SOLR-5948.jenkins.log.txt






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

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

Re: [JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.7.0_51) - Build # 3917 - Failure!

[Chris Hostetter]

Tracked in SOLR-5948 so we don't lose the logs due ot jenkins job 
expiration...

https://issues.apache.org/jira/browse/SOLR-5948


: Date: Wed, 2 Apr 2014 09:56:19 -0700 (MST)
: From: Chris Hostetter hossman_luc...@fucit.org
: To: dev@lucene.apache.org
: Subject: Re: [JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.7.0_51) - Build #
:  3917 - Failure!
: 
: 
: This is a new test (committed yesterday) but it does't create/write/modify 
: any files on disk directly -- just using the regular distributed test 
: setup.
: 
: Can anyone with a windows machine reproduce this failure to cleanup the 
: workspace?
: 
: : 1 tests failed. FAILED:  
: : 
junit.framework.TestSuite.org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest
: : 
: : Error Message:  WARNING: best effort to remove 
: : 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\.\solrtest-DistribDocExpirationUpdateProcessorTest-1396449841389
 
: : FAILED !
: 
: Possibly related is that at one point one node attempts to do log replay 
: and encounteres a FileNotFoundException: _0.si ... no idea why/how that 
: could happen, but it definitley smells fishy.  And of course: right after 
: the FNFE start, we start seeing lots of 500 errors from other nodes trying 
: to communicate with this node whose index is missing files.
: 
: 
: 
: 
: (FWIW: There's also an NPE getting logged here indicating that there is no 
: Leader at one point with the processor runs.  That NPE shouldn't have 
: caused any sort of problem -- it's in an islated Runable that logs the 
: error and ignores -- but i'll fix the code to be more careful.  In 
: anycase, the lack of a leader at that point may be indicitive of some 
: underlying problem that also then lead to the FNFE and ultimatley the 
: cleanup failure?
: 
: 
: 
: -Hoss
: http://www.lucidworks.com/
: 

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

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

[jira] [Created] (SOLR-5949) Stopwords in Boolean Query Result in invalid query

[Bob Laferriere (JIRA)]

Bob Laferriere created SOLR-5949:


 Summary: Stopwords in Boolean Query Result in invalid query
 Key: SOLR-5949
 URL: https://issues.apache.org/jira/browse/SOLR-5949
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 4.3
 Environment: Linux
Reporter: Bob Laferriere


This seems a repeat of SOLR-261 which was fixed in 1.3 but I am seeing the same 
behavior described. When I have a stopword in a boolean query the resulting 
query is invalid. 

e.g. Document -- No Smoking Sign
Stopword: No

Query:No AND Smoking AND Sign

The resultant query is a boolean query with a blank field so an empty boolean 
query. This is expanding as ? Smoking Sign which then leads to no matches as 
? AND Smoking AND sign has no match.

The expected behavior is to remove the empty boolean clause from the query. In 
the Analysis tool the parsing showing that No AND Smoking AND Sign analyzes 
to Smoke Sign. I would expect the same behavior by the QueryParser, but this 
is not true. The real parsed query is trying to do the following: empty 
boolean query Smoke Sign.

The only workaround is to never allow stopwords in the query or turn off 
stopwords entirely.



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

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

[jira] [Commented] (SOLR-5795) Option to periodically delete docs based on an expiration field -- or ttl specified when indexed.

[ASF subversion and git services (JIRA)]

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

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

Commit 1584097 from hoss...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1584097 ]

SOLR-5795: harden leader check to log cleanly (no NPE) in transient situations 
when there is no leader due to election in progress

 Option to periodically delete docs based on an expiration field -- or ttl 
 specified when indexed.
 -

 Key: SOLR-5795
 URL: https://issues.apache.org/jira/browse/SOLR-5795
 Project: Solr
  Issue Type: New Feature
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 4.8, 5.0

 Attachments: SOLR-5795.patch, SOLR-5795.patch, SOLR-5795.patch, 
 SOLR-5795.patch, SOLR-5795.patch, SOLR-5795.patch


 A question I get periodically from people is how to automatically remove 
 documents from a collection at a certain time (or after a certain amount of 
 time).  
 Excluding from search results using a filter query on a date field is 
 trivial, but you still have to periodically send a deleteByQuery to clean up 
 those older expired documents.  And in the case where you want all 
 documents to auto-expire some fixed amount of time when they were indexed, 
 you still have to setup a simple UpdateProcessorto set that expiration date.  
 So i've been thinking it would be nice if there was a simple way to configure 
 solr to do it all for you.



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

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

[jira] [Commented] (SOLR-5795) Option to periodically delete docs based on an expiration field -- or ttl specified when indexed.

[ASF subversion and git services (JIRA)]

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

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

Commit 1584099 from hoss...@apache.org in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1584099 ]

SOLR-5795: harden leader check to log cleanly (no NPE) in transient situations 
when there is no leader due to election in progress (merge r1584097)

 Option to periodically delete docs based on an expiration field -- or ttl 
 specified when indexed.
 -

 Key: SOLR-5795
 URL: https://issues.apache.org/jira/browse/SOLR-5795
 Project: Solr
  Issue Type: New Feature
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 4.8, 5.0

 Attachments: SOLR-5795.patch, SOLR-5795.patch, SOLR-5795.patch, 
 SOLR-5795.patch, SOLR-5795.patch, SOLR-5795.patch


 A question I get periodically from people is how to automatically remove 
 documents from a collection at a certain time (or after a certain amount of 
 time).  
 Excluding from search results using a filter query on a date field is 
 trivial, but you still have to periodically send a deleteByQuery to clean up 
 those older expired documents.  And in the case where you want all 
 documents to auto-expire some fixed amount of time when they were indexed, 
 you still have to setup a simple UpdateProcessorto set that expiration date.  
 So i've been thinking it would be nice if there was a simple way to configure 
 solr to do it all for you.



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

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

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.7.0_51) - Build # 9969 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9969/
Java: 64bit/jdk1.7.0_51 -XX:+UseCompressedOops -XX:+UseSerialGC 
-XX:-UseSuperWord

All tests passed

Build Log:
[...truncated 52512 lines...]
-ecj-javadoc-lint-src:
 [ecj-lint] Compiling 713 source files
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/lib/org.restlet-2.1.1.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/lib/org.restlet.ext.servlet-2.1.1.jar
 [ecj-lint] --
 [ecj-lint] 1. ERROR in 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/java/org/apache/solr/cloud/OverseerCollectionProcessor.java
 (at line 662)
 [ecj-lint] * @param clusterState
 [ecj-lint]  
 [ecj-lint] Javadoc: Description expected after this reference
 [ecj-lint] --
 [ecj-lint] 1 problem (1 error)

BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:467: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:63: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:562: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1768:
 The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1802:
 Compile failed; see the compiler error output for details.

Total time: 69 minutes 10 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 64bit/jdk1.7.0_51 -XX:+UseCompressedOops 
-XX:+UseSerialGC -XX:-UseSuperWord
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure



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

[jira] [Commented] (SOLR-5859) Harden the Overseer restart mechanism

[ASF subversion and git services (JIRA)]

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

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

Commit 1584108 from [~steve_rowe] in branch 'dev/trunk'
[ https://svn.apache.org/r1584108 ]

SOLR-5859: add OCP.getCollectionStatus() param description for 'clusterState' 
to stop 'ant precommit' bitching 'Javadoc: Description expected after this 
reference' and failing the build

 Harden the Overseer restart mechanism
 -

 Key: SOLR-5859
 URL: https://issues.apache.org/jira/browse/SOLR-5859
 Project: Solr
  Issue Type: Improvement
Reporter: Noble Paul
Assignee: Noble Paul
 Fix For: 4.8, 5.0

 Attachments: SOLR-5859.patch, SOLR-5859.patch, SOLR-5859.patch, 
 SOLR-5859.patch


 SOLR-5476 depends on Overseer restart.The current strategy is to remove the 
 zk node for leader election and wait for STATUS_UPDATE_DELAY +100 ms and  
 start the new overseer.
 Though overseer ops are short running,  it is not a 100% foolproof strategy 
 because if an operation takes longer than the wait period there can be race 
 condition. 



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

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

[jira] [Reopened] (SOLR-5859) Harden the Overseer restart mechanism

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar reopened SOLR-5859:
-


Re-opening because this seems to have reverted parts of SOLR-5908

 Harden the Overseer restart mechanism
 -

 Key: SOLR-5859
 URL: https://issues.apache.org/jira/browse/SOLR-5859
 Project: Solr
  Issue Type: Improvement
Reporter: Noble Paul
Assignee: Noble Paul
 Fix For: 4.8, 5.0

 Attachments: SOLR-5859.patch, SOLR-5859.patch, SOLR-5859.patch, 
 SOLR-5859.patch


 SOLR-5476 depends on Overseer restart.The current strategy is to remove the 
 zk node for leader election and wait for STATUS_UPDATE_DELAY +100 ms and  
 start the new overseer.
 Though overseer ops are short running,  it is not a 100% foolproof strategy 
 because if an operation takes longer than the wait period there can be race 
 condition. 



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

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

[jira] [Commented] (SOLR-5859) Harden the Overseer restart mechanism

[ASF subversion and git services (JIRA)]

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

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

Commit 1584110 from [~steve_rowe] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1584110 ]

SOLR-5859: add OCP.getCollectionStatus() param description for 'clusterState' 
to stop 'ant precommit' bitching 'Javadoc: Description expected after this 
reference' and failing the build (merged trunk r1584108)

 Harden the Overseer restart mechanism
 -

 Key: SOLR-5859
 URL: https://issues.apache.org/jira/browse/SOLR-5859
 Project: Solr
  Issue Type: Improvement
Reporter: Noble Paul
Assignee: Noble Paul
 Fix For: 4.8, 5.0

 Attachments: SOLR-5859.patch, SOLR-5859.patch, SOLR-5859.patch, 
 SOLR-5859.patch


 SOLR-5476 depends on Overseer restart.The current strategy is to remove the 
 zk node for leader election and wait for STATUS_UPDATE_DELAY +100 ms and  
 start the new overseer.
 Though overseer ops are short running,  it is not a 100% foolproof strategy 
 because if an operation takes longer than the wait period there can be race 
 condition. 



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

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

Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.7.0_51) - Build # 9969 - Failure!

[Steve Rowe]

I committed a fix. - Steve

On Apr 2, 2014, at 1:47 PM, Policeman Jenkins Server jenk...@thetaphi.de 
wrote:

 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9969/
 Java: 64bit/jdk1.7.0_51 -XX:+UseCompressedOops -XX:+UseSerialGC 
 -XX:-UseSuperWord
 
 All tests passed
 
 Build Log:
 [...truncated 52512 lines...]
 -ecj-javadoc-lint-src:
 [ecj-lint] Compiling 713 source files
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
 /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/lib/org.restlet-2.1.1.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
 /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/lib/org.restlet.ext.servlet-2.1.1.jar
 [ecj-lint] --
 [ecj-lint] 1. ERROR in 
 /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/java/org/apache/solr/cloud/OverseerCollectionProcessor.java
  (at line 662)
 [ecj-lint]* @param clusterState
 [ecj-lint] 
 [ecj-lint] Javadoc: Description expected after this reference
 [ecj-lint] --
 [ecj-lint] 1 problem (1 error)
 
 BUILD FAILED
 /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:467: The 
 following error occurred while executing this line:
 /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:63: The 
 following error occurred while executing this line:
 /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:562: The 
 following error occurred while executing this line:
 /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1768:
  The following error occurred while executing this line:
 /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1802:
  Compile failed; see the compiler error output for details.
 
 Total time: 69 minutes 10 seconds
 Build step 'Invoke Ant' marked build as failure
 Description set: Java: 64bit/jdk1.7.0_51 -XX:+UseCompressedOops 
 -XX:+UseSerialGC -XX:-UseSuperWord
 Archiving artifacts
 Recording test results
 Email was triggered for: Failure
 Sending email for trigger: Failure
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org


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

[jira] [Updated] (SOLR-5922) Add Properties and other parameters to SolrJ Collection Admin Request calls

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-5922:


Attachment: SOLR-5922.patch

New patch with 2 test cases.
- I only see these 2 directories getting created 
1. testInstanceDirAsPropertyParam-XYZ/
2. testInstanceDirAsPropertyParam-XYZ/testuLogDirAsPropertyParam-XYZ/

Don't see the dataDir getting created

 Add Properties and other parameters to SolrJ Collection Admin Request calls
 ---

 Key: SOLR-5922
 URL: https://issues.apache.org/jira/browse/SOLR-5922
 Project: Solr
  Issue Type: Improvement
Reporter: Varun Thacker
Assignee: Shalin Shekhar Mangar
 Fix For: 5.0

 Attachments: SOLR-5922.patch, SOLR-5922.patch, SOLR-5922.patch


 SOLR-5208 added functionality for the setting of core.properties key/values 
 at create-time on Collections API.
 We should allow the same behaviour for SolrJ API calls as well.
 Also I want to add get and set methods to be able to add 'instanceDir', 
 'dataDir', 'ulogDir' for a create colleciton call.



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

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

[jira] [Commented] (SOLR-5795) Option to periodically delete docs based on an expiration field -- or ttl specified when indexed.

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-5795:
-

Hoss, instead of slice.getLeader(), you should use ZkStateReader.getLeaderRetry 
method.

 Option to periodically delete docs based on an expiration field -- or ttl 
 specified when indexed.
 -

 Key: SOLR-5795
 URL: https://issues.apache.org/jira/browse/SOLR-5795
 Project: Solr
  Issue Type: New Feature
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 4.8, 5.0

 Attachments: SOLR-5795.patch, SOLR-5795.patch, SOLR-5795.patch, 
 SOLR-5795.patch, SOLR-5795.patch, SOLR-5795.patch


 A question I get periodically from people is how to automatically remove 
 documents from a collection at a certain time (or after a certain amount of 
 time).  
 Excluding from search results using a filter query on a date field is 
 trivial, but you still have to periodically send a deleteByQuery to clean up 
 those older expired documents.  And in the case where you want all 
 documents to auto-expire some fixed amount of time when they were indexed, 
 you still have to setup a simple UpdateProcessorto set that expiration date.  
 So i've been thinking it would be nice if there was a simple way to configure 
 solr to do it all for you.



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

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

[jira] [Commented] (SOLR-5908) Make REQUESTSTATUS call non-blocking and non-blocked

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-5859 removing accidental removal of SOLR-5908 changes

 Make REQUESTSTATUS call non-blocking and non-blocked
 

 Key: SOLR-5908
 URL: https://issues.apache.org/jira/browse/SOLR-5908
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Anshum Gupta
Assignee: Anshum Gupta
 Fix For: 4.8, 5.0

 Attachments: SOLR-5908.patch, SOLR-5908.patch


 Currently REQUESTSTATUS Collection API call is blocked by any other call in 
 the OCP work queue.
 Make it independent and non-blocked/non-blocking.
 This would be handled as a part of having the OCP multi-threaded but I'm 
 opening this issue to explore other possible options of handling this.
 If the final fix happens via SOLR-5681, will resolve it when SOLR-5681 gets 
 resolved.



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

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

[jira] [Commented] (SOLR-5859) Harden the Overseer restart mechanism

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-5859 removing accidental removal of SOLR-5908 changes

 Harden the Overseer restart mechanism
 -

 Key: SOLR-5859
 URL: https://issues.apache.org/jira/browse/SOLR-5859
 Project: Solr
  Issue Type: Improvement
Reporter: Noble Paul
Assignee: Noble Paul
 Fix For: 4.8, 5.0

 Attachments: SOLR-5859.patch, SOLR-5859.patch, SOLR-5859.patch, 
 SOLR-5859.patch


 SOLR-5476 depends on Overseer restart.The current strategy is to remove the 
 zk node for leader election and wait for STATUS_UPDATE_DELAY +100 ms and  
 start the new overseer.
 Though overseer ops are short running,  it is not a 100% foolproof strategy 
 because if an operation takes longer than the wait period there can be race 
 condition. 



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

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

[jira] [Commented] (SOLR-5859) Harden the Overseer restart mechanism

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-5859 removing accidental removal of SOLR-5908 changes

 Harden the Overseer restart mechanism
 -

 Key: SOLR-5859
 URL: https://issues.apache.org/jira/browse/SOLR-5859
 Project: Solr
  Issue Type: Improvement
Reporter: Noble Paul
Assignee: Noble Paul
 Fix For: 4.8, 5.0

 Attachments: SOLR-5859.patch, SOLR-5859.patch, SOLR-5859.patch, 
 SOLR-5859.patch


 SOLR-5476 depends on Overseer restart.The current strategy is to remove the 
 zk node for leader election and wait for STATUS_UPDATE_DELAY +100 ms and  
 start the new overseer.
 Though overseer ops are short running,  it is not a 100% foolproof strategy 
 because if an operation takes longer than the wait period there can be race 
 condition. 



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

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

[jira] [Commented] (SOLR-5908) Make REQUESTSTATUS call non-blocking and non-blocked

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-5859 removing accidental removal of SOLR-5908 changes

 Make REQUESTSTATUS call non-blocking and non-blocked
 

 Key: SOLR-5908
 URL: https://issues.apache.org/jira/browse/SOLR-5908
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Anshum Gupta
Assignee: Anshum Gupta
 Fix For: 4.8, 5.0

 Attachments: SOLR-5908.patch, SOLR-5908.patch


 Currently REQUESTSTATUS Collection API call is blocked by any other call in 
 the OCP work queue.
 Make it independent and non-blocked/non-blocking.
 This would be handled as a part of having the OCP multi-threaded but I'm 
 opening this issue to explore other possible options of handling this.
 If the final fix happens via SOLR-5681, will resolve it when SOLR-5681 gets 
 resolved.



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

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

[jira] [Resolved] (SOLR-5859) Harden the Overseer restart mechanism

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar resolved SOLR-5859.
-

Resolution: Fixed

Thanks for fixing, Noble!

 Harden the Overseer restart mechanism
 -

 Key: SOLR-5859
 URL: https://issues.apache.org/jira/browse/SOLR-5859
 Project: Solr
  Issue Type: Improvement
Reporter: Noble Paul
Assignee: Noble Paul
 Fix For: 4.8, 5.0

 Attachments: SOLR-5859.patch, SOLR-5859.patch, SOLR-5859.patch, 
 SOLR-5859.patch


 SOLR-5476 depends on Overseer restart.The current strategy is to remove the 
 zk node for leader election and wait for STATUS_UPDATE_DELAY +100 ms and  
 start the new overseer.
 Though overseer ops are short running,  it is not a 100% foolproof strategy 
 because if an operation takes longer than the wait period there can be race 
 condition. 



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

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

[jira] [Updated] (LUCENE-5563) Remove sep layout

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-5563:


Attachment: LUCENE-5563.patch

patch, I also cleaned up all remnants/conditionals about not supporting offsets.

 Remove sep layout
 -

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


 This has fallen behind feature wise, and isn't really performant (the 4.1 
 block format is a great improvement).
 I think we should remove it, its served its purpose but its time to retire...



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

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

[jira] [Commented] (LUCENE-5563) Remove sep layout

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-5563:


+1, nice that all codecs support offsets now!

 Remove sep layout
 -

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


 This has fallen behind feature wise, and isn't really performant (the 4.1 
 block format is a great improvement).
 I think we should remove it, its served its purpose but its time to retire...



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

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

[jira] [Updated] (SOLR-445) Update Handlers abort with bad documents

[JIRA]

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

Tomás Fernández Löbbe updated SOLR-445:
---

Attachment: SOLR-445-alternative.patch

added numAdds to header

 Update Handlers abort with bad documents
 

 Key: SOLR-445
 URL: https://issues.apache.org/jira/browse/SOLR-445
 Project: Solr
  Issue Type: Improvement
  Components: update
Affects Versions: 1.3
Reporter: Will Johnson
 Fix For: 4.8

 Attachments: SOLR-445-3_x.patch, SOLR-445-alternative.patch, 
 SOLR-445-alternative.patch, SOLR-445.patch, SOLR-445.patch, SOLR-445.patch, 
 SOLR-445.patch, SOLR-445_3x.patch, solr-445.xml


 Has anyone run into the problem of handling bad documents / failures mid 
 batch.  Ie:
 add
   doc
 field name=id1/field
   /doc
   doc
 field name=id2/field
 field name=myDateFieldI_AM_A_BAD_DATE/field
   /doc
   doc
 field name=id3/field
   /doc
 /add
 Right now solr adds the first doc and then aborts.  It would seem like it 
 should either fail the entire batch or log a message/return a code and then 
 continue on to add doc 3.  Option 1 would seem to be much harder to 
 accomplish and possibly require more memory while Option 2 would require more 
 information to come back from the API.  I'm about to dig into this but I 
 thought I'd ask to see if anyone had any suggestions, thoughts or comments.   
  



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

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

[jira] [Commented] (SOLR-5795) Option to periodically delete docs based on an expiration field -- or ttl specified when indexed.

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-5795:


bq. Hoss, instead of slice.getLeader(), you should use 
ZkStateReader.getLeaderRetry method.

That was actually a deliberate choice:

These deletes are low priority and will re-occur frequently - so it's fine to 
abort quickly as a No-Op, no need to block waiting for a leader. These leader 
checks will also happen very often and on every node very often - so we don't 
want to be hammering Zk with active leader checks/retries in a potential high 
load / leader election / outage situation.  The cached ClusterState info is 
good enough -- even if it's stale, the worst case scenario is that multiple 
nodes trigger a handfull redundant deletes, or the deletes are skipped for one 
cycle -- but the next one will take care of it.


 Option to periodically delete docs based on an expiration field -- or ttl 
 specified when indexed.
 -

 Key: SOLR-5795
 URL: https://issues.apache.org/jira/browse/SOLR-5795
 Project: Solr
  Issue Type: New Feature
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 4.8, 5.0

 Attachments: SOLR-5795.patch, SOLR-5795.patch, SOLR-5795.patch, 
 SOLR-5795.patch, SOLR-5795.patch, SOLR-5795.patch


 A question I get periodically from people is how to automatically remove 
 documents from a collection at a certain time (or after a certain amount of 
 time).  
 Excluding from search results using a filter query on a date field is 
 trivial, but you still have to periodically send a deleteByQuery to clean up 
 those older expired documents.  And in the case where you want all 
 documents to auto-expire some fixed amount of time when they were indexed, 
 you still have to setup a simple UpdateProcessorto set that expiration date.  
 So i've been thinking it would be nice if there was a simple way to configure 
 solr to do it all for you.



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

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

[jira] [Resolved] (LUCENE-5563) Remove sep layout

[Robert Muir (JIRA)]

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

Robert Muir resolved LUCENE-5563.
-

   Resolution: Fixed
Fix Version/s: 5.0

I can backport if we want to, but I'm not sure its worth the trouble here. We 
still have 3.x codec in 4.x, as well as the fact the blockterms readers/indexes 
have changed in trunk and have better testing: so backporting poses some risks.

 Remove sep layout
 -

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

 Attachments: LUCENE-5563.patch


 This has fallen behind feature wise, and isn't really performant (the 4.1 
 block format is a great improvement).
 I think we should remove it, its served its purpose but its time to retire...



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

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

[jira] [Commented] (LUCENE-5563) Remove sep layout

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-5563: remove sep layout

 Remove sep layout
 -

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

 Attachments: LUCENE-5563.patch


 This has fallen behind feature wise, and isn't really performant (the 4.1 
 block format is a great improvement).
 I think we should remove it, its served its purpose but its time to retire...



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

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

Re: [JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 81259 - Failure!

[Dawid Weiss]

Ummm... looks like  something hung. The rest junitcompat shouldn't
trigger -- these tests should be ignored once a previous error
happens, I'll try to look into it tomorrow.

Dawid

   [junit4]   2 Lucene Merge Thread #0 ID=25 RUNNABLE
   [junit4]   2 at
org.apache.lucene.codecs.lucene45.Lucene45DocValuesProducer.getSortedSet(Lucene45DocValuesProducer.java:541)
   [junit4]   2 at
org.apache.lucene.codecs.perfield.PerFieldDocValuesFormat$FieldsReader.getSortedSet(PerFieldDocValuesFormat.java:285)
   [junit4]   2 at
org.apache.lucene.index.SegmentReader.getSortedSetDocValues(SegmentReader.java:500)
   [junit4]   2 at
org.apache.lucene.index.SegmentMerger.mergeDocValues(SegmentMerger.java:204)
   [junit4]   2 at
org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:119)
   [junit4]   2 at
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4068)
   [junit4]   2 at
org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3664)
   [junit4]   2 at
org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:405)
   [junit4]   2 at
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:482)
   [junit4]   2
   [junit4]   2
TEST-TestLucene45DocValuesFormat.testSortedSetVariableLengthVsUninvertedField-seed#[7362FE36DE729D42]
ID=23 RUNNABLE
   [junit4]   2 at
org.apache.lucene.index.SortedSetDocValues.clinit(SortedSetDocValues.java:72)
   [junit4]   2 at
org.apache.lucene.index.DocTermOrds.iterator(DocTermOrds.java:767)
   [junit4]   2 at
org.apache.lucene.search.FieldCacheImpl.getDocTermOrds(FieldCacheImpl.java:1214)
   [junit4]   2 at
org.apache.lucene.index.BaseDocValuesFormatTestCase.doTestSortedSetVsUninvertedField(BaseDocValuesFormatTestCase.java:2342)
   [junit4]   2 at
org.apache.lucene.index.BaseDocValuesFormatTestCase.testSortedSetVariableLengthVsUninvertedField(BaseDocValuesFormatTestCase.java:2375)
   [junit4]   2 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   [junit4]   2 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   [junit4]   2 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   [junit4]   2 at java.lang.reflect.Method.invoke(Method.java:606)
   [junit4]   2 at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1617)
   [junit4]   2 at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:826)
   [junit4]   2 at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:862)
   [junit4]   2 at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:876)
   [junit4]   2 at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
   [junit4]   2 at
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
   [junit4]   2 at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
   [junit4]   2 at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
   [junit4]   2 at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
   [junit4]   2 at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
   [junit4]   2 at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
   [junit4]   2 at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
   [junit4]   2 at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:359)
   [junit4]   2 at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:783)
   [junit4]   2 at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:443)
   [junit4]   2 at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:835)
   [junit4]   2 at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:737)
   [junit4]   2 at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:771)
   [junit4]   2 at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:782)
   [junit4]   2 at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
   [junit4]   2 at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
   [junit4]   2 at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
   [junit4]   2 at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
   [junit4]   2 at

[jira] [Created] (SOLR-5950) In SolrJ's Maven Dependency Graph, slf4j-api is optional, which breaks plain solrj users

[Uwe Schindler (JIRA)]

Uwe Schindler created SOLR-5950:
---

 Summary: In SolrJ's Maven Dependency Graph, slf4j-api is optional, 
which breaks plain solrj users
 Key: SOLR-5950
 URL: https://issues.apache.org/jira/browse/SOLR-5950
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 4.7.1, 4.7
Reporter: Uwe Schindler


To run as a Solr Client, you need slf4j actually configured in your classpath, 
because HttpSolrServer hardly depends on it, also the used libs like Commons 
Httpclient (and others)

In SOLR-3706 *all* of the slf4j JARs were made optional, but because we did not 
exclude the dependencies of httpclient and others explicitely, the dependency 
was still included by maven automatically for a user that used SolrJ - so 
effectively the optional was never working.

In 4.7, [~steve_rowe] now explicitely excluded all dependencies of all deps 
included via IVY. By that the implicit dependency by httpclient was killed.

When I updated a project from SolrJ 4.6 to SolrJ 4.7, it suddenly failed to 
run, because it failed with a classnotfound ex directly after starting. Not 
even the default logging to console was enabled (which is provided by slf4j). 
This is bad for users of SolrJ, because they have to explicitely add a 
dependency for something that really required to use SolrJ.

The reason for excluding slf4j-api was that we don't want to have it in the WAR 
file, so it was made optional. But that is wrong:
- In trunk we no longer have a WAR file
- The primary user of SolrJ via Maven is not somebody who wants to install Solr 
in his appserver, its the user needing the client.

So we should restore the state from Solr 4.6, where the dep was implicitely 
included, by making it non-optional in Maven.

When building the WAR file in 4.x we should exclude it somehow via Maven 
Magic(tm).



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

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

[jira] [Commented] (SOLR-5949) Stopwords in Boolean Query Result in invalid query

[Ahmet Arslan (JIRA)]

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

Ahmet Arslan commented on SOLR-5949:


Which query parser is that?

 Stopwords in Boolean Query Result in invalid query
 --

 Key: SOLR-5949
 URL: https://issues.apache.org/jira/browse/SOLR-5949
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 4.3
 Environment: Linux
Reporter: Bob Laferriere

 This seems a repeat of SOLR-261 which was fixed in 1.3 but I am seeing the 
 same behavior described. When I have a stopword in a boolean query the 
 resulting query is invalid. 
 e.g. Document -- No Smoking Sign
 Stopword: No
 Query:No AND Smoking AND Sign
 The resultant query is a boolean query with a blank field so an empty boolean 
 query. This is expanding as ? Smoking Sign which then leads to no matches 
 as ? AND Smoking AND sign has no match.
 The expected behavior is to remove the empty boolean clause from the query. 
 In the Analysis tool the parsing showing that No AND Smoking AND Sign 
 analyzes to Smoke Sign. I would expect the same behavior by the 
 QueryParser, but this is not true. The real parsed query is trying to do the 
 following: empty boolean query Smoke Sign.
 The only workaround is to never allow stopwords in the query or turn off 
 stopwords entirely.



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

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

[jira] [Commented] (SOLR-5949) Stopwords in Boolean Query Result in invalid query

[Bob Laferriere (JIRA)]

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

Bob Laferriere commented on SOLR-5949:
--

Sorry. edismax.

 Stopwords in Boolean Query Result in invalid query
 --

 Key: SOLR-5949
 URL: https://issues.apache.org/jira/browse/SOLR-5949
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 4.3
 Environment: Linux
Reporter: Bob Laferriere

 This seems a repeat of SOLR-261 which was fixed in 1.3 but I am seeing the 
 same behavior described. When I have a stopword in a boolean query the 
 resulting query is invalid. 
 e.g. Document -- No Smoking Sign
 Stopword: No
 Query:No AND Smoking AND Sign
 The resultant query is a boolean query with a blank field so an empty boolean 
 query. This is expanding as ? Smoking Sign which then leads to no matches 
 as ? AND Smoking AND sign has no match.
 The expected behavior is to remove the empty boolean clause from the query. 
 In the Analysis tool the parsing showing that No AND Smoking AND Sign 
 analyzes to Smoke Sign. I would expect the same behavior by the 
 QueryParser, but this is not true. The real parsed query is trying to do the 
 following: empty boolean query Smoke Sign.
 The only workaround is to never allow stopwords in the query or turn off 
 stopwords entirely.



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

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

[jira] [Created] (SOLR-5951) SolrDispatchFilter no longer displays useful error message on statup when logging jars are missing

[Uwe Schindler (JIRA)]

Uwe Schindler created SOLR-5951:
---

 Summary: SolrDispatchFilter no longer displays useful error 
message on statup when logging jars are missing
 Key: SOLR-5951
 URL: https://issues.apache.org/jira/browse/SOLR-5951
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.7.1, 4.7
Reporter: Uwe Schindler
Assignee: Uwe Schindler


We no longer have logging jars in the webapp since SOLR-3706. Because of this 
we added a extra check in SolrDispatchFilter's ctor to print a nice exception 
if the logging jars were failing. This check was unfortunately never tests and 
recently broke:

The check delays initialization of the Logger instance to inside a try-catch 
block inside the explicit ctor. If it fails with ClassNotFound, it throws 
Exception.

Recently we upgraded to a newer HttpClient version. Unfortunately 
SolrDispatchFliter also has an implicit constructor a few lines before the main 
constructor:

{code:java}
  protected final HttpClient httpClient = HttpClientUtil.createClient(new 
ModifiableSolrParams()); // -- this breaks the detection
  
  private static final Charset UTF8 = StandardCharsets.UTF_8;

  public SolrDispatchFilter() {
try {
  log = LoggerFactory.getLogger(SolrDispatchFilter.class);
} catch (NoClassDefFoundError e) {
  throw new SolrException(
  ErrorCode.SERVER_ERROR,
  Could not find necessary SLF4j logging jars. If using Jetty, the 
SLF4j logging jars need to go in 
  +the jetty lib/ext directory. For other containers, the 
corresponding directory should be used. 
  +For more information, see: http://wiki.apache.org/solr/SolrLogging;,
  e);
}
  }
{code}

The first line above {{HttpClientUtil.createClient(new 
ModifiableSolrParams());}} breaks the whole thing, because it is executed 
before the declared constructor. The user just sees a ClassNotFoundEx at this 
line of code, the nice error message is hidden.

Because this is so easy to break, we should make the whole thing more safe (any 
maybe test it). 2 options:

# Into the webapp add a fake Servlet (not bound to anything, just loaded first) 
that does not use any Solr classes at all, nothing only plain java
# Alternatively add a Superclass between ServletFilter and SolrDispatchFilter 
(pkg-private). When the servlet container loads SolrDispatchFilter, it has in 
any case to first load the superclass. And this superclass does the check and 
throws ServletException or whatever (no Solr Exception) with the message from 
the current code.

I tend to the second approach, because it does not need to modify web-inf. It 
will also work with other Solr servlets, they must just extend this hidden 
class. I will provide a patch for that.



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

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

[jira] [Commented] (SOLR-5949) Stopwords in Boolean Query Result in invalid query

[Ahmet Arslan (JIRA)]

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

Ahmet Arslan commented on SOLR-5949:


I don't think AND is allowed inside phrases nor this is a bug.

 Stopwords in Boolean Query Result in invalid query
 --

 Key: SOLR-5949
 URL: https://issues.apache.org/jira/browse/SOLR-5949
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 4.3
 Environment: Linux
Reporter: Bob Laferriere

 This seems a repeat of SOLR-261 which was fixed in 1.3 but I am seeing the 
 same behavior described. When I have a stopword in a boolean query the 
 resulting query is invalid. 
 e.g. Document -- No Smoking Sign
 Stopword: No
 Query:No AND Smoking AND Sign
 The resultant query is a boolean query with a blank field so an empty boolean 
 query. This is expanding as ? Smoking Sign which then leads to no matches 
 as ? AND Smoking AND sign has no match.
 The expected behavior is to remove the empty boolean clause from the query. 
 In the Analysis tool the parsing showing that No AND Smoking AND Sign 
 analyzes to Smoke Sign. I would expect the same behavior by the 
 QueryParser, but this is not true. The real parsed query is trying to do the 
 following: empty boolean query Smoke Sign.
 The only workaround is to never allow stopwords in the query or turn off 
 stopwords entirely.



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

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

[jira] [Commented] (SOLR-5949) Stopwords in Boolean Query Result in invalid query

[Bob Laferriere (JIRA)]

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

Bob Laferriere commented on SOLR-5949:
--

I disagree. Boolean logic *is* allowed and listed as a feature of edismax. 

See here: 
https://cwiki.apache.org/confluence/display/solr/The+Extended+DisMax+Query+Parser

This is right off the Solr wiki page. Boolean operators are allowed. The issue 
is with stopwords combined with the Boolean operators.

 Stopwords in Boolean Query Result in invalid query
 --

 Key: SOLR-5949
 URL: https://issues.apache.org/jira/browse/SOLR-5949
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 4.3
 Environment: Linux
Reporter: Bob Laferriere

 This seems a repeat of SOLR-261 which was fixed in 1.3 but I am seeing the 
 same behavior described. When I have a stopword in a boolean query the 
 resulting query is invalid. 
 e.g. Document -- No Smoking Sign
 Stopword: No
 Query:No AND Smoking AND Sign
 The resultant query is a boolean query with a blank field so an empty boolean 
 query. This is expanding as ? Smoking Sign which then leads to no matches 
 as ? AND Smoking AND sign has no match.
 The expected behavior is to remove the empty boolean clause from the query. 
 In the Analysis tool the parsing showing that No AND Smoking AND Sign 
 analyzes to Smoke Sign. I would expect the same behavior by the 
 QueryParser, but this is not true. The real parsed query is trying to do the 
 following: empty boolean query Smoke Sign.
 The only workaround is to never allow stopwords in the query or turn off 
 stopwords entirely.



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

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

[jira] [Commented] (SOLR-5949) Stopwords in Boolean Query Result in invalid query

[Bob Laferriere (JIRA)]

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

Bob Laferriere commented on SOLR-5949:
--

Also, I am not searching with the quotes as a full phrase match. I just used 
that to highlight the issue. The search is sent over as q:(Not AND Smoking AND 
Sign) and not q:Not AND Smoking AND Sign which I believe you are indicating. 
I know that is not supported. But I am not doing a phrase query.

 Stopwords in Boolean Query Result in invalid query
 --

 Key: SOLR-5949
 URL: https://issues.apache.org/jira/browse/SOLR-5949
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 4.3
 Environment: Linux
Reporter: Bob Laferriere

 This seems a repeat of SOLR-261 which was fixed in 1.3 but I am seeing the 
 same behavior described. When I have a stopword in a boolean query the 
 resulting query is invalid. 
 e.g. Document -- No Smoking Sign
 Stopword: No
 Query:No AND Smoking AND Sign
 The resultant query is a boolean query with a blank field so an empty boolean 
 query. This is expanding as ? Smoking Sign which then leads to no matches 
 as ? AND Smoking AND sign has no match.
 The expected behavior is to remove the empty boolean clause from the query. 
 In the Analysis tool the parsing showing that No AND Smoking AND Sign 
 analyzes to Smoke Sign. I would expect the same behavior by the 
 QueryParser, but this is not true. The real parsed query is trying to do the 
 following: empty boolean query Smoke Sign.
 The only workaround is to never allow stopwords in the query or turn off 
 stopwords entirely.



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

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

[jira] [Comment Edited] (SOLR-5949) Stopwords in Boolean Query Result in invalid query

[Bob Laferriere (JIRA)]

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

Bob Laferriere edited comment on SOLR-5949 at 4/2/14 8:29 PM:
--

Also, I am not searching with the quotes as a full phrase match. I just used 
that to highlight the issue. The search is sent over as q:(No AND Smoking AND 
Sign) and not q:No AND Smoking AND Sign which I believe you are indicating. I 
know that is not supported. But I am not doing a phrase query.


was (Author: golferdad39):
Also, I am not searching with the quotes as a full phrase match. I just used 
that to highlight the issue. The search is sent over as q:(Not AND Smoking AND 
Sign) and not q:Not AND Smoking AND Sign which I believe you are indicating. 
I know that is not supported. But I am not doing a phrase query.

 Stopwords in Boolean Query Result in invalid query
 --

 Key: SOLR-5949
 URL: https://issues.apache.org/jira/browse/SOLR-5949
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 4.3
 Environment: Linux
Reporter: Bob Laferriere

 This seems a repeat of SOLR-261 which was fixed in 1.3 but I am seeing the 
 same behavior described. When I have a stopword in a boolean query the 
 resulting query is invalid. 
 e.g. Document -- No Smoking Sign
 Stopword: No
 Query:No AND Smoking AND Sign
 The resultant query is a boolean query with a blank field so an empty boolean 
 query. This is expanding as ? Smoking Sign which then leads to no matches 
 as ? AND Smoking AND sign has no match.
 The expected behavior is to remove the empty boolean clause from the query. 
 In the Analysis tool the parsing showing that No AND Smoking AND Sign 
 analyzes to Smoke Sign. I would expect the same behavior by the 
 QueryParser, but this is not true. The real parsed query is trying to do the 
 following: empty boolean query Smoke Sign.
 The only workaround is to never allow stopwords in the query or turn off 
 stopwords entirely.



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

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

[jira] [Comment Edited] (SOLR-5949) Stopwords in Boolean Query Result in invalid query

[Bob Laferriere (JIRA)]

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

Bob Laferriere edited comment on SOLR-5949 at 4/2/14 8:30 PM:
--

I disagree. Boolean logic *is* allowed and listed as a feature of edismax. 

See here: 
https://cwiki.apache.org/confluence/display/solr/The+Extended+DisMax+Query+Parser

This is right off the Solr wiki page. Boolean operators are allowed. The issue 
is with stopwords combined with the Boolean operators.

I am not searching with the quotes as a full phrase match. I just used that to 
highlight the issue. The search is sent over as q:(No AND Smoking AND Sign) and 
not q:No AND Smoking AND Sign which I believe you are indicating. I know that 
is not supported. But I am not doing a phrase query


was (Author: golferdad39):
I disagree. Boolean logic *is* allowed and listed as a feature of edismax. 

See here: 
https://cwiki.apache.org/confluence/display/solr/The+Extended+DisMax+Query+Parser

This is right off the Solr wiki page. Boolean operators are allowed. The issue 
is with stopwords combined with the Boolean operators.

 Stopwords in Boolean Query Result in invalid query
 --

 Key: SOLR-5949
 URL: https://issues.apache.org/jira/browse/SOLR-5949
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 4.3
 Environment: Linux
Reporter: Bob Laferriere

 This seems a repeat of SOLR-261 which was fixed in 1.3 but I am seeing the 
 same behavior described. When I have a stopword in a boolean query the 
 resulting query is invalid. 
 e.g. Document -- No Smoking Sign
 Stopword: No
 Query:No AND Smoking AND Sign
 The resultant query is a boolean query with a blank field so an empty boolean 
 query. This is expanding as ? Smoking Sign which then leads to no matches 
 as ? AND Smoking AND sign has no match.
 The expected behavior is to remove the empty boolean clause from the query. 
 In the Analysis tool the parsing showing that No AND Smoking AND Sign 
 analyzes to Smoke Sign. I would expect the same behavior by the 
 QueryParser, but this is not true. The real parsed query is trying to do the 
 following: empty boolean query Smoke Sign.
 The only workaround is to never allow stopwords in the query or turn off 
 stopwords entirely.



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

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

[jira] [Issue Comment Deleted] (SOLR-5949) Stopwords in Boolean Query Result in invalid query

[Bob Laferriere (JIRA)]

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

Bob Laferriere updated SOLR-5949:
-

Comment: was deleted

(was: Also, I am not searching with the quotes as a full phrase match. I just 
used that to highlight the issue. The search is sent over as q:(No AND Smoking 
AND Sign) and not q:No AND Smoking AND Sign which I believe you are 
indicating. I know that is not supported. But I am not doing a phrase query.)

 Stopwords in Boolean Query Result in invalid query
 --

 Key: SOLR-5949
 URL: https://issues.apache.org/jira/browse/SOLR-5949
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 4.3
 Environment: Linux
Reporter: Bob Laferriere

 This seems a repeat of SOLR-261 which was fixed in 1.3 but I am seeing the 
 same behavior described. When I have a stopword in a boolean query the 
 resulting query is invalid. 
 e.g. Document -- No Smoking Sign
 Stopword: No
 Query:No AND Smoking AND Sign
 The resultant query is a boolean query with a blank field so an empty boolean 
 query. This is expanding as ? Smoking Sign which then leads to no matches 
 as ? AND Smoking AND sign has no match.
 The expected behavior is to remove the empty boolean clause from the query. 
 In the Analysis tool the parsing showing that No AND Smoking AND Sign 
 analyzes to Smoke Sign. I would expect the same behavior by the 
 QueryParser, but this is not true. The real parsed query is trying to do the 
 following: empty boolean query Smoke Sign.
 The only workaround is to never allow stopwords in the query or turn off 
 stopwords entirely.



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

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

[jira] [Assigned] (SOLR-5950) In SolrJ's Maven Dependency Graph, slf4j-api is optional, which breaks plain solrj users

[Steve Rowe (JIRA)]

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

Steve Rowe reassigned SOLR-5950:


Assignee: Steve Rowe

 In SolrJ's Maven Dependency Graph, slf4j-api is optional, which breaks plain 
 solrj users
 

 Key: SOLR-5950
 URL: https://issues.apache.org/jira/browse/SOLR-5950
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 4.7, 4.7.1
Reporter: Uwe Schindler
Assignee: Steve Rowe

 To run as a Solr Client, you need slf4j actually configured in your 
 classpath, because HttpSolrServer hardly depends on it, also the used libs 
 like Commons Httpclient (and others)
 In SOLR-3706 *all* of the slf4j JARs were made optional, but because we did 
 not exclude the dependencies of httpclient and others explicitely, the 
 dependency was still included by maven automatically for a user that used 
 SolrJ - so effectively the optional was never working.
 In 4.7, [~steve_rowe] now explicitely excluded all dependencies of all deps 
 included via IVY. By that the implicit dependency by httpclient was killed.
 When I updated a project from SolrJ 4.6 to SolrJ 4.7, it suddenly failed to 
 run, because it failed with a classnotfound ex directly after starting. Not 
 even the default logging to console was enabled (which is provided by slf4j). 
 This is bad for users of SolrJ, because they have to explicitely add a 
 dependency for something that really required to use SolrJ.
 The reason for excluding slf4j-api was that we don't want to have it in the 
 WAR file, so it was made optional. But that is wrong:
 - In trunk we no longer have a WAR file
 - The primary user of SolrJ via Maven is not somebody who wants to install 
 Solr in his appserver, its the user needing the client.
 So we should restore the state from Solr 4.6, where the dep was implicitely 
 included, by making it non-optional in Maven.
 When building the WAR file in 4.x we should exclude it somehow via Maven 
 Magic(tm).



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

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

[jira] [Commented] (SOLR-5949) Stopwords in Boolean Query Result in invalid query

[Ahmet Arslan (JIRA)]

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

Ahmet Arslan commented on SOLR-5949:


I am talking about operators inside phrases. Using AND operator between terms 
surrounded by quotes makes no sense. Documents returned by Phrase Query will 
ensure that all terms will be there anyway.

 Stopwords in Boolean Query Result in invalid query
 --

 Key: SOLR-5949
 URL: https://issues.apache.org/jira/browse/SOLR-5949
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 4.3
 Environment: Linux
Reporter: Bob Laferriere

 This seems a repeat of SOLR-261 which was fixed in 1.3 but I am seeing the 
 same behavior described. When I have a stopword in a boolean query the 
 resulting query is invalid. 
 e.g. Document -- No Smoking Sign
 Stopword: No
 Query:No AND Smoking AND Sign
 The resultant query is a boolean query with a blank field so an empty boolean 
 query. This is expanding as ? Smoking Sign which then leads to no matches 
 as ? AND Smoking AND sign has no match.
 The expected behavior is to remove the empty boolean clause from the query. 
 In the Analysis tool the parsing showing that No AND Smoking AND Sign 
 analyzes to Smoke Sign. I would expect the same behavior by the 
 QueryParser, but this is not true. The real parsed query is trying to do the 
 following: empty boolean query Smoke Sign.
 The only workaround is to never allow stopwords in the query or turn off 
 stopwords entirely.



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

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

[jira] [Commented] (SOLR-5949) Stopwords in Boolean Query Result in invalid query

[Bob Laferriere (JIRA)]

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

Bob Laferriere commented on SOLR-5949:
--

Yes. I am not doing that type of query. I am doing

No AND Smoking AND Sign

as the query. The quotes were intended to only highlight the search not 
intended to indicate that I was doing a phrase search. It is truly a boolean 
query on keywords and not a phrase search.

 Stopwords in Boolean Query Result in invalid query
 --

 Key: SOLR-5949
 URL: https://issues.apache.org/jira/browse/SOLR-5949
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 4.3
 Environment: Linux
Reporter: Bob Laferriere

 This seems a repeat of SOLR-261 which was fixed in 1.3 but I am seeing the 
 same behavior described. When I have a stopword in a boolean query the 
 resulting query is invalid. 
 e.g. Document -- No Smoking Sign
 Stopword: No
 Query:No AND Smoking AND Sign
 The resultant query is a boolean query with a blank field so an empty boolean 
 query. This is expanding as ? Smoking Sign which then leads to no matches 
 as ? AND Smoking AND sign has no match.
 The expected behavior is to remove the empty boolean clause from the query. 
 In the Analysis tool the parsing showing that No AND Smoking AND Sign 
 analyzes to Smoke Sign. I would expect the same behavior by the 
 QueryParser, but this is not true. The real parsed query is trying to do the 
 following: empty boolean query Smoke Sign.
 The only workaround is to never allow stopwords in the query or turn off 
 stopwords entirely.



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

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

[jira] [Commented] (SOLR-5949) Stopwords in Boolean Query Result in invalid query

[Ahmet Arslan (JIRA)]

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

Ahmet Arslan commented on SOLR-5949:


I cannot reproduce your problem. q=(No AND Smoking AND Sign) is  
parsedquery_toString: +(+(author:smoking) +(author:sign)),
Question Mark ? in parsed query happens when stop words used in phrases.

Can you copy-paste your field type? Maybe you are using

 Stopwords in Boolean Query Result in invalid query
 --

 Key: SOLR-5949
 URL: https://issues.apache.org/jira/browse/SOLR-5949
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 4.3
 Environment: Linux
Reporter: Bob Laferriere

 This seems a repeat of SOLR-261 which was fixed in 1.3 but I am seeing the 
 same behavior described. When I have a stopword in a boolean query the 
 resulting query is invalid. 
 e.g. Document -- No Smoking Sign
 Stopword: No
 Query:No AND Smoking AND Sign
 The resultant query is a boolean query with a blank field so an empty boolean 
 query. This is expanding as ? Smoking Sign which then leads to no matches 
 as ? AND Smoking AND sign has no match.
 The expected behavior is to remove the empty boolean clause from the query. 
 In the Analysis tool the parsing showing that No AND Smoking AND Sign 
 analyzes to Smoke Sign. I would expect the same behavior by the 
 QueryParser, but this is not true. The real parsed query is trying to do the 
 following: empty boolean query Smoke Sign.
 The only workaround is to never allow stopwords in the query or turn off 
 stopwords entirely.



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

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

[jira] [Created] (LUCENE-5566) Inconsistent search results in different threads but same query

[Pradeep K Poluri (JIRA)]

Pradeep K Poluri created LUCENE-5566:


 Summary: Inconsistent search results in different threads but same 
query
 Key: LUCENE-5566
 URL: https://issues.apache.org/jira/browse/LUCENE-5566
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/search
Affects Versions: 3.6
Reporter: Pradeep K Poluri


We have a very difficult case to identify whats going on.
We have a multithreaded environment where multiple threads are trying to hit 
the same lucene query and getting different results each time.
For eg: Query A has returned 1 result which is running in thread 1
And same Query A is returning 0 results which is running in thread 2.

All the indexes looks fine and if we take the same query and try it in Luke and 
we are able to get the correct results which is 1 in this case.

Trying to figure out whats going on. 



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

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

[jira] [Updated] (LUCENE-5566) Inconsistent search results in different threads but same query

[Pradeep K Poluri (JIRA)]

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

Pradeep K Poluri updated LUCENE-5566:
-

Description: 
We have a very difficult case to identify whats going on.
We have a multithreaded environment where multiple threads are trying to hit 
the same lucene query and getting different results each time.
For eg: Query A has returned 1 result which is running in thread 1
And same Query A is returning 0 results which is running in thread 2.

All the indexes looks fine and if we take the same query and try it in Luke and 
we are able to get the correct results which is 1 in this case. And we are not 
able to reproduce it in local environments or staging or integration but only 
on Production.

Trying to figure out whats going on. 

  was:
We have a very difficult case to identify whats going on.
We have a multithreaded environment where multiple threads are trying to hit 
the same lucene query and getting different results each time.
For eg: Query A has returned 1 result which is running in thread 1
And same Query A is returning 0 results which is running in thread 2.

All the indexes looks fine and if we take the same query and try it in Luke and 
we are able to get the correct results which is 1 in this case.

Trying to figure out whats going on. 


 Inconsistent search results in different threads but same query
 ---

 Key: LUCENE-5566
 URL: https://issues.apache.org/jira/browse/LUCENE-5566
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/search
Affects Versions: 3.6
Reporter: Pradeep K Poluri

 We have a very difficult case to identify whats going on.
 We have a multithreaded environment where multiple threads are trying to hit 
 the same lucene query and getting different results each time.
 For eg: Query A has returned 1 result which is running in thread 1
 And same Query A is returning 0 results which is running in thread 2.
 All the indexes looks fine and if we take the same query and try it in Luke 
 and we are able to get the correct results which is 1 in this case. And we 
 are not able to reproduce it in local environments or staging or integration 
 but only on Production.
 Trying to figure out whats going on. 



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

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

[jira] [Updated] (SOLR-5951) SolrDispatchFilter no longer displays useful error message on statup when logging jars are missing

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated SOLR-5951:


Attachment: SOLR-5951.patch

Patch that implements the second approach. The good thing: All user-visible 
servlets and filters extend those hidden abstract base classes. Because of this 
the checking code is executed in any case, although maybe some other servlet or 
filter is loaded before SolrDispatchFilter (e.g., user modified web.xml file).

When starting the example with the Jetty {{ext}} folder emptied, the following 
is displayed:

{noformat}
2014-04-02 23:21:10.009:WARN:oejuc.AbstractLifeCycle:FAILED SolrRequestFilter: 
java.lang.NoClassDefFoundError: Failed to initialize
Apache Solr: Could not find necessary SLF4j logging jars. If using Jetty, the 
SLF4j logging jars need to go in the jetty lib/ext dir
ectory. For other containers, the corresponding directory should be used. For 
more information, see: http://wiki.apache.org/solr/Sol
rLogging
java.lang.NoClassDefFoundError: Failed to initialize Apache Solr: Could not 
find necessary SLF4j logging jars. If using Jetty, the S
LF4j logging jars need to go in the jetty lib/ext directory. For other 
containers, the corresponding directory should be used. For m
ore information, see: http://wiki.apache.org/solr/SolrLogging
at 
org.apache.solr.servlet.CheckLoggingConfiguration.check(CheckLoggingConfiguration.java:28)
at 
org.apache.solr.servlet.BaseSolrFilter.clinit(BaseSolrFilter.java:25)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at java.lang.Class.newInstance(Class.java:374)
at 
org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:1053)
at org.eclipse.jetty.servlet.FilterHolder.doStart(FilterHolder.java:105)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at 
org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:719)
at 
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:265)
at 
org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1252)
at 
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:710)
at 
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:494)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at 
org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:39)
at 
org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:186)
at 
org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:494)
at 
org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:141)
at 
org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:145)
at 
org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:56)
at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:609)
at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:540)
at org.eclipse.jetty.util.Scanner.scan(Scanner.java:403)
at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:337)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at 
org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:121)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at 
org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:555)
at 
org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:230)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at 
org.eclipse.jetty.util.component.AggregateLifeCycle.doStart(AggregateLifeCycle.java:81)
at 
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:58)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:96)
at org.eclipse.jetty.server.Server.doStart(Server.java:280)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at 
org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1259)
at java.security.AccessController.doPrivileged(Native Method)
at 

[jira] [Commented] (LUCENE-5189) Numeric DocValues Updates

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on LUCENE-5189:
--

One more note for adopters. if you start with experimenting with a test, make 
sure you suppress older codecs (check how a certain DV update test does it), 
otherwise you can spend some time to digging in really odd exception. 

 Numeric DocValues Updates
 -

 Key: LUCENE-5189
 URL: https://issues.apache.org/jira/browse/LUCENE-5189
 Project: Lucene - Core
  Issue Type: New Feature
  Components: core/index
Reporter: Shai Erera
Assignee: Shai Erera
 Fix For: 4.6, 5.0

 Attachments: LUCENE-5189-4x.patch, LUCENE-5189-4x.patch, 
 LUCENE-5189-no-lost-updates.patch, LUCENE-5189-renames.patch, 
 LUCENE-5189-segdv.patch, LUCENE-5189-updates-order.patch, 
 LUCENE-5189-updates-order.patch, LUCENE-5189.patch, LUCENE-5189.patch, 
 LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, 
 LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, 
 LUCENE-5189.patch, LUCENE-5189_process_events.patch, 
 LUCENE-5189_process_events.patch


 In LUCENE-4258 we started to work on incremental field updates, however the 
 amount of changes are immense and hard to follow/consume. The reason is that 
 we targeted postings, stored fields, DV etc., all from the get go.
 I'd like to start afresh here, with numeric-dv-field updates only. There are 
 a couple of reasons to that:
 * NumericDV fields should be easier to update, if e.g. we write all the 
 values of all the documents in a segment for the updated field (similar to 
 how livedocs work, and previously norms).
 * It's a fairly contained issue, attempting to handle just one data type to 
 update, yet requires many changes to core code which will also be useful for 
 updating other data types.
 * It has value in and on itself, and we don't need to allow updating all the 
 data types in Lucene at once ... we can do that gradually.
 I have some working patch already which I'll upload next, explaining the 
 changes.



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

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

[jira] [Updated] (SOLR-5951) SolrDispatchFilter no longer displays useful error message on statup when logging jars are missing

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated SOLR-5951:


Fix Version/s: 4.7.2
   5.0
   4.8

 SolrDispatchFilter no longer displays useful error message on statup when 
 logging jars are missing
 --

 Key: SOLR-5951
 URL: https://issues.apache.org/jira/browse/SOLR-5951
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.7, 4.7.1
Reporter: Uwe Schindler
Assignee: Uwe Schindler
 Fix For: 4.8, 5.0, 4.7.2

 Attachments: SOLR-5951.patch


 We no longer have logging jars in the webapp since SOLR-3706. Because of this 
 we added a extra check in SolrDispatchFilter's ctor to print a nice exception 
 if the logging jars were failing. This check was unfortunately never tests 
 and recently broke:
 The check delays initialization of the Logger instance to inside a try-catch 
 block inside the explicit ctor. If it fails with ClassNotFound, it throws 
 Exception.
 Recently we upgraded to a newer HttpClient version. Unfortunately 
 SolrDispatchFliter also has an implicit constructor a few lines before the 
 main constructor:
 {code:java}
   protected final HttpClient httpClient = HttpClientUtil.createClient(new 
 ModifiableSolrParams()); // -- this breaks the detection
   
   private static final Charset UTF8 = StandardCharsets.UTF_8;
   public SolrDispatchFilter() {
 try {
   log = LoggerFactory.getLogger(SolrDispatchFilter.class);
 } catch (NoClassDefFoundError e) {
   throw new SolrException(
   ErrorCode.SERVER_ERROR,
   Could not find necessary SLF4j logging jars. If using Jetty, the 
 SLF4j logging jars need to go in 
   +the jetty lib/ext directory. For other containers, the 
 corresponding directory should be used. 
   +For more information, see: 
 http://wiki.apache.org/solr/SolrLogging;,
   e);
 }
   }
 {code}
 The first line above {{HttpClientUtil.createClient(new 
 ModifiableSolrParams());}} breaks the whole thing, because it is executed 
 before the declared constructor. The user just sees a ClassNotFoundEx at this 
 line of code, the nice error message is hidden.
 Because this is so easy to break, we should make the whole thing more safe 
 (any maybe test it). 2 options:
 # Into the webapp add a fake Servlet (not bound to anything, just loaded 
 first) that does not use any Solr classes at all, nothing only plain java
 # Alternatively add a Superclass between ServletFilter and SolrDispatchFilter 
 (pkg-private). When the servlet container loads SolrDispatchFilter, it has in 
 any case to first load the superclass. And this superclass does the check and 
 throws ServletException or whatever (no Solr Exception) with the message from 
 the current code.
 I tend to the second approach, because it does not need to modify web-inf. It 
 will also work with other Solr servlets, they must just extend this hidden 
 class. I will provide a patch for that.



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

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

[JENKINS] Lucene-4x-Linux-Java7-64-test-only - Build # 17620 - Failure!

[builder]

Build: builds.flonkings.com/job/Lucene-4x-Linux-Java7-64-test-only/17620/

No tests ran.

Build Log:
[...truncated 13 lines...]
ERROR: Failed to update 
http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x
org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS 
/repos/asf/lucene/dev/branches/branch_4x failed
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148)
at 
org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339)
at 
org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274)
at 
org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27)
at 
org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:910)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:891)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:874)
at hudson.FilePath.act(FilePath.java:914)
at hudson.FilePath.act(FilePath.java:887)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:850)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:788)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1414)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561)
at hudson.model.Run.execute(Run.java:1678)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:231)
Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
... 38 more
Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request 
failed on '/repos/asf/lucene/dev/branches/branch_4x'
svn: E175002: timed out waiting for server
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382)
... 37 more
Caused by: svn: E175002: OPTIONS request failed on 
'/repos/asf/lucene/dev/branches/branch_4x'
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775)
... 38 more
Caused by: svn: E175002: timed out waiting for server
at 

[jira] [Commented] (SOLR-3582) Our ZooKeeper watchers respond to session events as if they are change events, creating undesirable side effects.

[Jessica Cheng (JIRA)]

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

Jessica Cheng commented on SOLR-3582:
-

{quote}
Never mind - found confirmation elsewhere that session events do not remove the 
watcher. The ZooKeeper programming guide does not appear very clear on this 
when it talks about watches being one time triggers.
{quote}

Mark, is this true even if the event is Expired? I don't know how zookeeper 
works in detail, but I'd be surprised if it would keep watchers across sessions 
(how can it figure out which session re-establishment is related to the expired 
session?).

 Our ZooKeeper watchers respond to session events as if they are change 
 events, creating undesirable side effects.
 -

 Key: SOLR-3582
 URL: https://issues.apache.org/jira/browse/SOLR-3582
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.0-BETA, 5.0


 As brought up by Trym R. Møller on the mailing list, we are responding to 
 watcher events about connection/disconnection as if they were notifications 
 about node changes.
 http://www.lucidimagination.com/search/document/e13ef390b882



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

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

[jira] [Commented] (SOLR-3582) Our ZooKeeper watchers respond to session events as if they are change events, creating undesirable side effects.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-3582:
---

If the session is expired you have to create all new watchers - you also have 
to create a new ZooKeeper client instance. Watchers do not span sessions.

 Our ZooKeeper watchers respond to session events as if they are change 
 events, creating undesirable side effects.
 -

 Key: SOLR-3582
 URL: https://issues.apache.org/jira/browse/SOLR-3582
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.0-BETA, 5.0


 As brought up by Trym R. Møller on the mailing list, we are responding to 
 watcher events about connection/disconnection as if they were notifications 
 about node changes.
 http://www.lucidimagination.com/search/document/e13ef390b882



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

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

[jira] [Commented] (SOLR-5654) Create a synonym filter factory that is (re)configurable, and capable of reporting its configuration, via REST API

[ASF subversion and git services (JIRA)]

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

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

Commit 1584211 from [~steve_rowe] in branch 'dev/trunk'
[ https://svn.apache.org/r1584211 ]

SOLR-5654: Create a synonym filter factory that is (re)configurable, and 
capable of reporting its configuration, via REST API

 Create a synonym filter factory that is (re)configurable, and capable of 
 reporting its configuration, via REST API
 --

 Key: SOLR-5654
 URL: https://issues.apache.org/jira/browse/SOLR-5654
 Project: Solr
  Issue Type: Sub-task
  Components: Schema and Analysis
Reporter: Steve Rowe
 Attachments: SOLR-5654.patch, SOLR-5654.patch, SOLR-5654.patch, 
 SOLR-5654.patch, SOLR-5654.patch


 A synonym filter factory could be (re)configurable via REST API by 
 registering with the RESTManager described in SOLR-5653, and then responding 
 to REST API calls to modify its init params and its synonyms resource file.
 Read-only (GET) REST API calls should also be provided, both for init params 
 and the synonyms resource file.
 It should be possible to add/remove/modify one or more entries in the 
 synonyms resource file.
 We should probably use JSON for the REST request body, as is done in the 
 Schema REST API methods.



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

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

[jira] [Updated] (SOLR-5654) Create a synonym filter factory that is (re)configurable, and capable of reporting its configuration, via REST API

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-5654:
-

Attachment: SOLR-5654.patch

{quote}
Here's an updated patch that uses a custom SynonymMap.Parser implementation 
instead of the SolrResourceLoader adapter approach based on the excellent 
suggestion by Steve Rowe. The only caveat is this requires making the 
SynonymFilterFactory.loadSynonyms method protected instead of private, which 
seemed like a good trade-off for being able to plug-in a different parser 
implementation.
{quote}

Looks great, thanks for making this change.  I see no problem with making 
{{SynonymFilterFactory.loadSynonyms()}} protected.

{quote}
I've also improved the test logic to verify synonyms get applied correctly 
after core reload.
{quote}

Cool, good test addition.

The attached patch includes a {{CHANGES.txt}} entry and some minor cleanups:

* Removed the custom boolean parsing logic in 
{{ManagedSynonmyFilterFactory.getIgnoreCase()}} in favor of the new 
{{NamedList.getBooleanArg()}} method.
* Add missing braces around single-line statement blocks after {{if}} and 
{{for}}
* Added {{Locale.ROOT}} as the first arg to several {{String.format()}} 
invocations to make {{ant precommit}} calm down.
* Converted explicit types in generic constructor invocations to the diamond 
operator.
* Converted schema references to {{ManagedSynonymFilterFactory}} from using the 
full package to the short form prefix {{solr.}}. 

I think it's ready to go.  I'll commit to trunk shortly.

 Create a synonym filter factory that is (re)configurable, and capable of 
 reporting its configuration, via REST API
 --

 Key: SOLR-5654
 URL: https://issues.apache.org/jira/browse/SOLR-5654
 Project: Solr
  Issue Type: Sub-task
  Components: Schema and Analysis
Reporter: Steve Rowe
 Attachments: SOLR-5654.patch, SOLR-5654.patch, SOLR-5654.patch, 
 SOLR-5654.patch, SOLR-5654.patch


 A synonym filter factory could be (re)configurable via REST API by 
 registering with the RESTManager described in SOLR-5653, and then responding 
 to REST API calls to modify its init params and its synonyms resource file.
 Read-only (GET) REST API calls should also be provided, both for init params 
 and the synonyms resource file.
 It should be possible to add/remove/modify one or more entries in the 
 synonyms resource file.
 We should probably use JSON for the REST request body, as is done in the 
 Schema REST API methods.



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

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

[jira] [Commented] (SOLR-5949) Stopwords in Boolean Query Result in invalid query

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-5949:


Bob: based on the information you've provided here, there is not enough 
info/evidence to reproduce the problem you are describing (in either 4.3.1, or 
4.7.1).

Please post a question to the solr-user list, and provide all of the details 
about what your configuration looks like (schema.xml and solrconfig.xml), what 
your data looks like, and what exactly your requests look like including what 
debugQuery output you get.  In general, you should always send questions like 
this to the mailing list, which is the primary forum for seeking help, and only 
file a Jira issue for a Bug once there is reproducible confirmation (or if 
requested by a dev -- sometimes even if folks can't reproduce it's helpful to 
create a jira to track it and upload detailed logs.)



My best off the cuff guesses, are that either you are using a phrase query even 
though you don't realize it, or that you have an edismax configuration that 
results in a query clause being created for your no word even though you 
think it's a stopword -- ie becuase of how your qf fields are configured.  In 
any case, as mentioned before, the mailing list is the appropriate forum to 
ask/discuss these problems.



Steps attempted to reproduce, using both the lucene QParser and edismax parser 
against the example configs provided in Solr 4.3.1 and Solr 4.7.1 ({{\*_en}} 
uses stopwords_en.txt containing no in both caes)...

{noformat}
$ curl -H 'Content-Type: application/json' -d '[{id:1,text_en:No Smoking 
Sign}]' 'http://localhost:8983/solr/collection1/update?commit=true'
{responseHeader:{status:0,QTime:560}}
$ curl -sS 
'http://localhost:8983/solr/collection1/select?debugQuery=truewt=jsonindent=truedefType=luceneq=text_en:(No+AND+Smoking+AND+Sign)'
{
  responseHeader:{
status:0,
QTime:4,
params:{
  debugQuery:true,
  indent:true,
  q:text_en:(No AND Smoking AND Sign),
  wt:json,
  defType:lucene}},
  response:{numFound:1,start:0,docs:[
  {
id:1,
text_en:[No Smoking Sign],
_version_:1464315067874934784}]
  },
  debug:{
rawquerystring:text_en:(No AND Smoking AND Sign),
querystring:text_en:(No AND Smoking AND Sign),
parsedquery:+text_en:smoke +text_en:sign,
parsedquery_toString:+text_en:smoke +text_en:sign,
...
$ curl -sS 
'http://localhost:8983/solr/collection1/select?debugQuery=truewt=jsonindent=truedefType=edismaxq=text_en:(No+AND+Smoking+AND+Sign)'
{
  responseHeader:{
status:0,
QTime:7,
params:{
  debugQuery:true,
  indent:true,
  q:text_en:(No AND Smoking AND Sign),
  wt:json,
  defType:edismax}},
  response:{numFound:1,start:0,docs:[
  {
id:1,
text_en:[No Smoking Sign],
_version_:1464315067874934784}]
  },
  debug:{
rawquerystring:text_en:(No AND Smoking AND Sign),
querystring:text_en:(No AND Smoking AND Sign),
parsedquery:(+(+text_en:smoke +text_en:sign))/no_coord,
parsedquery_toString:+(+text_en:smoke +text_en:sign),
$ curl -sS 
'http://localhost:8983/solr/collection1/select?debugQuery=truewt=jsonindent=truedefType=edismaxqf=text_enq=No+AND+Smoking+AND+Sign'
{
  responseHeader:{
status:0,
QTime:7,
params:{
  debugQuery:true,
  indent:true,
  q:No AND Smoking AND Sign,
  qf:text_en,
  wt:json,
  defType:edismax}},
  response:{numFound:1,start:0,docs:[
  {
id:1,
text_en:[No Smoking Sign],
_version_:1464315067874934784}]
  },
  debug:{
rawquerystring:No AND Smoking AND Sign,
querystring:No AND Smoking AND Sign,
parsedquery:(+(+DisjunctionMaxQuery((text_en:smoke)) 
+DisjunctionMaxQuery((text_en:sign/no_coord,
parsedquery_toString:+(+(text_en:smoke) +(text_en:sign)),
{noformat}



 Stopwords in Boolean Query Result in invalid query
 --

 Key: SOLR-5949
 URL: https://issues.apache.org/jira/browse/SOLR-5949
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 4.3
 Environment: Linux
Reporter: Bob Laferriere

 This seems a repeat of SOLR-261 which was fixed in 1.3 but I am seeing the 
 same behavior described. When I have a stopword in a boolean query the 
 resulting query is invalid. 
 e.g. Document -- No Smoking Sign
 Stopword: No
 Query:No AND Smoking AND Sign
 The resultant query is a boolean query with a blank field so an empty boolean 
 query. This is expanding as ? Smoking Sign which then leads to no matches 
 as ? AND Smoking AND sign has no match.
 The expected behavior is to remove the empty boolean clause from the query. 
 In the Analysis tool the parsing showing that No AND Smoking AND Sign 
 analyzes to 

[jira] [Resolved] (SOLR-5949) Stopwords in Boolean Query Result in invalid query

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-5949.


Resolution: Cannot Reproduce

 Stopwords in Boolean Query Result in invalid query
 --

 Key: SOLR-5949
 URL: https://issues.apache.org/jira/browse/SOLR-5949
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 4.3
 Environment: Linux
Reporter: Bob Laferriere

 This seems a repeat of SOLR-261 which was fixed in 1.3 but I am seeing the 
 same behavior described. When I have a stopword in a boolean query the 
 resulting query is invalid. 
 e.g. Document -- No Smoking Sign
 Stopword: No
 Query:No AND Smoking AND Sign
 The resultant query is a boolean query with a blank field so an empty boolean 
 query. This is expanding as ? Smoking Sign which then leads to no matches 
 as ? AND Smoking AND sign has no match.
 The expected behavior is to remove the empty boolean clause from the query. 
 In the Analysis tool the parsing showing that No AND Smoking AND Sign 
 analyzes to Smoke Sign. I would expect the same behavior by the 
 QueryParser, but this is not true. The real parsed query is trying to do the 
 following: empty boolean query Smoke Sign.
 The only workaround is to never allow stopwords in the query or turn off 
 stopwords entirely.



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

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

[jira] [Commented] (SOLR-5951) SolrDispatchFilter no longer displays useful error message on statup when logging jars are missing

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-5951: Fixed SolrDispatchFilter to throw useful exception on startup if 
SLF4j logging jars are missing

 SolrDispatchFilter no longer displays useful error message on statup when 
 logging jars are missing
 --

 Key: SOLR-5951
 URL: https://issues.apache.org/jira/browse/SOLR-5951
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.7, 4.7.1
Reporter: Uwe Schindler
Assignee: Uwe Schindler
 Fix For: 4.8, 5.0, 4.7.2

 Attachments: SOLR-5951.patch


 We no longer have logging jars in the webapp since SOLR-3706. Because of this 
 we added a extra check in SolrDispatchFilter's ctor to print a nice exception 
 if the logging jars were failing. This check was unfortunately never tests 
 and recently broke:
 The check delays initialization of the Logger instance to inside a try-catch 
 block inside the explicit ctor. If it fails with ClassNotFound, it throws 
 Exception.
 Recently we upgraded to a newer HttpClient version. Unfortunately 
 SolrDispatchFliter also has an implicit constructor a few lines before the 
 main constructor:
 {code:java}
   protected final HttpClient httpClient = HttpClientUtil.createClient(new 
 ModifiableSolrParams()); // -- this breaks the detection
   
   private static final Charset UTF8 = StandardCharsets.UTF_8;
   public SolrDispatchFilter() {
 try {
   log = LoggerFactory.getLogger(SolrDispatchFilter.class);
 } catch (NoClassDefFoundError e) {
   throw new SolrException(
   ErrorCode.SERVER_ERROR,
   Could not find necessary SLF4j logging jars. If using Jetty, the 
 SLF4j logging jars need to go in 
   +the jetty lib/ext directory. For other containers, the 
 corresponding directory should be used. 
   +For more information, see: 
 http://wiki.apache.org/solr/SolrLogging;,
   e);
 }
   }
 {code}
 The first line above {{HttpClientUtil.createClient(new 
 ModifiableSolrParams());}} breaks the whole thing, because it is executed 
 before the declared constructor. The user just sees a ClassNotFoundEx at this 
 line of code, the nice error message is hidden.
 Because this is so easy to break, we should make the whole thing more safe 
 (any maybe test it). 2 options:
 # Into the webapp add a fake Servlet (not bound to anything, just loaded 
 first) that does not use any Solr classes at all, nothing only plain java
 # Alternatively add a Superclass between ServletFilter and SolrDispatchFilter 
 (pkg-private). When the servlet container loads SolrDispatchFilter, it has in 
 any case to first load the superclass. And this superclass does the check and 
 throws ServletException or whatever (no Solr Exception) with the message from 
 the current code.
 I tend to the second approach, because it does not need to modify web-inf. It 
 will also work with other Solr servlets, they must just extend this hidden 
 class. I will provide a patch for that.



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

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

[jira] [Commented] (SOLR-5951) SolrDispatchFilter no longer displays useful error message on statup when logging jars are missing

[ASF subversion and git services (JIRA)]

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

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

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

Merged revision(s) 1584213 from lucene/dev/trunk:
SOLR-5951: Fixed SolrDispatchFilter to throw useful exception on startup if 
SLF4j logging jars are missing

 SolrDispatchFilter no longer displays useful error message on statup when 
 logging jars are missing
 --

 Key: SOLR-5951
 URL: https://issues.apache.org/jira/browse/SOLR-5951
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.7, 4.7.1
Reporter: Uwe Schindler
Assignee: Uwe Schindler
 Fix For: 4.8, 5.0, 4.7.2

 Attachments: SOLR-5951.patch


 We no longer have logging jars in the webapp since SOLR-3706. Because of this 
 we added a extra check in SolrDispatchFilter's ctor to print a nice exception 
 if the logging jars were failing. This check was unfortunately never tests 
 and recently broke:
 The check delays initialization of the Logger instance to inside a try-catch 
 block inside the explicit ctor. If it fails with ClassNotFound, it throws 
 Exception.
 Recently we upgraded to a newer HttpClient version. Unfortunately 
 SolrDispatchFliter also has an implicit constructor a few lines before the 
 main constructor:
 {code:java}
   protected final HttpClient httpClient = HttpClientUtil.createClient(new 
 ModifiableSolrParams()); // -- this breaks the detection
   
   private static final Charset UTF8 = StandardCharsets.UTF_8;
   public SolrDispatchFilter() {
 try {
   log = LoggerFactory.getLogger(SolrDispatchFilter.class);
 } catch (NoClassDefFoundError e) {
   throw new SolrException(
   ErrorCode.SERVER_ERROR,
   Could not find necessary SLF4j logging jars. If using Jetty, the 
 SLF4j logging jars need to go in 
   +the jetty lib/ext directory. For other containers, the 
 corresponding directory should be used. 
   +For more information, see: 
 http://wiki.apache.org/solr/SolrLogging;,
   e);
 }
   }
 {code}
 The first line above {{HttpClientUtil.createClient(new 
 ModifiableSolrParams());}} breaks the whole thing, because it is executed 
 before the declared constructor. The user just sees a ClassNotFoundEx at this 
 line of code, the nice error message is hidden.
 Because this is so easy to break, we should make the whole thing more safe 
 (any maybe test it). 2 options:
 # Into the webapp add a fake Servlet (not bound to anything, just loaded 
 first) that does not use any Solr classes at all, nothing only plain java
 # Alternatively add a Superclass between ServletFilter and SolrDispatchFilter 
 (pkg-private). When the servlet container loads SolrDispatchFilter, it has in 
 any case to first load the superclass. And this superclass does the check and 
 throws ServletException or whatever (no Solr Exception) with the message from 
 the current code.
 I tend to the second approach, because it does not need to modify web-inf. It 
 will also work with other Solr servlets, they must just extend this hidden 
 class. I will provide a patch for that.



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

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