[jira] Commented: (SOLR-1469) TestReplicationHandler failure

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-1469:


OK, I think this particular one might be a bug in the test.
Replication is disabled only after the master commit - and in the test log 
provided it looks like the start of a replication sneeks in there, and finishes 
after the addDoc() on the slave.

I'll leave the tests running in a loop tonight and see if moving the 
disableReplication before the master commit fixes things.

> TestReplicationHandler failure
> --
>
> Key: SOLR-1469
> URL: https://issues.apache.org/jira/browse/SOLR-1469
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
> Attachments: TestReplicationHandler.FAILED.210743
>
>
> TestReplicationHandler seems to fail often.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1470) index formats always compound

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-1470:
---

You know, it says that only works with LogMergePolicy (setUseCompoundFile) or 
it throws an exception. Thats another bug I think.

Should only set it that way if its that policy.

> index formats always compound
> -
>
> Key: SOLR-1470
> URL: https://issues.apache.org/jira/browse/SOLR-1470
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
> Fix For: 1.4
>
> Attachments: SOLR-1470.patch
>
>
> Seems like the index format is always compound now.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: compound file format being used

[Mark Miller]

Yonik Seeley wrote:
> Hey, it seems like the compound file format is always being used
> now... even in the example, when the config says not to.
> Anyone notice when this started?
>
> -Yonik
> http://www.lucidimagination.com
>   
Its being set correctly. Something with the mergepolicy?

-- 
- Mark

http://www.lucidimagination.com

[jira] Updated: (SOLR-1470) index formats always compound

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-1470:
--

Attachment: SOLR-1470.patch

I think this will fix it

> index formats always compound
> -
>
> Key: SOLR-1470
> URL: https://issues.apache.org/jira/browse/SOLR-1470
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
> Fix For: 1.4
>
> Attachments: SOLR-1470.patch
>
>
> Seems like the index format is always compound now.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: compound file format being used

[Mark Miller]

Mark Miller wrote:
> Yonik Seeley wrote:
>   
>> Hey, it seems like the compound file format is always being used
>> now... even in the example, when the config says not to.
>> Anyone notice when this started?
>>
>> -Yonik
>> http://www.lucidimagination.com
>>   
>> 
> Its being set correctly. Something with the mergepolicy?
>
>   
Because we set the mergpolicy after, I'm guessing it doesnt take.

-- 
- Mark

http://www.lucidimagination.com

[jira] Created: (SOLR-1470) index formats always compound

[Yonik Seeley (JIRA)]

index formats always compound
-

 Key: SOLR-1470
 URL: https://issues.apache.org/jira/browse/SOLR-1470
 Project: Solr
  Issue Type: Bug
Reporter: Yonik Seeley
 Fix For: 1.4


Seems like the index format is always compound now.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1469) TestReplicationHandler failure

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-1469:
---

Are you using Windows? Havn't gotten it to fail on Linux yet.

Perhaps we should add a check of the status returned from index in there?

> TestReplicationHandler failure
> --
>
> Key: SOLR-1469
> URL: https://issues.apache.org/jira/browse/SOLR-1469
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
> Attachments: TestReplicationHandler.FAILED.210743
>
>
> TestReplicationHandler seems to fail often.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

compound file format being used

[Yonik Seeley]

Hey, it seems like the compound file format is always being used
now... even in the example, when the config says not to.
Anyone notice when this started?

-Yonik
http://www.lucidimagination.com

[jira] Updated: (SOLR-1469) TestReplicationHandler failure

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-1469:
---

Attachment: TestReplicationHandler.FAILED.210743

Attaching one particular worrying failure.

Testcase: testReplicateAfterWrite2Slave took 2.656 sec
FAILED
expected:<1> but was:<0>
junit.framework.AssertionFailedError: expected:<1> but was:<0>
at 
org.apache.solr.handler.TestReplicationHandler.testReplicateAfterWrite2Slave(TestReplicationHandler.java:424)

So replication was disabled, a doc was added to the slave, but then the search 
for it failed.  How can that be?

> TestReplicationHandler failure
> --
>
> Key: SOLR-1469
> URL: https://issues.apache.org/jira/browse/SOLR-1469
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
> Attachments: TestReplicationHandler.FAILED.210743
>
>
> TestReplicationHandler seems to fail often.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SOLR-1469) TestReplicationHandler failure

[Yonik Seeley (JIRA)]

TestReplicationHandler failure
--

 Key: SOLR-1469
 URL: https://issues.apache.org/jira/browse/SOLR-1469
 Project: Solr
  Issue Type: Bug
Reporter: Yonik Seeley


TestReplicationHandler seems to fail often.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: solr hudson builds

[Chris Hostetter]

: I've switched "ant test" to use the plain formatter rather than the
: XML formatter - I think this is a lot more sane for humans looking at
: the output.  XML escaped failing assertions are no fun to read.  And

...although if you use "ant test-reports" you're going to want to add 
junit.formatter=xml to your personal build.properties file or it's not 
going to work anymore.

: XML can be used by defining the junit.formatter system property.
: ant clean test -Djunit.formatter=xml
: 
: Does anyone know how to change the hudson build to add that property?

i added it -- it's just an addition to the "ant targets" text areas in the 
hudson config screens.


-Hoss

[jira] Commented: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-1221:
---

bq. In Lucene, the fix would only be needed for highlighting in 2.9.1, 3.0 will 
have no RangeQuery anymore.

You can have custom queryparsers in Solr, so you can't say definitely its not 
used.

Whether I'm concerned about it depends on if we a 2.9.1 - if we do, I'll fix 
it. If we don't I won't.

> Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by 
> default
> --
>
> Key: SOLR-1221
> URL: https://issues.apache.org/jira/browse/SOLR-1221
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch, 
> SOLR-1221.patch
>
>
> To improve the out of the box experience of Solr 1.4, I really think we 
> should make this change. You will still be able to turn both off.
> Comments?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (SOLR-1449) solrconfig.xml syntax to add classpath elements from outside of instanceDir

[Hoss Man (JIRA)]

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

Hoss Man reassigned SOLR-1449:
--

Assignee: Hoss Man

> solrconfig.xml syntax to add classpath elements from outside of instanceDir
> ---
>
> Key: SOLR-1449
> URL: https://issues.apache.org/jira/browse/SOLR-1449
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 1.4
>
> Attachments: SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch, 
> SOLR-1449.patch, SOLR-1449.patch
>
>
> the idea has been discussed numerous times that it would be nice if there was 
> a way to configure a core to load plugins from specific jars (or "classes" 
> style directories) by path  w/o needing to copy them to the "./lib" dir in 
> the instanceDir.
> The current workaround is "symlinks" but that doesn't really help the 
> situation of the Solr Release artifacts, where we wind up making numerous 
> copies of jars to support multiple example directories (you can't have 
> reliable symlinks in zip files)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1449) solrconfig.xml syntax to add classpath elements from outside of instanceDir

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-1449:


bq. should we reference the libs in contrib (where they are actually checked 
in) rather than dist? "ant example" doesn't currently copy anything to dist... 
and avoiding another copy of those libraries would be nice too.

FYI: We already copy them to ./dist/ as part of dist-contrib, and "ant example" 
already depends on dist-contrib so nothing changed there.

Ultimately it's a question of how we want to solve SOLR-1433 ... this patch 
assumes we keep including the full ./dist structure that we have now for all 
the jars in our artifacts 9and SOLR-1433 could be solved w/o changing that by 
exclusing the source locations of those libs), but if the solution to SOLR-1433 
is to not copy libs to ./dist at all then it's trivial to change the  refs 
in the solrconfig.xml files to point at the original locations.

> solrconfig.xml syntax to add classpath elements from outside of instanceDir
> ---
>
> Key: SOLR-1449
> URL: https://issues.apache.org/jira/browse/SOLR-1449
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 1.4
>
> Attachments: SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch, 
> SOLR-1449.patch, SOLR-1449.patch
>
>
> the idea has been discussed numerous times that it would be nice if there was 
> a way to configure a core to load plugins from specific jars (or "classes" 
> style directories) by path  w/o needing to copy them to the "./lib" dir in 
> the instanceDir.
> The current workaround is "symlinks" but that doesn't really help the 
> situation of the Solr Release artifacts, where we wind up making numerous 
> copies of jars to support multiple example directories (you can't have 
> reliable symlinks in zip files)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1449) solrconfig.xml syntax to add classpath elements from outside of instanceDir

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-1449:
---

Attachment: SOLR-1449.patch

minor update to the previous patch...

1) the patch command didn't like the empty files, so now they have a single 
newline in them.
2) because of a typo, javadoc-all on the trunk is getting lucking and finding 
the download clustering jars only if they've already been copied to the 
example/lib ... since the patch stops the copying to example/lib i fixed the 
topy so it finds them in lib/downloads

> solrconfig.xml syntax to add classpath elements from outside of instanceDir
> ---
>
> Key: SOLR-1449
> URL: https://issues.apache.org/jira/browse/SOLR-1449
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 1.4
>
> Attachments: SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch, 
> SOLR-1449.patch, SOLR-1449.patch
>
>
> the idea has been discussed numerous times that it would be nice if there was 
> a way to configure a core to load plugins from specific jars (or "classes" 
> style directories) by path  w/o needing to copy them to the "./lib" dir in 
> the instanceDir.
> The current workaround is "symlinks" but that doesn't really help the 
> situation of the Solr Release artifacts, where we wind up making numerous 
> copies of jars to support multiple example directories (you can't have 
> reliable symlinks in zip files)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-1221:
-

Does RangeQuery really need to be highlighted? It is not used anywhere in Solr 
(I removed all occurences in the issue about TermRangeQuery), so why handle it?

In Lucene, the fix would only be needed for highlighting in 2.9.1, 3.0 will 
have no RangeQuery anymore.

> Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by 
> default
> --
>
> Key: SOLR-1221
> URL: https://issues.apache.org/jira/browse/SOLR-1221
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch, 
> SOLR-1221.patch
>
>
> To improve the out of the box experience of Solr 1.4, I really think we 
> should make this change. You will still be able to turn both off.
> Comments?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-1221:
---

bq. deprec ConstantScoreRangeQuery (if ever used in Solr) would also have the 
problem... (but it extends TermRangeQuery, so should be catched before).

Right - anything that extends TermRangeQuery should be fine. It has special 
handling.

bq. would not work (final and no ctors).

Thanks - I actually saw that when I was messing with the Highlighter earlier 
today, but I didn't put 2 and 2 together.
Sounds like the updated Highlighter jar is the solution.

> Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by 
> default
> --
>
> Key: SOLR-1221
> URL: https://issues.apache.org/jira/browse/SOLR-1221
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch, 
> SOLR-1221.patch
>
>
> To improve the out of the box experience of Solr 1.4, I really think we 
> should make this change. You will still be able to turn both off.
> Comments?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-1221:
-

deprec ConstantScoreRangeQuery (if ever used in Solr) would also have the 
problem... (but it extends TermRangeQuery, so should be catched before).

bq. 3. use an overridden version of NumericQuery in Solr that returns a 
placeholder term from getTerm

would not work (final and no ctors).

> Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by 
> default
> --
>
> Key: SOLR-1221
> URL: https://issues.apache.org/jira/browse/SOLR-1221
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch, 
> SOLR-1221.patch
>
>
> To improve the out of the box experience of Solr 1.4, I really think we 
> should make this change. You will still be able to turn both off.
> Comments?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

solr hudson builds

[Yonik Seeley]

I've switched "ant test" to use the plain formatter rather than the
XML formatter - I think this is a lot more sane for humans looking at
the output.  XML escaped failing assertions are no fun to read.  And
of course there is the buffering bug too - running any really large
test that prodoces output using the XML formatter can run you out of
memory.

XML can be used by defining the junit.formatter system property.
ant clean test -Djunit.formatter=xml

Does anyone know how to change the hudson build to add that property?

-Yonik
http://www.lucidimagination.com

[jira] Commented: (SOLR-1449) solrconfig.xml syntax to add classpath elements from outside of instanceDir

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-1449:


bq.  solrconfig.xml syntax to add classpath elements from outside of instanceDir
> ---
>
> Key: SOLR-1449
> URL: https://issues.apache.org/jira/browse/SOLR-1449
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 1.4
>
> Attachments: SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch, 
> SOLR-1449.patch
>
>
> the idea has been discussed numerous times that it would be nice if there was 
> a way to configure a core to load plugins from specific jars (or "classes" 
> style directories) by path  w/o needing to copy them to the "./lib" dir in 
> the instanceDir.
> The current workaround is "symlinks" but that doesn't really help the 
> situation of the Solr Release artifacts, where we wind up making numerous 
> copies of jars to support multiple example directories (you can't have 
> reliable symlinks in zip files)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1449) solrconfig.xml syntax to add classpath elements from outside of instanceDir

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-1449:
---

Attachment: SOLR-1449.patch

checkpoint patch, new additions...

1. updated TestConfig to also assert that the existing automatic lib dir 
support works (i don't see any evidence that we already had a test for this)
2. replaced the TODO's in the example solrconfig.xml with documentation 
explaining hte new  directives.
3. updated the README in the example solr home so that the note about ./lib 
also mentions the  config option
4. updated the build.xml and example/solrconfig.xml for the clusturing contrib 
so that they don't copy just for the example
5. fixed a small bug in the clustering example schema (that example reuses the 
main example docs, but wasn't ignoring unexpected fields which have since been 
added to those docs on the trunk since the clustering example was added)


> solrconfig.xml syntax to add classpath elements from outside of instanceDir
> ---
>
> Key: SOLR-1449
> URL: https://issues.apache.org/jira/browse/SOLR-1449
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 1.4
>
> Attachments: SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch, 
> SOLR-1449.patch
>
>
> the idea has been discussed numerous times that it would be nice if there was 
> a way to configure a core to load plugins from specific jars (or "classes" 
> style directories) by path  w/o needing to copy them to the "./lib" dir in 
> the instanceDir.
> The current workaround is "symlinks" but that doesn't really help the 
> situation of the Solr Release artifacts, where we wind up making numerous 
> copies of jars to support multiple example directories (you can't have 
> reliable symlinks in zip files)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (SOLR-1468) Solrj bug when using facet.missing

[Yonik Seeley (JIRA)]

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

Yonik Seeley resolved SOLR-1468.


Resolution: Fixed

I just committed a patch for this... thanks for the bug report!

> Solrj bug when using facet.missing
> --
>
> Key: SOLR-1468
> URL: https://issues.apache.org/jira/browse/SOLR-1468
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 1.3
>Reporter: Tomasz Wrobel
>Assignee: Yonik Seeley
> Fix For: 1.4
>
>
> Setting queryParams.setMissing("true") or 
> queryParams.set(FacetParams.FACET_MISSING, "true") in Solrj query parameters 
> object results in an exception:
> ...
> Caused by: org.apache.solr.common.SolrException: parsing error
> at 
> org.apache.solr.client.solrj.impl.XMLResponseParser.processResponse(XMLResponseParser.java:139)
> at 
> org.apache.solr.client.solrj.impl.XMLResponseParser.processResponse(XMLResponseParser.java:100)
> at 
> org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:385)
> at 
> org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:183)
> at 
> org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:90)
> ... 37 more
> Caused by: javax.xml.stream.XMLStreamException: ParseError at 
> [row,col]:[3,788]
> Message: requires 'name' attribute: int
> at 
> org.apache.solr.client.solrj.impl.XMLResponseParser.readNamedList(XMLResponseParser.java:231)
> at 
> org.apache.solr.client.solrj.impl.XMLResponseParser.readNamedList(XMLResponseParser.java:236)
> at 
> org.apache.solr.client.solrj.impl.XMLResponseParser.readNamedList(XMLResponseParser.java:236)
> at 
> org.apache.solr.client.solrj.impl.XMLResponseParser.readNamedList(XMLResponseParser.java:236)
> at 
> org.apache.solr.client.solrj.impl.XMLResponseParser.processResponse(XMLResponseParser.java:124)
> ... 41 more
> When "facet.missing" parameter is set to "true" Solr is returning response 
> containing "int" element with no "name", which possibly causes the Solrj 
> parsing problem. Sample server response may look like:
> 
> 5559
> 5547
> 5412
> 0
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1468) Solrj bug when using facet.missing

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-1468:
---

Fix Version/s: 1.4
 Assignee: Yonik Seeley

> Solrj bug when using facet.missing
> --
>
> Key: SOLR-1468
> URL: https://issues.apache.org/jira/browse/SOLR-1468
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 1.3
>Reporter: Tomasz Wrobel
>Assignee: Yonik Seeley
> Fix For: 1.4
>
>
> Setting queryParams.setMissing("true") or 
> queryParams.set(FacetParams.FACET_MISSING, "true") in Solrj query parameters 
> object results in an exception:
> ...
> Caused by: org.apache.solr.common.SolrException: parsing error
> at 
> org.apache.solr.client.solrj.impl.XMLResponseParser.processResponse(XMLResponseParser.java:139)
> at 
> org.apache.solr.client.solrj.impl.XMLResponseParser.processResponse(XMLResponseParser.java:100)
> at 
> org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:385)
> at 
> org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:183)
> at 
> org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:90)
> ... 37 more
> Caused by: javax.xml.stream.XMLStreamException: ParseError at 
> [row,col]:[3,788]
> Message: requires 'name' attribute: int
> at 
> org.apache.solr.client.solrj.impl.XMLResponseParser.readNamedList(XMLResponseParser.java:231)
> at 
> org.apache.solr.client.solrj.impl.XMLResponseParser.readNamedList(XMLResponseParser.java:236)
> at 
> org.apache.solr.client.solrj.impl.XMLResponseParser.readNamedList(XMLResponseParser.java:236)
> at 
> org.apache.solr.client.solrj.impl.XMLResponseParser.readNamedList(XMLResponseParser.java:236)
> at 
> org.apache.solr.client.solrj.impl.XMLResponseParser.processResponse(XMLResponseParser.java:124)
> ... 41 more
> When "facet.missing" parameter is set to "true" Solr is returning response 
> containing "int" element with no "name", which possibly causes the Solrj 
> parsing problem. Sample server response may look like:
> 
> 5559
> 5547
> 5412
> 0
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Deleted: (SOLR-1467) SolrJ XML parser errors on null names in a NamedList

[Yonik Seeley (JIRA)]

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

Yonik Seeley deleted SOLR-1467:
---


> SolrJ XML parser errors on null names in a NamedList
> 
>
> Key: SOLR-1467
> URL: https://issues.apache.org/jira/browse/SOLR-1467
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SOLR-1468) Solrj bug when using facet.missing

[Tomasz Wrobel (JIRA)]

Solrj bug when using facet.missing
--

 Key: SOLR-1468
 URL: https://issues.apache.org/jira/browse/SOLR-1468
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 1.3
Reporter: Tomasz Wrobel


Setting queryParams.setMissing("true") or 
queryParams.set(FacetParams.FACET_MISSING, "true") in Solrj query parameters 
object results in an exception:
...
Caused by: org.apache.solr.common.SolrException: parsing error
at 
org.apache.solr.client.solrj.impl.XMLResponseParser.processResponse(XMLResponseParser.java:139)
at 
org.apache.solr.client.solrj.impl.XMLResponseParser.processResponse(XMLResponseParser.java:100)
at 
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:385)
at 
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:183)
at 
org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:90)
... 37 more
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[3,788]
Message: requires 'name' attribute: int
at 
org.apache.solr.client.solrj.impl.XMLResponseParser.readNamedList(XMLResponseParser.java:231)
at 
org.apache.solr.client.solrj.impl.XMLResponseParser.readNamedList(XMLResponseParser.java:236)
at 
org.apache.solr.client.solrj.impl.XMLResponseParser.readNamedList(XMLResponseParser.java:236)
at 
org.apache.solr.client.solrj.impl.XMLResponseParser.readNamedList(XMLResponseParser.java:236)
at 
org.apache.solr.client.solrj.impl.XMLResponseParser.processResponse(XMLResponseParser.java:124)
... 41 more

When "facet.missing" parameter is set to "true" Solr is returning response 
containing "int" element with no "name", which possibly causes the Solrj 
parsing problem. Sample server response may look like:


5559
5547
5412
0


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SOLR-1467) SolrJ XML parser errors on null names in a NamedList

[Yonik Seeley (JIRA)]

SolrJ XML parser errors on null names in a NamedList


 Key: SOLR-1467
 URL: https://issues.apache.org/jira/browse/SOLR-1467
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 1.3
Reporter: Yonik Seeley
 Fix For: 1.4




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (SOLR-1447) Simple property injection

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar resolved SOLR-1447.
-

Resolution: Fixed

Committed revision 819401.

> Simple property injection 
> --
>
> Key: SOLR-1447
> URL: https://issues.apache.org/jira/browse/SOLR-1447
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1447-indexDefault-test.patch, 
> SOLR-1447-indexDefault-test.patch, SOLR-1447.patch, SOLR-1447.patch, 
> SOLR-1447.patch, SOLR-1447.patch, SOLR-1447.patch, SOLR-1447.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> MergePolicy and MergeScheduler require property injection.  We'll allow these 
> and probably other cases in this patch using Java reflection.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1447) Simple property injection

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-1447:


Attachment: SOLR-1447-indexDefault-test.patch

Fix which passes the test case posted earlier. I'll commit this shortly.

> Simple property injection 
> --
>
> Key: SOLR-1447
> URL: https://issues.apache.org/jira/browse/SOLR-1447
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1447-indexDefault-test.patch, 
> SOLR-1447-indexDefault-test.patch, SOLR-1447.patch, SOLR-1447.patch, 
> SOLR-1447.patch, SOLR-1447.patch, SOLR-1447.patch, SOLR-1447.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> MergePolicy and MergeScheduler require property injection.  We'll allow these 
> and probably other cases in this patch using Java reflection.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1447) Simple property injection

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-1447:


Attachment: SOLR-1447-indexDefault-test.patch

Here's a test case which fails.

Still trying to understand and debug.

> Simple property injection 
> --
>
> Key: SOLR-1447
> URL: https://issues.apache.org/jira/browse/SOLR-1447
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1447-indexDefault-test.patch, SOLR-1447.patch, 
> SOLR-1447.patch, SOLR-1447.patch, SOLR-1447.patch, SOLR-1447.patch, 
> SOLR-1447.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> MergePolicy and MergeScheduler require property injection.  We'll allow these 
> and probably other cases in this patch using Java reflection.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (SOLR-1447) Simple property injection

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar reopened SOLR-1447:
-


Re-opening because the mergeScheduler and mergePolicy specified in the 
indexDefaults section is not honored.

> Simple property injection 
> --
>
> Key: SOLR-1447
> URL: https://issues.apache.org/jira/browse/SOLR-1447
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1447.patch, SOLR-1447.patch, SOLR-1447.patch, 
> SOLR-1447.patch, SOLR-1447.patch, SOLR-1447.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> MergePolicy and MergeScheduler require property injection.  We'll allow these 
> and probably other cases in this patch using Java reflection.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default

[Mark Miller (JIRA)]

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

Mark Miller edited comment on SOLR-1221 at 9/27/09 12:36 PM:
-

Sorry - should have been more clear.

The bug is hidden on trunk at the moment - Koji pointed out that I missed a 
spot, and on trunk right now, queries are being rewritten by default when they 
shouldnt be.

Now that you mention it though, the issue is not just with NumericRange (I just 
assumed that was being gen'd cause I saw the problem with it), but its also 
going to be with the
deprecated RangeQuery it looks. *edit* actually - since RangeQuery no longer 
extends MultiTermQuery, it won't cause the error - it just won't highlight.

*edit*

which really argues for a jar update - I can fix all causes with one simple fix 
- checking if getTerm returns null.

  was (Author: markrmil...@gmail.com):
Sorry - should have been more clear.

The bug is hidden on trunk at the moment - Koji pointed out that I missed a 
spot, and on trunk right now, queries are being rewritten by default when they 
shouldnt be.

Now that you mention it though, the issue is not just with NumericRange (I just 
assumed that was being gen'd cause I saw the problem with it), but its also 
going to be with the
deprecated RangeQuery it looks.

*edit*

which really argues for a jar update - I can fix all causes with one simple fix 
- checking if getTerm returns null.
  
> Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by 
> default
> --
>
> Key: SOLR-1221
> URL: https://issues.apache.org/jira/browse/SOLR-1221
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch, 
> SOLR-1221.patch
>
>
> To improve the out of the box experience of Solr 1.4, I really think we 
> should make this change. You will still be able to turn both off.
> Comments?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-1221:
---

bq. The query parser produces a normal term query for numeric queries.

Also, I shouldn't have said NumericQuery - NumericRangeQuery - sorry again.

> Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by 
> default
> --
>
> Key: SOLR-1221
> URL: https://issues.apache.org/jira/browse/SOLR-1221
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch, 
> SOLR-1221.patch
>
>
> To improve the out of the box experience of Solr 1.4, I really think we 
> should make this change. You will still be able to turn both off.
> Comments?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-1221:
--

Attachment: SOLR-1221.patch

this patch needs to be applied to finish the issue - but for now it will cause 
tests to fail.

> Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by 
> default
> --
>
> Key: SOLR-1221
> URL: https://issues.apache.org/jira/browse/SOLR-1221
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch, 
> SOLR-1221.patch
>
>
> To improve the out of the box experience of Solr 1.4, I really think we 
> should make this change. You will still be able to turn both off.
> Comments?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Fwd: 8 for 1.4

[Chris Hostetter]

: > On S-1294, the SolrJS patch, I yet again have concerns about even including
: > this, given the lack of activity (from Matthias, the original author and
...
: > true for others too.  At a minimum, I think S-1294 should be pushed to 1.5.
: > Next up, I think we consider pulling SolrJS from the release, but keeping it
: > in trunk and officially releasing it with either 1.5 or 1.4.1, assuming its
: > gotten some love in the meantime.  If by then it has no love, I vote we
: > remove it and let the fork maintain it and point people there.

If we leave SolrJS in the release, then i can't imagine any reason why the 
patch in SOLR-1294 shouldn't be committed ... no one is going to step up 
and help maintain it if we aren't committing the patches that people offer 
to improve it.

That said: as a client that isn't tightly coupled to the Solr Interals, if 
there's already a better SolrJS fork out there that has a community 
actively maintaining it, then I don't see a strong reason for us to start 
including SolrJS in 1.4. 

Summary...
+0 on SolrJS being in 1.4
+1 on SOLR-1294 being in 1.4 if SolrJS is in 1.4

-Hoss

[jira] Commented: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-1221:
---

Sorry - should have been more clear.

The bug is hidden on trunk at the moment - Koji pointed out that I missed a 
spot, and on trunk right now, queries are being rewritten by default when they 
shouldnt be.

Now that you mention it though, the issue is not just with NumericRange (I just 
assumed that was being gen'd cause I saw the problem with it), but its also 
going to be with the
deprecated RangeQuery it looks.

> Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by 
> default
> --
>
> Key: SOLR-1221
> URL: https://issues.apache.org/jira/browse/SOLR-1221
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch
>
>
> To improve the out of the box experience of Solr 1.4, I really think we 
> should make this change. You will still be able to turn both off.
> Comments?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default

[Mark Miller (JIRA)]

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

Mark Miller edited comment on SOLR-1221 at 9/27/09 11:54 AM:
-

Sorry - should have been more clear.

The bug is hidden on trunk at the moment - Koji pointed out that I missed a 
spot, and on trunk right now, queries are being rewritten by default when they 
shouldnt be.

Now that you mention it though, the issue is not just with NumericRange (I just 
assumed that was being gen'd cause I saw the problem with it), but its also 
going to be with the
deprecated RangeQuery it looks.

*edit*

which really argues for a jar update - I can fix all causes with one simple fix 
- checking if getTerm returns null.

  was (Author: markrmil...@gmail.com):
Sorry - should have been more clear.

The bug is hidden on trunk at the moment - Koji pointed out that I missed a 
spot, and on trunk right now, queries are being rewritten by default when they 
shouldnt be.

Now that you mention it though, the issue is not just with NumericRange (I just 
assumed that was being gen'd cause I saw the problem with it), but its also 
going to be with the
deprecated RangeQuery it looks.
  
> Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by 
> default
> --
>
> Key: SOLR-1221
> URL: https://issues.apache.org/jira/browse/SOLR-1221
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch
>
>
> To improve the out of the box experience of Solr 1.4, I really think we 
> should make this change. You will still be able to turn both off.
> Comments?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-1221:


How can one reproduce this bug?  The query parser produces a normal term query 
for numeric queries.

Something like this does not cause an error on trunk:
http://localhost:8983/solr/select?q=popularity:6&hl=true&hl.fl=popularity



> Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by 
> default
> --
>
> Key: SOLR-1221
> URL: https://issues.apache.org/jira/browse/SOLR-1221
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch
>
>
> To improve the out of the box experience of Solr 1.4, I really think we 
> should make this change. You will still be able to turn both off.
> Comments?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Commented: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default

[Mark Miller]

Chris Hostetter wrote:
> : 3. use an overridden version of NumericQuery in Solr that returns a 
> placeholder term from getTerm
>
> on the surface that doesn't sound too horrific.  just make it final and 
> deprecated and open an issue to remove it when upgrading to Lucene 3.0.
>
>
> -Hoss
>
>   
Yeah, your right - the ugliness factor blinded me a bit I suppose.

But there is also the issue of custom query parsers out there. If they
make the mistake
of generating Lucene NumericRangeQueries, they will be in the same boat.

-- 
- Mark

http://www.lucidimagination.com

Re: [jira] Commented: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default

[Chris Hostetter]

: 3. use an overridden version of NumericQuery in Solr that returns a 
placeholder term from getTerm

on the surface that doesn't sound too horrific.  just make it final and 
deprecated and open an issue to remove it when upgrading to Lucene 3.0.


-Hoss

[jira] Commented: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-1221:
---

I don't see one -

ugly options I can think of -

1. extend highlighter and duplicate a ton of code with a fix - obviously not 
really an option
2. run through the query first and rebuild it without the numericrangequery part
3. use an overridden version of NumericQuery in Solr that returns a placeholder 
term from getTerm

None of these are really viable IMO though.

> Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by 
> default
> --
>
> Key: SOLR-1221
> URL: https://issues.apache.org/jira/browse/SOLR-1221
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch
>
>
> To improve the out of the box experience of Solr 1.4, I really think we 
> should make this change. You will still be able to turn both off.
> Comments?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-1221:


bq. What do people thing about putting in an updated Highlighter jar with a 
fix? 

+1, If there's not an easy way to work around it in Solr.


> Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by 
> default
> --
>
> Key: SOLR-1221
> URL: https://issues.apache.org/jira/browse/SOLR-1221
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch
>
>
> To improve the out of the box experience of Solr 1.4, I really think we 
> should make this change. You will still be able to turn both off.
> Comments?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-1221:
---

What do people thing about putting in an updated Highlighter jar with a fix?

> Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by 
> default
> --
>
> Key: SOLR-1221
> URL: https://issues.apache.org/jira/browse/SOLR-1221
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch
>
>
> To improve the out of the box experience of Solr 1.4, I really think we 
> should make this change. You will still be able to turn both off.
> Comments?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: print junit test name

[Yonik Seeley]

On Sun, Sep 27, 2009 at 1:13 PM, Chris Hostetter
 wrote:
>
> : Right now, if I see something funny (like an exception that doesn't
> : cause a test failure) in a big junit test report, it's hard to tell
> : what test it was in - the output for each test is simply catenated,
> : with no separator.
>
> what do you mean by output?  System.out? System.err? messages logged via
> SLF4J?

All of the above.

> : Is there a way to get junit to print this info, or do we need to do
> : subclass TestCase, and do it ourselves?
>
> getName() can be called by any method in a testCase at anytime to know
> which test method is currently being executed (or in the case of
> setUp/tearDown about to be executed) so we could always modify
> AbstractSolrTestCase to print that out in setUp/tearDown
>
> if you're specificly talking about exceptions that get writen via the
> logger then the ideal solution is something i've been meaning to look into
> when i have some more time: a LogHandler dynamicly registered during
> setUp() that records any log messages above a certain level (ERROR) that
> test methods can use to assert that certain behavior did/didn't trigger
> messages matching a regex (ie: tests of bad config/input that want to
> assert an error was logged vs test of good configs/input that assert no
> errors were logged)  the tearDown method can then assert that the
> LogHandler doesn't have any LogMessages left in it's queue the test didn't
> already account for.

Sweet!  Not what I was talking about, but trying to filter malignant
from benign exceptions has been a constant thorn in my side.

-Yonik
http://www.lucidimagination.com

Re: print junit test name

[Chris Hostetter]

: Right now, if I see something funny (like an exception that doesn't
: cause a test failure) in a big junit test report, it's hard to tell
: what test it was in - the output for each test is simply catenated,
: with no separator.

what do you mean by output?  System.out? System.err? messages logged via 
SLF4J?

: Is there a way to get junit to print this info, or do we need to do
: subclass TestCase, and do it ourselves?

getName() can be called by any method in a testCase at anytime to know 
which test method is currently being executed (or in the case of 
setUp/tearDown about to be executed) so we could always modify 
AbstractSolrTestCase to print that out in setUp/tearDown

if you're specificly talking about exceptions that get writen via the 
logger then the ideal solution is something i've been meaning to look into 
when i have some more time: a LogHandler dynamicly registered during 
setUp() that records any log messages above a certain level (ERROR) that 
test methods can use to assert that certain behavior did/didn't trigger 
messages matching a regex (ie: tests of bad config/input that want to 
assert an error was logged vs test of good configs/input that assert no 
errors were logged)  the tearDown method can then assert that the 
LogHandler doesn't have any LogMessages left in it's queue the test didn't 
already account for.



-Hoss

[jira] Commented: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-1221:
---

Easy enough to side step this bug in Lucene for now - but if we release with 
pure Lucene 2.9, not sure what I'm going to do here...

> Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by 
> default
> --
>
> Key: SOLR-1221
> URL: https://issues.apache.org/jira/browse/SOLR-1221
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch
>
>
> To improve the out of the box experience of Solr 1.4, I really think we 
> should make this change. You will still be able to turn both off.
> Comments?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1458) Java Replication error: NullPointerException SEVERE: SnapPull failed on 2009-09-22 nightly

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-1458:


I've committed this patch.  I'm occasionally getting errors in 
TestReplicationHandler... but I also get occasional errors there w/o this patch!

Artem, it would be great if you could test trunk and see if your problems are 
fixed.

> Java Replication error: NullPointerException SEVERE: SnapPull failed on 
> 2009-09-22 nightly
> --
>
> Key: SOLR-1458
> URL: https://issues.apache.org/jira/browse/SOLR-1458
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Affects Versions: 1.4
> Environment: CentOS x64
> 8GB RAM
> Tomcat, running with 7G max memory; memory usage is <2GB, so it's not the 
> problem
> Host a: master
> Host b: slave
> Multiple single core Solr instances, using JNDI.
> Java replication
>Reporter: Artem Russakovskii
>Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1458.patch, SOLR-1458.patch, SOLR-1458.patch, 
> SOLR-1458.patch, SOLR-1458.patch, SolrDeletionPolicy.patch, 
> SolrDeletionPolicy.patch
>
>
> After finally figuring out the new Java based replication, we have started 
> both the slave and the master and issued optimize to all master Solr 
> instances. This triggered some replication to go through just fine, but it 
> looks like some of it is failing.
> Here's what I'm getting in the slave logs, repeatedly for each shard:
> {code} 
> SEVERE: SnapPull failed 
> java.lang.NullPointerException
> at 
> org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:271)
> at 
> org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:258)
> at org.apache.solr.handler.SnapPuller$1.run(SnapPuller.java:159)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at 
> java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> {code} 
> If I issue an optimize again on the master to one of the shards, it then 
> triggers a replication and replicates OK. I have a feeling that these 
> SnapPull failures appear later on but right now I don't have enough to form a 
> pattern.
> Here's replication.properties on one of the failed slave instances.
> {code}
> cat data/replication.properties 
> #Replication details
> #Wed Sep 23 19:35:30 PDT 2009
> replicationFailedAtList=1253759730020,1253759700018,1253759670019,1253759640018,1253759610018,1253759580022,1253759550019,1253759520016,1253759490026,1253759460016
> previousCycleTimeInSeconds=0
> timesFailed=113
> indexReplicatedAtList=1253759730020,1253759700018,1253759670019,1253759640018,1253759610018,1253759580022,1253759550019,1253759520016,1253759490026,1253759460016
> indexReplicatedAt=1253759730020
> replicationFailedAt=1253759730020
> lastCycleBytesDownloaded=0
> timesIndexReplicated=113
> {code}
> and another
> {code}
> cat data/replication.properties 
> #Replication details
> #Wed Sep 23 18:42:01 PDT 2009
> replicationFailedAtList=1253756490034,1253756460169
> previousCycleTimeInSeconds=1
> timesFailed=2
> indexReplicatedAtList=1253756521284,1253756490034,1253756460169
> indexReplicatedAt=1253756521284
> replicationFailedAt=1253756490034
> lastCycleBytesDownloaded=22932293
> timesIndexReplicated=3
> {code}
> Some relevant configs:
> In solrconfig.xml:
> {code}
> 
>   
> 
> ${enable.master:false}
> optimize
> optimize
> 00:00:20
> 
> 
> ${enable.slave:false}
> 
> ${master.url}
> 
> 00:00:30
> 
>   
> {code}
> The slave then has this in solrcore.properties:
> {code}
> enable.slave=true
> master.url=URLOFMASTER/replication
> {code}
> and the master has
> {code}
> enable.master=true
> {code}
> I'd be glad to provide more details but I'm not sure what else I can do.  
> SOLR-926 may be relevant.
> Thanks.

-- 
This message is automatically generated by JIRA.
-
You can reply to this em

print junit test name

[Yonik Seeley]

Right now, if I see something funny (like an exception that doesn't
cause a test failure) in a big junit test report, it's hard to tell
what test it was in - the output for each test is simply catenated,
with no separator.

Is there a way to get junit to print this info, or do we need to do
subclass TestCase, and do it ourselves?

-Yonik
http://www.lucidimagination.com

[jira] Commented: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-1221:
---

Grrr ... darn it. Its at the Lucene level. NumericQuery doesn't set the Term 
for getTerm(), so its not supported by the Span Highlighter. Grrr. Not sure 
what to do at the moment ...

> Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by 
> default
> --
>
> Key: SOLR-1221
> URL: https://issues.apache.org/jira/browse/SOLR-1221
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch
>
>
> To improve the out of the box experience of Solr 1.4, I really think we 
> should make this change. You will still be able to turn both off.
> Comments?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default

[Mark Miller (JIRA)]

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

Mark Miller reopened SOLR-1221:
---


There is a bug to take care of, and a missing piece that Koji pointed out.

> Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by 
> default
> --
>
> Key: SOLR-1221
> URL: https://issues.apache.org/jira/browse/SOLR-1221
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch
>
>
> To improve the out of the box experience of Solr 1.4, I really think we 
> should make this change. You will still be able to turn both off.
> Comments?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: svn commit: r819314 - in /lucene/solr/trunk: CHANGES.txt src/java/org/apache/solr/highlight/DefaultSolrHighlighter.java src/test/org/apache/solr/highlight/HighlighterTest.java

[Mark Miller]

Turned up a bug to boot ...

Mark Miller wrote:
> Thank you Koji!
>
> Indeed - those need to default true now.
>
> Nice eyes, and thanks for looking over!
>
> Koji Sekiguchi wrote:
>   
>>> Also make both options default to true.
>>>   
>> If so, isn't this line (from HighlightComponent) needed to be
>> also true by default?
>>
>>boolean rewrite =
>> !(Boolean.valueOf(req.getParams().get(HighlightParams.USE_PHRASE_HIGHLIGHTER))
>> &&
>> Boolean.valueOf(req.getParams().get(HighlightParams.HIGHLIGHT_MULTI_TERM)));
>>
>>
>> I think MultiTermQueries are converted to ConstantScoreQuery
>> by rewrite?
>>
>> Koji
>>
>>
>> markrmil...@apache.org wrote:
>> 
>>> Author: markrmiller
>>> Date: Sun Sep 27 13:58:30 2009
>>> New Revision: 819314
>>>
>>> URL: http://svn.apache.org/viewvc?rev=819314&view=rev
>>> Log:
>>> SOLR-1221: Change Solr Highlighting to use the SpanScorer with
>>> MultiTerm expansion by default
>>>
>>> Modified:
>>> lucene/solr/trunk/CHANGES.txt
>>>
>>> lucene/solr/trunk/src/java/org/apache/solr/highlight/DefaultSolrHighlighter.java
>>>
>>>
>>> lucene/solr/trunk/src/test/org/apache/solr/highlight/HighlighterTest.java
>>>
>>>
>>> Modified: lucene/solr/trunk/CHANGES.txt
>>> URL:
>>> http://svn.apache.org/viewvc/lucene/solr/trunk/CHANGES.txt?rev=819314&r1=819313&r2=819314&view=diff
>>>
>>> ==
>>>
>>> --- lucene/solr/trunk/CHANGES.txt (original)
>>> +++ lucene/solr/trunk/CHANGES.txt Sun Sep 27 13:58:30 2009
>>> @@ -503,8 +503,8 @@
>>>  45. SOLR-1078: Fixes to WordDelimiterFilter to avoid splitting or
>>> dropping
>>>  international non-letter characters such as non spacing marks.
>>> (yonik)
>>>  -46. SOLR-825: Enables highlighting for
>>> range/wildcard/fuzzy/prefix queries if using
>>> hl.usePhraseHighlighter=true
>>> -and hl.highlightMultiTerm=true.  (Mark Miller)
>>> +46. SOLR-825, SOLR-1221: Enables highlighting for
>>> range/wildcard/fuzzy/prefix queries if using
>>> hl.usePhraseHighlighter=true
>>> +and hl.highlightMultiTerm=true. Also make both options default
>>> to true. (Mark Miller)
>>>  
>>>  47. SOLR-1174: Fix Logging admin form submit url for multicore.
>>> (Jacob Singh via shalin)
>>>  
>>>
>>> Modified:
>>> lucene/solr/trunk/src/java/org/apache/solr/highlight/DefaultSolrHighlighter.java
>>>
>>> URL:
>>> http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/highlight/DefaultSolrHighlighter.java?rev=819314&r1=819313&r2=819314&view=diff
>>>
>>> ==
>>>
>>> ---
>>> lucene/solr/trunk/src/java/org/apache/solr/highlight/DefaultSolrHighlighter.java
>>> (original)
>>> +++
>>> lucene/solr/trunk/src/java/org/apache/solr/highlight/DefaultSolrHighlighter.java
>>> Sun Sep 27 13:58:30 2009
>>> @@ -144,7 +144,7 @@
>>> */
>>>private QueryScorer getSpanQueryScorer(Query query, String
>>> fieldName, TokenStream tokenStream, SolrQueryRequest request) throws
>>> IOException {
>>>  boolean reqFieldMatch =
>>> request.getParams().getFieldBool(fieldName,
>>> HighlightParams.FIELD_MATCH, false);
>>> -Boolean highlightMultiTerm =
>>> request.getParams().getBool(HighlightParams.HIGHLIGHT_MULTI_TERM);
>>> +Boolean highlightMultiTerm =
>>> request.getParams().getBool(HighlightParams.HIGHLIGHT_MULTI_TERM, true);
>>>  if(highlightMultiTerm == null) {
>>>highlightMultiTerm = false;
>>>  }
>>> @@ -306,8 +306,9 @@
>>>  }
>>>Highlighter highlighter;
>>> -if
>>> (Boolean.valueOf(req.getParams().get(HighlightParams.USE_PHRASE_HIGHLIGHTER)))
>>> {
>>> -  // wrap CachingTokenFilter around TokenStream for reuse
>>> +if
>>> (Boolean.valueOf(req.getParams().get(HighlightParams.USE_PHRASE_HIGHLIGHTER,
>>> "true"))) {
>>> +  // TODO: this is not always necessary - eventually we
>>> would like to avoid this wrap
>>> +  //   when it is not needed.
>>>tstream = new CachingTokenFilter(tstream);
>>>   // get highlighter
>>>
>>> Modified:
>>> lucene/solr/trunk/src/test/org/apache/solr/highlight/HighlighterTest.java
>>>
>>> URL:
>>> http://svn.apache.org/viewvc/lucene/solr/trunk/src/test/org/apache/solr/highlight/HighlighterTest.java?rev=819314&r1=819313&r2=819314&view=diff
>>>
>>> ==
>>>
>>> ---
>>> lucene/solr/trunk/src/test/org/apache/solr/highlight/HighlighterTest.java
>>> (original)
>>> +++
>>> lucene/solr/trunk/src/test/org/apache/solr/highlight/HighlighterTest.java
>>> Sun Sep 27 13:58:30 2009
>>> @@ -585,6 +585,7 @@
>>>  args.put("hl.fl", "t_text");
>>>  args.put("hl.fragsize", "40");
>>>  args.put("hl.snippets", "10");
>>> +args.put("hl.usePhraseHighlighter", "false");
>>>  
>>>  TestHarness.LocalRequestFactory sumLRF = h.getRequestF

Re: svn commit: r819314 - in /lucene/solr/trunk: CHANGES.txt src/java/org/apache/solr/highlight/DefaultSolrHighlighter.java src/test/org/apache/solr/highlight/HighlighterTest.java

[Mark Miller]

Thank you Koji!

Indeed - those need to default true now.

Nice eyes, and thanks for looking over!

Koji Sekiguchi wrote:
> > Also make both options default to true.
>
> If so, isn't this line (from HighlightComponent) needed to be
> also true by default?
>
>boolean rewrite =
> !(Boolean.valueOf(req.getParams().get(HighlightParams.USE_PHRASE_HIGHLIGHTER))
> &&
> Boolean.valueOf(req.getParams().get(HighlightParams.HIGHLIGHT_MULTI_TERM)));
>
>
> I think MultiTermQueries are converted to ConstantScoreQuery
> by rewrite?
>
> Koji
>
>
> markrmil...@apache.org wrote:
>> Author: markrmiller
>> Date: Sun Sep 27 13:58:30 2009
>> New Revision: 819314
>>
>> URL: http://svn.apache.org/viewvc?rev=819314&view=rev
>> Log:
>> SOLR-1221: Change Solr Highlighting to use the SpanScorer with
>> MultiTerm expansion by default
>>
>> Modified:
>> lucene/solr/trunk/CHANGES.txt
>>
>> lucene/solr/trunk/src/java/org/apache/solr/highlight/DefaultSolrHighlighter.java
>>
>>
>> lucene/solr/trunk/src/test/org/apache/solr/highlight/HighlighterTest.java
>>
>>
>> Modified: lucene/solr/trunk/CHANGES.txt
>> URL:
>> http://svn.apache.org/viewvc/lucene/solr/trunk/CHANGES.txt?rev=819314&r1=819313&r2=819314&view=diff
>>
>> ==
>>
>> --- lucene/solr/trunk/CHANGES.txt (original)
>> +++ lucene/solr/trunk/CHANGES.txt Sun Sep 27 13:58:30 2009
>> @@ -503,8 +503,8 @@
>>  45. SOLR-1078: Fixes to WordDelimiterFilter to avoid splitting or
>> dropping
>>  international non-letter characters such as non spacing marks.
>> (yonik)
>>  -46. SOLR-825: Enables highlighting for
>> range/wildcard/fuzzy/prefix queries if using
>> hl.usePhraseHighlighter=true
>> -and hl.highlightMultiTerm=true.  (Mark Miller)
>> +46. SOLR-825, SOLR-1221: Enables highlighting for
>> range/wildcard/fuzzy/prefix queries if using
>> hl.usePhraseHighlighter=true
>> +and hl.highlightMultiTerm=true. Also make both options default
>> to true. (Mark Miller)
>>  
>>  47. SOLR-1174: Fix Logging admin form submit url for multicore.
>> (Jacob Singh via shalin)
>>  
>>
>> Modified:
>> lucene/solr/trunk/src/java/org/apache/solr/highlight/DefaultSolrHighlighter.java
>>
>> URL:
>> http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/highlight/DefaultSolrHighlighter.java?rev=819314&r1=819313&r2=819314&view=diff
>>
>> ==
>>
>> ---
>> lucene/solr/trunk/src/java/org/apache/solr/highlight/DefaultSolrHighlighter.java
>> (original)
>> +++
>> lucene/solr/trunk/src/java/org/apache/solr/highlight/DefaultSolrHighlighter.java
>> Sun Sep 27 13:58:30 2009
>> @@ -144,7 +144,7 @@
>> */
>>private QueryScorer getSpanQueryScorer(Query query, String
>> fieldName, TokenStream tokenStream, SolrQueryRequest request) throws
>> IOException {
>>  boolean reqFieldMatch =
>> request.getParams().getFieldBool(fieldName,
>> HighlightParams.FIELD_MATCH, false);
>> -Boolean highlightMultiTerm =
>> request.getParams().getBool(HighlightParams.HIGHLIGHT_MULTI_TERM);
>> +Boolean highlightMultiTerm =
>> request.getParams().getBool(HighlightParams.HIGHLIGHT_MULTI_TERM, true);
>>  if(highlightMultiTerm == null) {
>>highlightMultiTerm = false;
>>  }
>> @@ -306,8 +306,9 @@
>>  }
>>Highlighter highlighter;
>> -if
>> (Boolean.valueOf(req.getParams().get(HighlightParams.USE_PHRASE_HIGHLIGHTER)))
>> {
>> -  // wrap CachingTokenFilter around TokenStream for reuse
>> +if
>> (Boolean.valueOf(req.getParams().get(HighlightParams.USE_PHRASE_HIGHLIGHTER,
>> "true"))) {
>> +  // TODO: this is not always necessary - eventually we
>> would like to avoid this wrap
>> +  //   when it is not needed.
>>tstream = new CachingTokenFilter(tstream);
>>   // get highlighter
>>
>> Modified:
>> lucene/solr/trunk/src/test/org/apache/solr/highlight/HighlighterTest.java
>>
>> URL:
>> http://svn.apache.org/viewvc/lucene/solr/trunk/src/test/org/apache/solr/highlight/HighlighterTest.java?rev=819314&r1=819313&r2=819314&view=diff
>>
>> ==
>>
>> ---
>> lucene/solr/trunk/src/test/org/apache/solr/highlight/HighlighterTest.java
>> (original)
>> +++
>> lucene/solr/trunk/src/test/org/apache/solr/highlight/HighlighterTest.java
>> Sun Sep 27 13:58:30 2009
>> @@ -585,6 +585,7 @@
>>  args.put("hl.fl", "t_text");
>>  args.put("hl.fragsize", "40");
>>  args.put("hl.snippets", "10");
>> +args.put("hl.usePhraseHighlighter", "false");
>>  
>>  TestHarness.LocalRequestFactory sumLRF = h.getRequestFactory(
>>"standard", 0, 200, args);
>>
>>
>>
>>   
>


-- 
- Mark

http://www.lucidimagination.com

Re: svn commit: r819314 - in /lucene/solr/trunk: CHANGES.txt src/java/org/apache/solr/highlight/DefaultSolrHighlighter.java src/test/org/apache/solr/highlight/HighlighterTest.java

[Koji Sekiguchi]

> Also make both options default to true.

If so, isn't this line (from HighlightComponent) needed to be
also true by default?

   boolean rewrite = 
!(Boolean.valueOf(req.getParams().get(HighlightParams.USE_PHRASE_HIGHLIGHTER)) 
&& 
Boolean.valueOf(req.getParams().get(HighlightParams.HIGHLIGHT_MULTI_TERM)));


I think MultiTermQueries are converted to ConstantScoreQuery
by rewrite?

Koji


markrmil...@apache.org wrote:

Author: markrmiller
Date: Sun Sep 27 13:58:30 2009
New Revision: 819314

URL: http://svn.apache.org/viewvc?rev=819314&view=rev
Log:
SOLR-1221: Change Solr Highlighting to use the SpanScorer with MultiTerm 
expansion by default

Modified:
lucene/solr/trunk/CHANGES.txt

lucene/solr/trunk/src/java/org/apache/solr/highlight/DefaultSolrHighlighter.java
lucene/solr/trunk/src/test/org/apache/solr/highlight/HighlighterTest.java

Modified: lucene/solr/trunk/CHANGES.txt
URL: 
http://svn.apache.org/viewvc/lucene/solr/trunk/CHANGES.txt?rev=819314&r1=819313&r2=819314&view=diff
==
--- lucene/solr/trunk/CHANGES.txt (original)
+++ lucene/solr/trunk/CHANGES.txt Sun Sep 27 13:58:30 2009
@@ -503,8 +503,8 @@
 45. SOLR-1078: Fixes to WordDelimiterFilter to avoid splitting or dropping
 international non-letter characters such as non spacing marks. (yonik)
 
-46. SOLR-825: Enables highlighting for range/wildcard/fuzzy/prefix queries if using hl.usePhraseHighlighter=true

-and hl.highlightMultiTerm=true.  (Mark Miller)
+46. SOLR-825, SOLR-1221: Enables highlighting for range/wildcard/fuzzy/prefix 
queries if using hl.usePhraseHighlighter=true
+and hl.highlightMultiTerm=true. Also make both options default to true. 
(Mark Miller)
 
 47. SOLR-1174: Fix Logging admin form submit url for multicore. (Jacob Singh via shalin)
 


Modified: 
lucene/solr/trunk/src/java/org/apache/solr/highlight/DefaultSolrHighlighter.java
URL: 
http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/highlight/DefaultSolrHighlighter.java?rev=819314&r1=819313&r2=819314&view=diff
==
--- 
lucene/solr/trunk/src/java/org/apache/solr/highlight/DefaultSolrHighlighter.java
 (original)
+++ 
lucene/solr/trunk/src/java/org/apache/solr/highlight/DefaultSolrHighlighter.java
 Sun Sep 27 13:58:30 2009
@@ -144,7 +144,7 @@
*/
   private QueryScorer getSpanQueryScorer(Query query, String fieldName, 
TokenStream tokenStream, SolrQueryRequest request) throws IOException {
 boolean reqFieldMatch = request.getParams().getFieldBool(fieldName, 
HighlightParams.FIELD_MATCH, false);
-Boolean highlightMultiTerm = 
request.getParams().getBool(HighlightParams.HIGHLIGHT_MULTI_TERM);
+Boolean highlightMultiTerm = 
request.getParams().getBool(HighlightParams.HIGHLIGHT_MULTI_TERM, true);
 if(highlightMultiTerm == null) {
   highlightMultiTerm = false;
 }
@@ -306,8 +306,9 @@
 }
  
 Highlighter highlighter;

-if 
(Boolean.valueOf(req.getParams().get(HighlightParams.USE_PHRASE_HIGHLIGHTER))) {
-  // wrap CachingTokenFilter around TokenStream for reuse
+if 
(Boolean.valueOf(req.getParams().get(HighlightParams.USE_PHRASE_HIGHLIGHTER, 
"true"))) {
+  // TODO: this is not always necessary - eventually we would like 
to avoid this wrap
+  //   when it is not needed.
   tstream = new CachingTokenFilter(tstream);
   
   // get highlighter


Modified: 
lucene/solr/trunk/src/test/org/apache/solr/highlight/HighlighterTest.java
URL: 
http://svn.apache.org/viewvc/lucene/solr/trunk/src/test/org/apache/solr/highlight/HighlighterTest.java?rev=819314&r1=819313&r2=819314&view=diff
==
--- lucene/solr/trunk/src/test/org/apache/solr/highlight/HighlighterTest.java 
(original)
+++ lucene/solr/trunk/src/test/org/apache/solr/highlight/HighlighterTest.java 
Sun Sep 27 13:58:30 2009
@@ -585,6 +585,7 @@
 args.put("hl.fl", "t_text");
 args.put("hl.fragsize", "40");
 args.put("hl.snippets", "10");
+args.put("hl.usePhraseHighlighter", "false");
 
 TestHarness.LocalRequestFactory sumLRF = h.getRequestFactory(

   "standard", 0, 200, args);



  

[jira] Updated: (SOLR-1314) Upgrade Carrot2 to version 3.1.0

[Stanislaw Osinski (JIRA)]

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

Stanislaw Osinski updated SOLR-1314:


Attachment: SOLR-1314.patch

Hi Grant,

I've built Carrot2 3.1.0 binaries and tested them with Solr trunk. Attached is 
a patch that upgrades the libs to Carrot2 3.1.0 and fixes one unit test.

S.

> Upgrade Carrot2 to version 3.1.0
> 
>
> Key: SOLR-1314
> URL: https://issues.apache.org/jira/browse/SOLR-1314
> Project: Solr
>  Issue Type: Task
>Reporter: Stanislaw Osinski
>Assignee: Grant Ingersoll
> Fix For: 1.4
>
> Attachments: SOLR-1314.patch
>
>
> As soon as Lucene 2.9 is releases, Carrot2 3.1.0 will come out with bug fixes 
> in clustering algorithms and improved clustering in Chinese. The upgrade 
> should be a matter of upgrading {{carrot2-mini.jar}} and 
> {{google-collections.jar}}.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default

[Mark Miller (JIRA)]

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

Mark Miller resolved SOLR-1221.
---

Resolution: Fixed

> Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by 
> default
> --
>
> Key: SOLR-1221
> URL: https://issues.apache.org/jira/browse/SOLR-1221
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch
>
>
> To improve the out of the box experience of Solr 1.4, I really think we 
> should make this change. You will still be able to turn both off.
> Comments?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (SOLR-1466) Fix File descriptor leak in SnapPuller

[Mark Miller (JIRA)]

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

Mark Miller resolved SOLR-1466.
---

Resolution: Fixed
  Assignee: Mark Miller

Thanks for the review!

> Fix File descriptor leak in SnapPuller
> --
>
> Key: SOLR-1466
> URL: https://issues.apache.org/jira/browse/SOLR-1466
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1466.patch, SOLR-1466.patch
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Hudson build is back to normal: Solr-trunk #937

[Apache Hudson Server]

See 

Solr nightly build failure

[solr-dev]

init-forrest-entities:
[mkdir] Created dir: /tmp/apache-solr-nightly/build
[mkdir] Created dir: /tmp/apache-solr-nightly/build/web

compile-solrj:
[mkdir] Created dir: /tmp/apache-solr-nightly/build/solrj
[javac] Compiling 86 source files to /tmp/apache-solr-nightly/build/solrj
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.

compile:
[mkdir] Created dir: /tmp/apache-solr-nightly/build/solr
[javac] Compiling 388 source files to /tmp/apache-solr-nightly/build/solr
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.

compileTests:
[mkdir] Created dir: /tmp/apache-solr-nightly/build/tests
[javac] Compiling 176 source files to /tmp/apache-solr-nightly/build/tests
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.

solr-cell-example:

init:
[mkdir] Created dir: 
/tmp/apache-solr-nightly/contrib/extraction/build/classes
[mkdir] Created dir: /tmp/apache-solr-nightly/build/docs/api

init-forrest-entities:

compile-solrj:

compile:
[javac] Compiling 1 source file to /tmp/apache-solr-nightly/build/solr
[javac] Note: 
/tmp/apache-solr-nightly/src/java/org/apache/solr/search/DocSetHitCollector.java
 uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.

make-manifest:
[mkdir] Created dir: /tmp/apache-solr-nightly/build/META-INF

compile:
[javac] Compiling 6 source files to 
/tmp/apache-solr-nightly/contrib/extraction/build/classes
[javac] Note: 
/tmp/apache-solr-nightly/contrib/extraction/src/main/java/org/apache/solr/handler/extraction/ExtractingDocumentLoader.java
 uses unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.

build:
  [jar] Building jar: 
/tmp/apache-solr-nightly/contrib/extraction/build/apache-solr-cell-nightly.jar

example:
 [copy] Copying 1 file to /tmp/apache-solr-nightly/example/solr/lib
 [copy] Copying 26 files to /tmp/apache-solr-nightly/example/solr/lib

junit:
[mkdir] Created dir: /tmp/apache-solr-nightly/build/test-results
[junit] Running org.apache.solr.BasicFunctionalityTest
[junit] Tests run: 20, Failures: 0, Errors: 0, Time elapsed: 46.826 sec
[junit] Running org.apache.solr.ConvertedLegacyTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 53.261 sec
[junit] Running org.apache.solr.DisMaxRequestHandlerTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 14.679 sec
[junit] Running org.apache.solr.EchoParamsTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 8.962 sec
[junit] Running org.apache.solr.MinimalSchemaTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 9.656 sec
[junit] Running org.apache.solr.OutputWriterTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 7.643 sec
[junit] Running org.apache.solr.SampleTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.43 sec
[junit] Running org.apache.solr.SolrInfoMBeanTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.33 sec
[junit] Running org.apache.solr.TestDistributedSearch
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 115.255 sec
[junit] Running org.apache.solr.TestPluginEnable
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 5.027 sec
[junit] Running org.apache.solr.TestSolrCoreProperties
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 10.954 sec
[junit] Running org.apache.solr.TestTrie
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 27.079 sec
[junit] Running org.apache.solr.analysis.CommonGramsFilterFactoryTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 6.601 sec
[junit] Running org.apache.solr.analysis.CommonGramsFilterTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.486 sec
[junit] Running org.apache.solr.analysis.CommonGramsQueryFilterFactoryTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 5.855 sec
[junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterFactoryTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.44 sec
[junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterTest
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 1.018 sec
[junit] Running org.apach