[jira] Issue Comment Edited: (SOLR-2411) Build target prepare-release should produce a solr/dist/ directory that only has distribution files in it

[Steven Rowe (JIRA)]

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

Steven Rowe edited comment on SOLR-2411 at 3/8/11 5:51 AM:
---

**edit**: This patch is against branch_3x.

Patch implementing these changes.

All intermediate .jars (and the .war) are placed in {{solr/build/dist-work/}}.

I compared contents of the source tarball, the binary tarball, and the {{.war}} 
file before and after applying this patch.  In all three cases, the same files 
are present in both versions.

This patch also drops tar'ing both of {{dist/maven/}} as 
{{dist/solr-maven.tar}} and of {{dist/*}} -- except the {{.war}} -- as 
{{dist/solr.tar}}.

  was (Author: steve_rowe):
Patch implementing these changes.

All intermediate .jars (and the .war) are placed in {{solr/build/dist-work/}}.

I compared contents of the source tarball, the binary tarball, and the {{.war}} 
file before and after applying this patch.  In all three cases, the same files 
are present in both versions.

This patch also drops tar'ing both of {{dist/maven/}} as 
{{dist/solr-maven.tar}} and of {{dist/*}} -- except the {{.war}} -- as 
{{dist/solr.tar}}.
  
> Build target prepare-release should produce a solr/dist/ directory that only 
> has distribution files in it
> -
>
> Key: SOLR-2411
> URL: https://issues.apache.org/jira/browse/SOLR-2411
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Steven Rowe
>Priority: Minor
> Attachments: SOLR-2411.patch
>
>
> Build targets dist, dist-*, create-package, package, package-src, etc. use 
> {{dist/}} as a landing spot for intermediate .jar files which will not be 
> individually shipped.
> These targets should instead use {{solr/build/}} to hold these intermediate 
> .jars.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Updated: (SOLR-2411) Build target prepare-release should produce a solr/dist/ directory that only has distribution files in it

[Steven Rowe (JIRA)]

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

Steven Rowe updated SOLR-2411:
--

Attachment: SOLR-2411.patch

Patch implementing these changes.

All intermediate .jars (and the .war) are placed in {{solr/build/dist-work/}}.

I compared contents of the source tarball, the binary tarball, and the {{.war}} 
file before and after applying this patch.  In all three cases, the same files 
are present in both versions.

This patch also drops tar'ing both of {{dist/maven/}} as 
{{dist/solr-maven.tar}} and of {{dist/*}} -- except the {{.war}} -- as 
{{dist/solr.tar}}.

> Build target prepare-release should produce a solr/dist/ directory that only 
> has distribution files in it
> -
>
> Key: SOLR-2411
> URL: https://issues.apache.org/jira/browse/SOLR-2411
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Steven Rowe
>Priority: Minor
> Attachments: SOLR-2411.patch
>
>
> Build targets dist, dist-*, create-package, package, package-src, etc. use 
> {{dist/}} as a landing spot for intermediate .jar files which will not be 
> individually shipped.
> These targets should instead use {{solr/build/}} to hold these intermediate 
> .jars.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Created: (SOLR-2411) Build target prepare-release should produce a solr/dist/ directory that only has distribution files in it

[Steven Rowe (JIRA)]

Build target prepare-release should produce a solr/dist/ directory that only 
has distribution files in it
-

 Key: SOLR-2411
 URL: https://issues.apache.org/jira/browse/SOLR-2411
 Project: Solr
  Issue Type: Improvement
  Components: Build
Reporter: Steven Rowe
Priority: Minor


Build targets dist, dist-*, create-package, package, package-src, etc. use 
{{dist/}} as a landing spot for intermediate .jar files which will not be 
individually shipped.

These targets should instead use {{solr/build/}} to hold these intermediate 
.jars.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[HUDSON] Lucene-Solr-tests-only-3.x - Build # 5694 - Failure

[Apache Hudson Server]

Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/5694/

No tests ran.

Build Log (for compile errors):
[...truncated 37 lines...]



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

[HUDSON] Lucene-trunk - Build # 1488 - Failure

[Apache Hudson Server]

Build: https://hudson.apache.org/hudson/job/Lucene-trunk/1488/

No tests ran.

Build Log (for compile errors):
[...truncated 7928 lines...]



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

[jira] Updated: (SOLR-2410) ConcurrentLRUCache can throw class cast exception

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-2410:
---

Attachment: SOLR-2410.patch

Here's the patch with a test added that normally manages to trip the exception.

> ConcurrentLRUCache can throw class cast exception
> -
>
> Key: SOLR-2410
> URL: https://issues.apache.org/jira/browse/SOLR-2410
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Yonik Seeley
> Fix For: 4.0
>
> Attachments: SOLR-2410.patch, SOLR-2410.patch
>
>
> ConcurrentLRUCache throws a class cast exception.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Updated: (LUCENE-2953) PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"

[Hoss Man (JIRA)]

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

Hoss Man updated LUCENE-2953:
-

Attachment: LUCENE-2953.patch

patch to TestPriorityQueue demonstrating bug

> PriorityQueue is inheriently broken if subclass attempts to use "heap" 
> w/generic T bound to anything other then "Object"
> 
>
> Key: LUCENE-2953
> URL: https://issues.apache.org/jira/browse/LUCENE-2953
> Project: Lucene - Java
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: LUCENE-2953.patch
>
>
> as discovered in SOLR-2410 the fact that the protected "heap" variable in 
> PriorityQueue is initialized using an Object[] makes it impossible for 
> subclasses of PriorityQueue to exist and access the "heap" array unless they 
> bind the generic to Object.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Created: (LUCENE-2953) PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"

[Hoss Man (JIRA)]

PriorityQueue is inheriently broken if subclass attempts to use "heap" 
w/generic T bound to anything other then "Object"


 Key: LUCENE-2953
 URL: https://issues.apache.org/jira/browse/LUCENE-2953
 Project: Lucene - Java
  Issue Type: Bug
Reporter: Hoss Man


as discovered in SOLR-2410 the fact that the protected "heap" variable in 
PriorityQueue is initialized using an Object[] makes it impossible for 
subclasses of PriorityQueue to exist and access the "heap" array unless they 
bind the generic to Object.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5709 - Failure

[Apache Hudson Server]

Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5709/

1 tests failed.
REGRESSION:  org.apache.lucene.index.TestIndexWriter.testIndexingThenDeleting

Error Message:
flush happened too quickly during deleting count=1155

Stack Trace:
junit.framework.AssertionFailedError: flush happened too quickly during 
deleting count=1155
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1213)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1145)
at 
org.apache.lucene.index.TestIndexWriter.testIndexingThenDeleting(TestIndexWriter.java:2579)




Build Log (for compile errors):
[...truncated 3082 lines...]



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

[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5707 - Failure

[Apache Hudson Server]

Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5707/

1 tests failed.
REGRESSION:  org.apache.solr.client.solrj.TestLBHttpSolrServer.testSimple

Error Message:
expected:<3> but was:<2>

Stack Trace:
junit.framework.AssertionFailedError: expected:<3> but was:<2>
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1213)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1145)
at 
org.apache.solr.client.solrj.TestLBHttpSolrServer.testSimple(TestLBHttpSolrServer.java:127)




Build Log (for compile errors):
[...truncated 8489 lines...]



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

[jira] Updated: (SOLR-2410) ConcurrentLRUCache can throw class cast exception

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-2410:
---

Attachment: SOLR-2410.patch

Here's a patch that reverts back to a normal PQ (non-generified).  This 
minimizes the chance of another generics related bug here since the code is so 
hard to hit.

> ConcurrentLRUCache can throw class cast exception
> -
>
> Key: SOLR-2410
> URL: https://issues.apache.org/jira/browse/SOLR-2410
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Yonik Seeley
> Fix For: 4.0
>
> Attachments: SOLR-2410.patch
>
>
> ConcurrentLRUCache throws a class cast exception.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Commented: (LUCENE-2948) Make var gap terms index a partial prefix trie

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-2948:


Here's a graphical rendition of the above table:

!Results.png!

It's sorted in the same order (leftmost = biggest slowdown), and the error bars 
show std dev.

> Make var gap terms index a partial prefix trie
> --
>
> Key: LUCENE-2948
> URL: https://issues.apache.org/jira/browse/LUCENE-2948
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: Index
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 4.0
>
> Attachments: LUCENE-2948.patch, LUCENE-2948.patch, LUCENE-2948.patch, 
> LUCENE-2948_automaton.patch, Results.png
>
>
> Var gap stores (in an FST) the indexed terms (every 32nd term, by
> default), minus their non-distinguishing suffixes.
> However, often times the resulting FST is "close" to a prefix trie in
> some portion of the terms space.
> By allowing some nodes of the FST to store all outgoing edges,
> including ones that do not lead to an indexed term, and by recording
> that this node is then "authoritative" as to what terms exist in the
> terms dict from that prefix, we can get some important benefits:
>   * It becomes possible to know that a certain term prefix cannot
> exist in the terms index, which means we can save a disk seek in
> some cases (like PK lookup, docFreq, etc.)
>   * We can query for the next possible prefix in the index, allowing
> some MTQs (eg FuzzyQuery) to save disk seeks.
> Basically, the terms index is able to answer questions that previously
> required seeking/scanning in the terms dict file.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Updated: (LUCENE-2948) Make var gap terms index a partial prefix trie

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-2948:
---

Attachment: Results.png

Graph showing perf results.

> Make var gap terms index a partial prefix trie
> --
>
> Key: LUCENE-2948
> URL: https://issues.apache.org/jira/browse/LUCENE-2948
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: Index
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 4.0
>
> Attachments: LUCENE-2948.patch, LUCENE-2948.patch, LUCENE-2948.patch, 
> LUCENE-2948_automaton.patch, Results.png
>
>
> Var gap stores (in an FST) the indexed terms (every 32nd term, by
> default), minus their non-distinguishing suffixes.
> However, often times the resulting FST is "close" to a prefix trie in
> some portion of the terms space.
> By allowing some nodes of the FST to store all outgoing edges,
> including ones that do not lead to an indexed term, and by recording
> that this node is then "authoritative" as to what terms exist in the
> terms dict from that prefix, we can get some important benefits:
>   * It becomes possible to know that a certain term prefix cannot
> exist in the terms index, which means we can save a disk seek in
> some cases (like PK lookup, docFreq, etc.)
>   * We can query for the next possible prefix in the index, allowing
> some MTQs (eg FuzzyQuery) to save disk seeks.
> Basically, the terms index is able to answer questions that previously
> required seeking/scanning in the terms dict file.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Commented: (LUCENE-2948) Make var gap terms index a partial prefix trie

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-2948:


I ran perf test w/ latest patch, and also fixed luceneutil to track stddev of 
the measures:
 
||Task||QPS base||StdDev base||QPS bushy||StdDev bushy||Pct diff
|Fuzzy1|32.41|1.29|21.68|0.65|{color:red}37%{color}-{color:red}28%{color}|
|Fuzzy2|21.59|0.79|14.54|0.41|{color:red}36%{color}-{color:red}28%{color}|
|Respell|29.52|0.95|28.70|1.07|{color:red}9%{color}-{color:green}4%{color}|
|IntNRQ|9.16|1.10|9.03|1.04|{color:red}22%{color}-{color:green}24%{color}|
|Wildcard|53.88|3.10|53.25|2.96|{color:red}11%{color}-{color:green}10%{color}|
|Prefix3|31.75|2.73|31.41|2.47|{color:red}16%{color}-{color:green}16%{color}|
|SloppyPhrase|6.28|0.26|6.24|0.31|{color:red}9%{color}-{color:green}8%{color}|
|AndHighHigh|10.81|0.40|10.80|0.36|{color:red}6%{color}-{color:green}7%{color}|
|Phrase|6.79|0.42|6.80|0.41|{color:red}11%{color}-{color:green}13%{color}|
|AndHighMed|47.27|1.37|47.34|1.10|{color:red}4%{color}-{color:green}5%{color}|
|SpanNear|7.72|0.43|7.78|0.34|{color:red}8%{color}-{color:green}11%{color}|
|Term|34.21|3.12|35.36|3.04|{color:red}13%{color}-{color:green}23%{color}|
|OrHighHigh|12.16|1.18|12.60|1.15|{color:red}14%{color}-{color:green}25%{color}|
|OrHighMed|15.20|1.44|15.76|1.43|{color:red}13%{color}-{color:green}24%{color}|
|PKLookup|39.59|1.08|56.36|2.07|{color:green}33%{color}-{color:green}51%{color}|

The range on the %tg gain/loss takes the best/worst ends of +/1 one stddev.

Unfortunately, the patch slows down fuzzy queries, I think because the cost of 
checking for the next possible prefix exceeds any savings.  Though, this is a 
hot test; it's possible we'd see gains w/ a cold test since we are doing less 
seeking.

But for PK lookup the gains are sizable.  But note that this only applies to PK 
values that are "tight", eg sequential IDs, not to GUIDs, and only then on a 
relatively "fresh" index (ie after many updates in randomish order the PKs will 
be randomly distributed and the gains will be gone).

I think for now we should not expose the nextPossiblePrefix (or at least not 
use it from ATE)?


> Make var gap terms index a partial prefix trie
> --
>
> Key: LUCENE-2948
> URL: https://issues.apache.org/jira/browse/LUCENE-2948
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: Index
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 4.0
>
> Attachments: LUCENE-2948.patch, LUCENE-2948.patch, LUCENE-2948.patch, 
> LUCENE-2948_automaton.patch
>
>
> Var gap stores (in an FST) the indexed terms (every 32nd term, by
> default), minus their non-distinguishing suffixes.
> However, often times the resulting FST is "close" to a prefix trie in
> some portion of the terms space.
> By allowing some nodes of the FST to store all outgoing edges,
> including ones that do not lead to an indexed term, and by recording
> that this node is then "authoritative" as to what terms exist in the
> terms dict from that prefix, we can get some important benefits:
>   * It becomes possible to know that a certain term prefix cannot
> exist in the terms index, which means we can save a disk seek in
> some cases (like PK lookup, docFreq, etc.)
>   * We can query for the next possible prefix in the index, allowing
> some MTQs (eg FuzzyQuery) to save disk seeks.
> Basically, the terms index is able to answer questions that previously
> required seeking/scanning in the terms dict file.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Issue Comment Edited: (SOLR-2410) ConcurrentLRUCache can throw class cast exception

[Yonik Seeley (JIRA)]

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

Yonik Seeley edited comment on SOLR-2410 at 3/7/11 11:40 PM:
-

Thanks Dawid!

bq. 2) cast superclass's array to (Object[]) first, then cast to the concrete 
component type. Here:

I tried this, but couldn't get it to work:

{code}

class Example
{
   public static class A {
   @SuppressWarnings("unchecked") // it is here for a reason :)
   public T[] array = (T[]) new Object [1];
   }

   public static void main(String [] args)
   {
   A clazzA = new A();
   System.out.println(((Integer[])((Object[])clazzA.array))[0]);
   }
}
{code}

edit: I got it - you need to access the array as an Object[]

{code}
   System.out.println( (Integer) (((Object[])clazzA.array)[0]));
{code}

  was (Author: ysee...@gmail.com):
Thanks Dawid!

bq. 2) cast superclass's array to (Object[]) first, then cast to the concrete 
component type. Here:

I tried this, but couldn't get it to work:

{code}

class Example
{
   public static class A {
   @SuppressWarnings("unchecked") // it is here for a reason :)
   public T[] array = (T[]) new Object [1];
   }

   public static void main(String [] args)
   {
   A clazzA = new A();
   System.out.println(((Integer[])((Object[])clazzA.array))[0]);
   }
}
{code}
  
> ConcurrentLRUCache can throw class cast exception
> -
>
> Key: SOLR-2410
> URL: https://issues.apache.org/jira/browse/SOLR-2410
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Yonik Seeley
> Fix For: 4.0
>
>
> ConcurrentLRUCache throws a class cast exception.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Commented: (SOLR-2410) ConcurrentLRUCache can throw class cast exception

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-2410:


Thanks Dawid!

bq. 2) cast superclass's array to (Object[]) first, then cast to the concrete 
component type. Here:

I tried this, but couldn't get it to work:

{code}

class Example
{
   public static class A {
   @SuppressWarnings("unchecked") // it is here for a reason :)
   public T[] array = (T[]) new Object [1];
   }

   public static void main(String [] args)
   {
   A clazzA = new A();
   System.out.println(((Integer[])((Object[])clazzA.array))[0]);
   }
}
{code}

> ConcurrentLRUCache can throw class cast exception
> -
>
> Key: SOLR-2410
> URL: https://issues.apache.org/jira/browse/SOLR-2410
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Yonik Seeley
> Fix For: 4.0
>
>
> ConcurrentLRUCache throws a class cast exception.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Commented: (LUCENE-2948) Make var gap terms index a partial prefix trie

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-2948:


Thanks Dawid.

It really is hairy -- I wish we could find a way to simplify it.
Pruning as-you-go, backwards on compiling a now "finished" tail is
just really hard to think about!

bq. I've been thinking about the questions stated in the comments – would it be 
possible to create a "better" pruning/ path keeping method. I honestly don't 
think it is possible if you add terms incrementally to the FST because some of 
the information required to keep or prune states is not available until the 
very end.

Yeah I do too.  We'd need a more global view on how best to "spend"
the allowed budget.

For some cases (dense PKs) it takes very little budget to have a full
prefix trie, and you get good speedups for this case.  But for other
cases (eg, GUIDs as your PKs) it's the polar opposite.

bq. One method I was thinking of was to determine "deep" subtrees of states 
with an approximately equal size (and prune them entirely, or at least part of 
them). These "deep" subtrees (or precalculated frozen states if you want to 
think of them this way) can be computed by sorting reversed input sequences and 
calculating their LCP (longest common prefix) table – then the shared prefixes 
are actually suffixes of the input sequences... You can then linearly scan such 
a reversed table and you'd know immediately how large a given subtree of 
suffixes is. One problem is that this is exact only in state representation of 
the FST (in the edge/LAST representation an input suffix can be integrated with 
a longer suffix, as you recall).

Phew!  So this means for any given suffix you'd know how many terms
end with it?  But how would we then use this info to better pick index
nodes?

bq. Since we're using edge-based representation I don't think the above idea 
helps much. Also, it would require sorting the reversed terms and calculating 
an LCP table... this may be even more costly than what is mentioned in the code 
comment – use two passes, build an FSA first, determine nodes to prune and then 
build the final FST.

Yeah I fear it would be costly...


> Make var gap terms index a partial prefix trie
> --
>
> Key: LUCENE-2948
> URL: https://issues.apache.org/jira/browse/LUCENE-2948
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: Index
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 4.0
>
> Attachments: LUCENE-2948.patch, LUCENE-2948.patch, LUCENE-2948.patch, 
> LUCENE-2948_automaton.patch
>
>
> Var gap stores (in an FST) the indexed terms (every 32nd term, by
> default), minus their non-distinguishing suffixes.
> However, often times the resulting FST is "close" to a prefix trie in
> some portion of the terms space.
> By allowing some nodes of the FST to store all outgoing edges,
> including ones that do not lead to an indexed term, and by recording
> that this node is then "authoritative" as to what terms exist in the
> terms dict from that prefix, we can get some important benefits:
>   * It becomes possible to know that a certain term prefix cannot
> exist in the terms index, which means we can save a disk seek in
> some cases (like PK lookup, docFreq, etc.)
>   * We can query for the next possible prefix in the index, allowing
> some MTQs (eg FuzzyQuery) to save disk seeks.
> Basically, the terms index is able to answer questions that previously
> required seeking/scanning in the terms dict file.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Commented: (SOLR-2410) ConcurrentLRUCache can throw class cast exception

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on SOLR-2410:
---

Yonik, try this and it should be clear why the above doesn't work:

{noformat}

public class Example
{
public static class A {
@SuppressWarnings("unchecked") // it is here for a reason :)
public T[] array = (T[]) new Object [1]; 
}

public static void main(String [] args)
{
A clazzA = new A();
System.out.println(clazzA.array[0]);
}
}
{noformat}

> ConcurrentLRUCache can throw class cast exception
> -
>
> Key: SOLR-2410
> URL: https://issues.apache.org/jira/browse/SOLR-2410
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Yonik Seeley
> Fix For: 4.0
>
>
> ConcurrentLRUCache throws a class cast exception.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Commented: (SOLR-2410) ConcurrentLRUCache can throw class cast exception

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on SOLR-2410:
---

Btw. this is exactly the reason Collections declare Object[] toArray() and not 
T[] toArray -- in the latter case the compiler adds casts to the expression's 
argument type and collections can't know their component type after type 
erasure. Eh, C#/.NET is so much more elegant with generics.

> ConcurrentLRUCache can throw class cast exception
> -
>
> Key: SOLR-2410
> URL: https://issues.apache.org/jira/browse/SOLR-2410
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Yonik Seeley
> Fix For: 4.0
>
>
> ConcurrentLRUCache throws a class cast exception.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Commented: (SOLR-2410) ConcurrentLRUCache can throw class cast exception

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on SOLR-2410:
---

It's because there's a bug -- PriorityQueue declares a generic array:

  protected T[] heap; 

but assigns an Object[] to it in:

heap = (T[]) new Object[heapSize]; // T is unbounded type, so this 
unchecked cast works always

this is true only if heap is not exposed outside the class (and is the pattern 
used in JDK's ArrayDeque, for  example). Unfortunately the compiler will 
insert casts if you have a subclass with a narrowed generic type to ensure the 
array is indeed of proper type. The solution is to:

1) allocate arrays of real component type (impossible if you don't know it in 
advance or don't have an existing array or its component). Example: Google 
Guava's ObjectArrays.newArray, as here:

http://guava-libraries.googlecode.com/svn/tags/release08/javadoc/com/google/common/collect/ObjectArrays.html#newArray(java.lang.Class,
 int)

2) cast superclass's array to (Object[]) first, then cast to the concrete 
component type. Here:

(CacheEntry) ((Object[]) heap)[1];

3) Declare PriorityQueue's internal array as Object[] and provide a getter that 
casts components to (T)?

> ConcurrentLRUCache can throw class cast exception
> -
>
> Key: SOLR-2410
> URL: https://issues.apache.org/jira/browse/SOLR-2410
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Yonik Seeley
> Fix For: 4.0
>
>
> ConcurrentLRUCache throws a class cast exception.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Commented: (SOLR-2410) ConcurrentLRUCache can throw class cast exception

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-2410:


Here's an even smaller version w/ no dependencies:

{code}
class C {
}

class A {
  public T1[] arr = (T1[])(new Object[1]);
}

class B extends A> {
  public C tst() {
return arr[0];
  }

  public static void main(String[] args) {
new B().tst();
  }
}
{code}


> ConcurrentLRUCache can throw class cast exception
> -
>
> Key: SOLR-2410
> URL: https://issues.apache.org/jira/browse/SOLR-2410
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Yonik Seeley
> Fix For: 4.0
>
>
> ConcurrentLRUCache throws a class cast exception.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Commented: (SOLR-2410) ConcurrentLRUCache can throw class cast exception

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-2410:


Here's the smallest version I could reproduce the issue with.

{code}
class CacheEntry {
}

class PQueue extends PriorityQueue> {
  public static void main(String[] args) {
new PQueue().tst();
  }

  PQueue() {
super.initialize(1);
  }

  @Override
  protected boolean lessThan(CacheEntry a, CacheEntry b) {
return true;
  }

  public CacheEntry tst() {
return heap[1];
  }
}
{code}

I just cut-n-pasted the code into BasicFunctionalityTest, run main() from my 
IDE, and presto:

{code}
Exception in thread "main" java.lang.ClassCastException: [Ljava.lang.Object; 
cannot be cast to [Lorg.apache.solr.CacheEntry;
at org.apache.solr.PQueue.tst(BasicFunctionalityTest.java:81)
at org.apache.solr.PQueue.main(BasicFunctionalityTest.java:68)
{code}

> ConcurrentLRUCache can throw class cast exception
> -
>
> Key: SOLR-2410
> URL: https://issues.apache.org/jira/browse/SOLR-2410
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Yonik Seeley
> Fix For: 4.0
>
>
> ConcurrentLRUCache throws a class cast exception.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Created: (SOLR-2410) ConcurrentLRUCache can throw class cast exception

[Yonik Seeley (JIRA)]

ConcurrentLRUCache can throw class cast exception
-

 Key: SOLR-2410
 URL: https://issues.apache.org/jira/browse/SOLR-2410
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Yonik Seeley
 Fix For: 4.0


ConcurrentLRUCache throws a class cast exception.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5703 - Failure

[Apache Hudson Server]

Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5703/

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

Error Message:
.response.numFound:35!=67

Stack Trace:
junit.framework.AssertionFailedError: .response.numFound:35!=67
at 
org.apache.solr.BaseDistributedSearchTestCase.compareResponses(BaseDistributedSearchTestCase.java:584)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:337)
at 
org.apache.solr.cloud.BasicDistributedZkTest.doTest(BasicDistributedZkTest.java:129)
at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:593)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1213)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1145)




Build Log (for compile errors):
[...truncated 8624 lines...]



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

[jira] Commented: (LUCENE-2573) Tiered flushing of DWPTs by RAM with low/high water marks

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-2573:


OK I tested trunk vs RT branch + patch, indexing 10M Wikipedia docs
with 1 GB RAM buffer and 8 threads.

Trunk took 298 sec for initial indexing, then 198 sec to wait for
merges to catch up, and 24 sec to commit.

RT+patch took 289 sec for initial indexing, then 225 sec to wait for
merges, then 26 sec to commit.

Not sure yet why I'm not seeing real concurrency gains here... is
there anything printed to infoStream if the safety net (hijack app
threads) kicks in?


> Tiered flushing of DWPTs by RAM with low/high water marks
> -
>
> Key: LUCENE-2573
> URL: https://issues.apache.org/jira/browse/LUCENE-2573
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: Index
>Reporter: Michael Busch
>Assignee: Simon Willnauer
>Priority: Minor
> Fix For: Realtime Branch
>
> Attachments: LUCENE-2573.patch, LUCENE-2573.patch, LUCENE-2573.patch, 
> LUCENE-2573.patch
>
>
> Now that we have DocumentsWriterPerThreads we need to track total consumed 
> RAM across all DWPTs.
> A flushing strategy idea that was discussed in LUCENE-2324 was to use a 
> tiered approach:  
> - Flush the first DWPT at a low water mark (e.g. at 90% of allowed RAM)
> - Flush all DWPTs at a high water mark (e.g. at 110%)
> - Use linear steps in between high and low watermark:  E.g. when 5 DWPTs are 
> used, flush at 90%, 95%, 100%, 105% and 110%.
> Should we allow the user to configure the low and high water mark values 
> explicitly using total values (e.g. low water mark at 120MB, high water mark 
> at 140MB)?  Or shall we keep for simplicity the single setRAMBufferSizeMB() 
> config method and use something like 90% and 110% for the water marks?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: issue with automatic iterable detection?

[Andi Vajda]

On Mon, 7 Mar 2011, Bill Janssen wrote:


Andi Vajda  wrote:


Where does t_JArray get defined?  I can't find it.


I'm not sure there is one. If you can provide me with a piece of Java
to reproduce this, I can fix it faster.


I've narrowed this down to three iterator classes which cause this
issue.  Now I've got to see what's the common factor.


Probably an array being used as a type parameter ?

Andi..

Re: make ResponseHeader an object on SolrQueryResponse?

[Ryan McKinley]

hymm, maybe this is not a great idea...  many things assume the entire
response is represented as a single NamedList.

but I still think we should drop the old format in XMLWriter



On Mon, Mar 7, 2011 at 4:32 PM, Ryan McKinley  wrote:
> Currently we have:
>
>  public NamedList getResponseHeader() {
>    @SuppressWarnings("unchecked")
>          SimpleOrderedMap header = (SimpleOrderedMap)
> values.get("responseHeader");
>          return header;
>  }
>
> and then every response writer pick out this value and treats it different.
>
> Can we just put the variable directly on SolrQueryResponse?
>
> Also, any need for /trunk to keep the old style response header format
> in XMLWriter?
>
>    if (version<=2100 && sz>0) {
>      Object header = lst.getVal(0);
>      if (header instanceof NamedList &&
> "responseHeader".equals(lst.getName(0))) {
>        writer.write("");
> ...
>
> I'm hoping to clean up the response writers, and the responeHeader
> sticks out as a baby step.
>
> ryan
>

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

make ResponseHeader an object on SolrQueryResponse?

[Ryan McKinley]

Currently we have:

  public NamedList getResponseHeader() {
@SuppressWarnings("unchecked")
  SimpleOrderedMap header = (SimpleOrderedMap)
values.get("responseHeader");
  return header;
  }

and then every response writer pick out this value and treats it different.

Can we just put the variable directly on SolrQueryResponse?

Also, any need for /trunk to keep the old style response header format
in XMLWriter?

if (version<=2100 && sz>0) {
  Object header = lst.getVal(0);
  if (header instanceof NamedList &&
"responseHeader".equals(lst.getName(0))) {
writer.write("");
...

I'm hoping to clean up the response writers, and the responeHeader
sticks out as a baby step.

ryan

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

Re: ClassCastException thrown in Join and Pivot

[Yonik Seeley]

Hmmm, this is definitely strange.
Doesn't seem like it has anything to do with the join patch, or the
field values.
For some strange reason, an internal priority queue (inheriting from
lucene's priority queue) in the ConcurrentLRUCache can't cast one of
it's internal arrays to the correct type.  It can't cast Object[] to
CacheEntry[]

This smells like some sort of weird classloading issue.  Are you sure
you don't have any old jars or class directories sitting around in the
classpath somewhere?

-Yonik
http://lucidimagination.com


On Mon, Mar 7, 2011 at 3:53 PM, Peter Sturge  wrote:
> Hi,
>
> I (and apparently others) have noticed a rather strange and seemingly
> intermittent ClassCastException in facet caching when using join (SOLR-2272)
> and sometimes pivot as well.
>
> A similar discussion from others noticing this can be found here:
> http://www.lucidimagination.com/search/document/30c0029a7eb194c4/are_there_any_restrictions_on_what_kind_of_how_many_fields_you_can_use_in_pivot_query_i_get_classca#7ef18fd2add7ee5c
>
> Errors/stack trace for the exception included below.
>
> Solr Version: This is seen intermittently on trunk + SOLR-2272.
>
> From initial testing, maybe this is an escaping/tokenizing issue? If I have
> facet values that include a '-' in the string, the exception is thrown.
> Strangely, it seems to show up in other scenarios, but maybe under the
> covers there are non-alphanum and/or special chars ending up in facet
> parameters.
>
> I'm not very familiar with the join and/or pivot code (but wow they are
> great additions!) -- perhaps someone with more knowledge in this area can
> chime in?
>
> Many thanks,
> Peter
>
>
> Here's a sample query that generates an error:
>  http://127.0.0.1:9000/solr/select?q=*:*&fq={!join from=customer_number
> to=customer_number}customer_name:onlineltd
>
> N.B. Both the customer_number and customer_name fields have some [but not
> all] values that contain '-', whitespace, and other non-alphanum chars. The
> last 'onlineltd' can be any value to produce the exception.
> Also, the server log shows this exception is thrown twice in quick
> succession.
>
> Error messages:
>
> Excerpt just before stack trace from the server log:
> 07-Mar-2011 20:40:08 org.apache.solr.core.SolrCore execute
> INFO: [] webapp=/solr path=/select
> params={fq={!join+from%3Dcustomer_number+to%3
> Dcustomer_number}customer_name:*ltd*&q=*:*&rows=0} status=500 QTime=34
> 07-Mar-2011 20:40:08 org.apache.solr.common.SolrException log
> SEVERE: java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to
> [Lorg.apache.solr.common.util.ConcurrentLRUCache$CacheEntry;
>
>
> And here's the client side http trace:
>
> HTTP ERROR 500
>
> Problem accessing /solr/select. Reason:
>
> [Ljava.lang.Object; cannot be cast to
> [Lorg.apache.solr.common.util.ConcurrentLRUCache$CacheEntry;
>
> java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to
> [Lorg.apache.solr.common.util.ConcurrentLRUCache$CacheEntry;
>
>   at
> org.apache.solr.common.util.ConcurrentLRUCache$PQueue.myInsertWithOverflow(ConcurrentLRUCache.java:377)
>   at
> org.apache.solr.common.util.ConcurrentLRUCache.markAndSweep(ConcurrentLRUCache.java:329)
>   at
> org.apache.solr.common.util.ConcurrentLRUCache.put(ConcurrentLRUCache.java:144)
>
>   at org.apache.solr.search.FastLRUCache.put(FastLRUCache.java:131)
>   at
> org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:809)
>   at
> org.apache.solr.search.JoinQuery$JoinQueryWeight.getDocSet(JoinQParserPlugin.java:256)
>
>   at
> org.apache.solr.search.JoinQuery$JoinQueryWeight.scorer(JoinQParserPlugin.java:139)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:536)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:303)
>
>   at
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:849)
>   at
> org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:568)
>   at
> org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:603)
>
>   at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1088)
>   at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1069)
>   at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:337)
>
>   at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:431)
>   at
> org.apache.solr.handler.component.SearchHandler.handleSingleQuery(SearchHandler.java:304)
>   at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:261)
>
>   at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1298)
>   at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341)
>
>   at
> org.apache.solr.servle

ClassCastException thrown in Join and Pivot

[Peter Sturge]

Hi,

I (and apparently others) have noticed a rather strange and seemingly
intermittent ClassCastException in facet caching when using join (SOLR-2272)
and sometimes pivot as well.

A similar discussion from others noticing this can be found here:
http://www.lucidimagination.com/search/document/30c0029a7eb194c4/are_there_any_restrictions_on_what_kind_of_how_many_fields_you_can_use_in_pivot_query_i_get_classca#7ef18fd2add7ee5c

Errors/stack trace for the exception included below.

Solr Version: This is seen intermittently on trunk + SOLR-2272.

>From initial testing, maybe this is an escaping/tokenizing issue? If I have
facet values that include a '-' in the string, the exception is thrown.
Strangely, it seems to show up in other scenarios, but maybe under the
covers there are non-alphanum and/or special chars ending up in facet
parameters.

I'm not very familiar with the join and/or pivot code (but wow they are
great additions!) -- perhaps someone with more knowledge in this area can
chime in?

Many thanks,
Peter


Here's a sample query that generates an error:
 http://127.0.0.1:9000/solr/select?q=*:*&fq={!join from=customer_number
to=customer_number}customer_name:onlineltd

N.B. Both the customer_number and customer_name fields have some [but not
all] values that contain '-', whitespace, and other non-alphanum chars. The
last 'onlineltd' can be any value to produce the exception.
Also, the server log shows this exception is thrown twice in quick
succession.

Error messages:

Excerpt just before stack trace from the server log:
07-Mar-2011 20:40:08 org.apache.solr.core.SolrCore execute
INFO: [] webapp=/solr path=/select
params={fq={!join+from%3Dcustomer_number+to%3
Dcustomer_number}customer_name:*ltd*&q=*:*&rows=0} status=500 QTime=34
07-Mar-2011 20:40:08 org.apache.solr.common.SolrException log
SEVERE: java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to
[Lorg.apache.solr.common.util.ConcurrentLRUCache$CacheEntry;


And here's the client side http trace:
HTTP ERROR 500

Problem accessing /solr/select. Reason:

[Ljava.lang.Object; cannot be cast to
[Lorg.apache.solr.common.util.ConcurrentLRUCache$CacheEntry;

java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to
[Lorg.apache.solr.common.util.ConcurrentLRUCache$CacheEntry;
at 
org.apache.solr.common.util.ConcurrentLRUCache$PQueue.myInsertWithOverflow(ConcurrentLRUCache.java:377)
at 
org.apache.solr.common.util.ConcurrentLRUCache.markAndSweep(ConcurrentLRUCache.java:329)
at 
org.apache.solr.common.util.ConcurrentLRUCache.put(ConcurrentLRUCache.java:144)
at org.apache.solr.search.FastLRUCache.put(FastLRUCache.java:131)
at 
org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:809)
at 
org.apache.solr.search.JoinQuery$JoinQueryWeight.getDocSet(JoinQParserPlugin.java:256)
at 
org.apache.solr.search.JoinQuery$JoinQueryWeight.scorer(JoinQParserPlugin.java:139)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:536)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:303)
at 
org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:849)
at 
org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:568)
at 
org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:603)
at 
org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1088)
at 
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1069)
at 
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:337)
at 
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:431)
at 
org.apache.solr.handler.component.SearchHandler.handleSingleQuery(SearchHandler.java:304)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:261)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1298)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
at 
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at 
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at 
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
at 
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at 
org.mortbay.jetty.handler.

[jira] Resolved: (SOLR-2402) Add more debug info for DocumentBuilder errors

[Ryan McKinley (JIRA)]

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

Ryan McKinley resolved SOLR-2402.
-

   Resolution: Fixed
Fix Version/s: 4.0

added to /trunk in 1078928

could be merged with 3.x, but lets wait 'till after the pending release

> Add more debug info for DocumentBuilder errors
> --
>
> Key: SOLR-2402
> URL: https://issues.apache.org/jira/browse/SOLR-2402
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: SOLR-2402-doc-builder-error-messages.patch
>
>
> When digging though logs, it is hard to figure out what went wrong with 
> errors like:
> {code}
> 2011-03-04 11:43:52,773 INFO 
> org.apache.solr.update.processor.UpdateRequestProcessor - {} 0 0
> 2011-03-04 11:43:52,773 ERROR org.apache.solr.core.SolrCore - 
> java.lang.NumberFormatException: multiple points
>   at 
> sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1084)
>   at java.lang.Float.parseFloat(Float.java:422)
>   at org.apache.solr.schema.TrieField.createField(TrieField.java:512)
>   at org.apache.solr.schema.SchemaField.createField(SchemaField.java:94)
>   at 
> org.apache.solr.update.DocumentBuilder.addField(DocumentBuilder.java:204)
>   at 
> org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:277)
>   at 
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:60)
>   at 
> org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:94)
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:53)
> {code}
> would be nice to know the field name/value and ideally the ID value also.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Commented: (SOLR-2402) Add more debug info for DocumentBuilder errors

[Ryan McKinley (JIRA)]

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

Ryan McKinley commented on SOLR-2402:
-

This now gives an error like:
{panel}

org.apache.solr.common.SolrException: ERROR: [doc=123] Error adding field 
'weight'='not a number'
at 
org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:325)
at 
org.apache.solr.update.DocumentBuilderTest.testExceptions(DocumentBuilderTest.java:90)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

Caused by: java.lang.NumberFormatException: For input string: "not a number"
at 
sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1224)
at java.lang.Float.parseFloat(Float.java:422)
at org.apache.solr.schema.TrieField.createField(TrieField.java:508)
at org.apache.solr.schema.SchemaField.createField(SchemaField.java:97)
at 
org.apache.solr.update.DocumentBuilder.addField(DocumentBuilder.java:204)
at 
org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:282)
... 29 more
{panel}



> Add more debug info for DocumentBuilder errors
> --
>
> Key: SOLR-2402
> URL: https://issues.apache.org/jira/browse/SOLR-2402
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
>Priority: Trivial
> Attachments: SOLR-2402-doc-builder-error-messages.patch
>
>
> When digging though logs, it is hard to figure out what went wrong with 
> errors like:
> {code}
> 2011-03-04 11:43:52,773 INFO 
> org.apache.solr.update.processor.UpdateRequestProcessor - {} 0 0
> 2011-03-04 11:43:52,773 ERROR org.apache.solr.core.SolrCore - 
> java.lang.NumberFormatException: multiple points
>   at 
> sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1084)
>   at java.lang.Float.parseFloat(Float.java:422)
>   at org.apache.solr.schema.TrieField.createField(TrieField.java:512)
>   at org.apache.solr.schema.SchemaField.createField(SchemaField.java:94)
>   at 
> org.apache.solr.update.DocumentBuilder.addField(DocumentBuilder.java:204)
>   at 
> org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:277)
>   at 
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:60)
>   at 
> org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:94)
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:53)
> {code}
> would be nice to know the field name/value and ideally the ID value also.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Issue Comment Edited: (SOLR-2402) Add more debug info for DocumentBuilder errors

[Ryan McKinley (JIRA)]

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

Ryan McKinley edited comment on SOLR-2402 at 3/7/11 8:30 PM:
-

This now gives an error like:
{code}

org.apache.solr.common.SolrException: ERROR: [doc=123] Error adding field 
'weight'='not a number'
at 
org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:325)
at 
org.apache.solr.update.DocumentBuilderTest.testExceptions(DocumentBuilderTest.java:90)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

Caused by: java.lang.NumberFormatException: For input string: "not a number"
at 
sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1224)
at java.lang.Float.parseFloat(Float.java:422)
at org.apache.solr.schema.TrieField.createField(TrieField.java:508)
at org.apache.solr.schema.SchemaField.createField(SchemaField.java:97)
at 
org.apache.solr.update.DocumentBuilder.addField(DocumentBuilder.java:204)
at 
org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:282)
... 29 more
{code}



  was (Author: ryantxu):
This now gives an error like:
{panel}

org.apache.solr.common.SolrException: ERROR: [doc=123] Error adding field 
'weight'='not a number'
at 
org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:325)
at 
org.apache.solr.update.DocumentBuilderTest.testExceptions(DocumentBuilderTest.java:90)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

Caused by: java.lang.NumberFormatException: For input string: "not a number"
at 
sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1224)
at java.lang.Float.parseFloat(Float.java:422)
at org.apache.solr.schema.TrieField.createField(TrieField.java:508)
at org.apache.solr.schema.SchemaField.createField(SchemaField.java:97)
at 
org.apache.solr.update.DocumentBuilder.addField(DocumentBuilder.java:204)
at 
org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:282)
... 29 more
{panel}


  
> Add more debug info for DocumentBuilder errors
> --
>
> Key: SOLR-2402
> URL: https://issues.apache.org/jira/browse/SOLR-2402
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
>Priority: Trivial
> Attachments: SOLR-2402-doc-builder-error-messages.patch
>
>
> When digging though logs, it is hard to figure out what went wrong with 
> errors like:
> {code}
> 2011-03-04 11:43:52,773 INFO 
> org.apache.solr.update.processor.UpdateRequestProcessor - {} 0 0
> 2011-03-04 11:43:52,773 ERROR org.apache.solr.core.SolrCore - 
> java.lang.NumberFormatException: multiple points
>   at 
> sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1084)
>   at java.lang.Float.parseFloat(Float.java:422)
>   at org.apache.solr.schema.TrieField.createField(TrieField.java:512)
>   at org.apache.solr.schema.SchemaField.createField(SchemaField.java:94)
>   at 
> org.apache.solr.update.DocumentBuilder.addField(DocumentBuilder.java:204)
>   at 
> org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:277)
>   at 
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:60)
>   at 
> org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:94)
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:53)
> {code}
> would be nice to know the field name/value and ideally the ID value also.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Updated: (SOLR-2402) Add more debug info for DocumentBuilder errors

[Ryan McKinley (JIRA)]

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

Ryan McKinley updated SOLR-2402:


Attachment: SOLR-2402-doc-builder-error-messages.patch

> Add more debug info for DocumentBuilder errors
> --
>
> Key: SOLR-2402
> URL: https://issues.apache.org/jira/browse/SOLR-2402
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
>Priority: Trivial
> Attachments: SOLR-2402-doc-builder-error-messages.patch
>
>
> When digging though logs, it is hard to figure out what went wrong with 
> errors like:
> {code}
> 2011-03-04 11:43:52,773 INFO 
> org.apache.solr.update.processor.UpdateRequestProcessor - {} 0 0
> 2011-03-04 11:43:52,773 ERROR org.apache.solr.core.SolrCore - 
> java.lang.NumberFormatException: multiple points
>   at 
> sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1084)
>   at java.lang.Float.parseFloat(Float.java:422)
>   at org.apache.solr.schema.TrieField.createField(TrieField.java:512)
>   at org.apache.solr.schema.SchemaField.createField(SchemaField.java:94)
>   at 
> org.apache.solr.update.DocumentBuilder.addField(DocumentBuilder.java:204)
>   at 
> org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:277)
>   at 
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:60)
>   at 
> org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:94)
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:53)
> {code}
> would be nice to know the field name/value and ideally the ID value also.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5699 - Failure

[Apache Hudson Server]

Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5699/

No tests ran.

Build Log (for compile errors):
[...truncated 2993 lines...]



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

[jira] Commented: (SOLR-2409) edismax unescaped colon returns no results

[Ryan McKinley (JIRA)]

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

Ryan McKinley commented on SOLR-2409:
-

From: 
https://issues.apache.org/jira/browse/SOLR-1553?focusedCommentId=12994448&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12994448

Adding:
{code:java}
// Make sure the Boolean Query actually has somethign there
if( parsedUserQuery instanceof BooleanQuery ) {
  if( ((BooleanQuery)parsedUserQuery).getClauses().length < 1 ) {
parsedUserQuery = null;
  }
}
{code}

seems to fix thigns.

I don't understand the bigger picture well enough to know the implications

> edismax unescaped colon returns no results
> --
>
> Key: SOLR-2409
> URL: https://issues.apache.org/jira/browse/SOLR-2409
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Reporter: Ryan McKinley
>Priority: Minor
> Attachments: SOLR-2409-unescapedcolon.patch
>
>
> The edismax query parser should behave OK when a colon is in the query, but 
> does not refer to a field name.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Updated: (SOLR-2409) edismax unescaped colon returns no results

[Ryan McKinley (JIRA)]

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

Ryan McKinley updated SOLR-2409:


Attachment: SOLR-2409-unescapedcolon.patch

adding test and patch from SOLR-1553

> edismax unescaped colon returns no results
> --
>
> Key: SOLR-2409
> URL: https://issues.apache.org/jira/browse/SOLR-2409
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Reporter: Ryan McKinley
>Priority: Minor
> Attachments: SOLR-2409-unescapedcolon.patch
>
>
> The edismax query parser should behave OK when a colon is in the query, but 
> does not refer to a field name.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Created: (SOLR-2409) edismax unescaped colon returns no results

[Ryan McKinley (JIRA)]

edismax unescaped colon returns no results
--

 Key: SOLR-2409
 URL: https://issues.apache.org/jira/browse/SOLR-2409
 Project: Solr
  Issue Type: Bug
  Components: search
Reporter: Ryan McKinley
Priority: Minor


The edismax query parser should behave OK when a colon is in the query, but 
does not refer to a field name.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: using org.apache.jcc.PythonVM

[Bill Janssen]

Andi Vajda  wrote:

> > I did patch setuptools, and as you can see below, the config.py says
> > "Shared=True", so I believe I have shared mode enabled.  I'm certainly
> > using jcc with the "--shared" switch with no complaints.
> 
> Something's off. libjcc.so is not shown in your list.
> You need to solve that mystery before embedding can proceed.
> 
> Andi..

Looks like the patch failed, and the check doesn't notice that failure.
I removed setuptools, then re-installed it, then went to build JCC
again.  It told me I needed the patch, so I tried to apply the patch per
instructions:

% sudo patch -d /usr/lib/python2.6/dist-packages -Nup0 < 
/tmp/pylucene/branches/branch_3x/jcc/jcc/patches/patch.43.0.6c11
patching file setuptools/extension.py
patching file setuptools/command/build_ext.py
Hunk #1 FAILED at 85.
Hunk #2 succeeded at 177 (offset 7 lines).
Hunk #3 succeeded at 259 (offset 7 lines).
1 out of 3 hunks FAILED -- saving rejects to file 
setuptools/command/build_ext.py.rej
%

The EGG-INFO for "setuptools" says:

Metadata-Version: 1.0
Name: setuptools
Version: 0.6c11
Summary: 
Home-page: xxx
Author: xxx
Author-email: xxx
License: xxx
Description: xxx

build_ext.py:get_ext_filename() is:

def get_ext_filename(self, fullname):
filename = _build_ext.get_ext_filename(self,fullname)
if fullname not in self.ext_map:
return filename
ext = self.ext_map[fullname]
if isinstance(ext,Library):
fn, ext = os.path.splitext(filename)
return self.shlib_compiler.library_filename(fn,libtype)
elif use_stubs and ext._links_to_dynamic:
d,fn = os.path.split(filename)
return os.path.join(d,'dl-'+fn)
else:
return filename

I believe the patched version should look like this:

def get_ext_filename(self, fullname):
filename = _build_ext.get_ext_filename(self,fullname)
if fullname not in self.ext_map:
return filename
ext = self.ext_map[fullname]
if isinstance(ext,Library):
if ext.force_shared and not use_stubs:
_libtype = 'shared'
else:
_libtype = libtype
fn, ext = os.path.splitext(filename)
return self.shlib_compiler.library_filename(fn,_libtype)
elif use_stubs and ext._links_to_dynamic:
d,fn = os.path.split(filename)
return os.path.join(d,'dl-'+fn)
else:
return filename

Right?

Bill

Re: using org.apache.jcc.PythonVM

[Bill Janssen]

Andi Vajda  wrote:

> > So, I went to my Mac, and looked for libjcc.dylib.  Sure enough,
> > it's there.  So I tried this simple program:
> >
> > import org.apache.jcc.PythonVM;
> >
> > public class test {
> >
> >public static void main (String[] argv) {
> >PythonVM.start("/usr/bin/python",
> > new String[] { "-c", "import time; print time.localtime()"});
> >}
> > }
> 
> It seems that you think that this is going to run /usr/bin/python.
> Not really.

Right.  I finally broke down and read the code.  I see there's no way to
do a "simple" test case.

What the "instantiate" code does is to load a callable from a specified
module, then call it, passing no arguments.  That callable must return
an instance of a Python class which explicitly extends a Java class, if
the value is to be returned to Java.  Otherwise, a value of "null" is
returned.  The callable may of course have side-effects in the Python
world.

It would be nice to be able to pass arguments to the callable.

And there doesn't seem to be any way to modify Python's sys.path before
one attempts to instantiate one's own Python class, either.  Adding a
PythonVM.exec() method would be a help there.

> To fix that, to help the dynamic linker to load that library, you need
> to change the LFLAGS for 'darwin' in JCC's setup.py to also list the
> python framework by adding '-framework', 'Python' to that list.
> After rebuilding JCC, be sure then that otool lists libpython.dylib to
> verify that it worked.

Is there any reason not to make that change globally?  Is there a
downside to automatically building against the Python framework on OS X?

Bill

[jira] Commented: (SOLR-2408) Solr 1.4.1 javaNullPointerException

[Christos Constantinou (JIRA)]

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

Christos Constantinou commented on SOLR-2408:
-

The exception occurred because the field was initially defined as int and then 
changed to text. The data that were previously stored in Solr were processed as 
text whereas they were stored as int - thus unhandled.

> Solr 1.4.1 javaNullPointerException
> ---
>
> Key: SOLR-2408
> URL: https://issues.apache.org/jira/browse/SOLR-2408
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 1.4.1
> Environment: OS X, possibly other *ix as well
>Reporter: Christos Constantinou
>Priority: Minor
>
> SEVERE: java.lang.NullPointerException
>   at 
> org.apache.solr.request.JSONWriter.writeStr(JSONResponseWriter.java:613)
>   at org.apache.solr.schema.TextField.write(TextField.java:49)
>   at org.apache.solr.schema.SchemaField.write(SchemaField.java:113)
>   at 
> org.apache.solr.request.JSONWriter.writeDoc(JSONResponseWriter.java:383)
>   at 
> org.apache.solr.request.JSONWriter.writeDoc(JSONResponseWriter.java:449)
>   at 
> org.apache.solr.request.JSONWriter.writeDocList(JSONResponseWriter.java:496)
>   at 
> org.apache.solr.request.TextResponseWriter.writeVal(TextResponseWriter.java:141)
>   at 
> org.apache.solr.request.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:179)
>   at 
> org.apache.solr.request.JSONWriter.writeNamedList(JSONResponseWriter.java:294)
>   at 
> org.apache.solr.request.JSONWriter.writeResponse(JSONResponseWriter.java:92)
>   at 
> org.apache.solr.request.JSONResponseWriter.write(JSONResponseWriter.java:51)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.writeResponse(SolrDispatchFilter.java:325)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
>   at 
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
>   at 
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
>   at 
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
>   at 
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
>   at 
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
>   at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
>   at 
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
>   at 
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
>   at 
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
>   at org.mortbay.jetty.Server.handle(Server.java:285)
>   at 
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
>   at 
> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
>   at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
>   at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
>   at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
>   at 
> org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
>   at 
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
> To reproduce the exception, the following ingredients are required:
> - A query that is sorted by a date field in DESC order, ASC will not crash
> - A multivalued field like so  indexed="true" stored="true" multiValued="true" />
> - Exclude the multivalued field from either the query (AND NOT 
> deleted_in:XXX) or with a filter query (-deleted_in:XXX)
> - The value XXX of deleted_in MUST MATCH at least one value, if not, the 
> crash will not occur.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: [Lucene.Net] [jira] Resolved: (LUCENENET-403) Improve site layout and design

[Christopher Currens]

The site does look great, I only have one concern and that is that is seems
we used bitbucket.org as our sole design inspiration.  I'm concerned that it
looks *too* much like the bitbucket site and that may cause problems in the
future.  I don't like having words and not backing it up without any
actions, so I would like to add to the design if that's alright with
everyone, I don't have anything now, but I can get something in the next few
days...I just need some time to think about the design.

Christopher

On Mon, Mar 7, 2011 at 5:59 AM, Michael Herndon  wrote:

> +1, Great Job Prescott.
>
> On Mon, Mar 7, 2011 at 3:44 AM, Glyn Darkin 
> wrote:
> > The site looks great.
> >
> > Well done!!!
> >
> > Glyn
> >
> > On 6 Mar 2011, at 23:04, Prescott Nasser (JIRA) wrote:
> >
> >>
> >> [
> https://issues.apache.org/jira/browse/LUCENENET-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
> >>
> >> Prescott Nasser resolved LUCENENET-403.
> >> ---
> >>
> >>Resolution: Fixed
> >>
> >> Latest Layout was voted upon and selected. Images were updated by Mike
> and I've moved it to staging:
> http://lucene.net.staging.apache.org/lucene.net/index.html.
> >>
> >>> Improve site layout and design
> >>> --
> >>>
> >>>Key: LUCENENET-403
> >>>URL:
> https://issues.apache.org/jira/browse/LUCENENET-403
> >>>Project: Lucene.Net
> >>> Issue Type: Sub-task
> >>> Components: Project Infrastructure
> >>>   Reporter: Troy Howard
> >>>   Assignee: Prescott Nasser
> >>>Fix For: Lucene.Net 2.9.2
> >>>
> >>>Attachments: layout1.zip, layout2.zip
> >>>
> >>>
> >>> Improve the website layout and design. Current staging design is based
> off an extremely simplistic implementation of Apache CMS basic template
> using the default Apache CMS CSS styling. Let's try to make it look better
> and have a more intuitive navigational structure.
> >>> See staging site at:
> >>> http://lucene.net.staging.apache.org/lucene.net/
> >>> To edit content, please use:
> >>> https://cms.apache.org/lucene.net/
> >>
> >> --
> >> This message is automatically generated by JIRA.
> >> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
> >
> > Glyn Darkin
> >
> > Darkin Systems Ltd
> > Mob: 07961815649
> > Fax: 08717145065
> > Web: www.darkinsystems.com
> >
> > Company No: 6173001
> > VAT No: 906350835
> >
> >
> >
> >
> >
> >
>

Re: [VOTE] Lucene and Solr 3.1 release candidate

[Yonik Seeley]

On Mon, Mar 7, 2011 at 10:52 AM, Smiley, David W.  wrote:
> So https://issues.apache.org/jira/browse/SOLR-2405 didn't make it in 
> yesterday (apparently it didn't)? :-(  Darn... maybe I shouldn't have waited 
> for a committer to agree with the issue. I would have had it in Saturday.


Oops, I thought it had made it (I accidentally marked fixed for 3.1).
I guess the branch was created first.
If we end up doing a respin, I can merge this to the branch.

-Yonik
http://lucidimagination.com

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

[jira] Updated: (LUCENE-2573) Tiered flushing of DWPTs by RAM with low/high water marks

[Simon Willnauer (JIRA)]

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

Simon Willnauer updated LUCENE-2573:


Attachment: LUCENE-2573.patch

Here is my first cut / current status on this issue. First of all I have a 
couple of failures related to deletes but they seem not to be related 
(directly) to this patch since I can reproduce them even without the patch. 
all of the failures are related to deletes in some way so I suspect that there 
is another issue for that, no?

This patch implements a tiered flush strategy combined with a concurrent flush 
approach. 

* All decisions are based on a FlushPolicy which operates on a 
DocumentsWriterSession (does the ram tracking and housekeeping), once the flush 
policy encounters a transition to the next tier it marks the "largest" ram 
consuming thread 
as flushPending if we transition from a lower level and all threads if we 
transition from the upper watermark (level). DocumentsWriterSession shifts the 
memory of a pending thread to a new memory "level" (pendingBytes) and marks the 
thread as pending. 

* Once FlushPolicy#findFlushes(..) returns the caller tries to check if itself 
needs to flush and if so it "checks-out" its DWPT and replaces it with a 
complete new instance. Releases the lock on the ThreadState and continues to 
flush the "checked-out" DWPT. After this is done or if the current DWPT doesn't 
need flushing the indexing thread checks if there are any other pending flushes 
and tries to (non-blocking) obtain their lock. It only tries to get the lock 
and only tries once since if the lock is taken another thread is already 
holding it and will see the flushPending once finished adding the document.


This approach tries to utilize as much conccurrency as possible while flushing 
the DWPT and releaseing its ThreadState with an entirely new DWPT. Yet, this 
might also have problems especially if IO is slow and we filling up indexing 
RAM too fast. To prevent us from bloating up the memory too much I introduced a 
notation of "healtiness" which operates on the net-bytes used in the 
DocumentsWriterSession (flushBytes + pendingBytes + activeBytes) -- (flushBytes 
- mem consumption of currently flushing DWPT, pendingBytes - mem consumption of 
marked as pending ThreadStates / DWPT, activeBytes mem consuption of the 
indexing DWPT). If net-bytes reach a certain threshold (2*maxRam currently) I 
stop incoming threads until the session becomes healty again.

I run luceneutil with trunk vs. LUCENE-2573 indexing 300k wikipedia docs with 
1GB MaxRamBuffer and 4 Threads. Searches on both indexes yield identical 
results (Phew!) 
Indexing time in ms look promising
||trunk||patch|| diff ||
|134129 ms|102932 ms|{color:green}23.25%{color}| 

This patch is still kind of rough and needs iterations so reviews and questions 
are very much welcome.




> Tiered flushing of DWPTs by RAM with low/high water marks
> -
>
> Key: LUCENE-2573
> URL: https://issues.apache.org/jira/browse/LUCENE-2573
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: Index
>Reporter: Michael Busch
>Assignee: Simon Willnauer
>Priority: Minor
> Fix For: Realtime Branch
>
> Attachments: LUCENE-2573.patch, LUCENE-2573.patch, LUCENE-2573.patch, 
> LUCENE-2573.patch
>
>
> Now that we have DocumentsWriterPerThreads we need to track total consumed 
> RAM across all DWPTs.
> A flushing strategy idea that was discussed in LUCENE-2324 was to use a 
> tiered approach:  
> - Flush the first DWPT at a low water mark (e.g. at 90% of allowed RAM)
> - Flush all DWPTs at a high water mark (e.g. at 110%)
> - Use linear steps in between high and low watermark:  E.g. when 5 DWPTs are 
> used, flush at 90%, 95%, 100%, 105% and 110%.
> Should we allow the user to configure the low and high water mark values 
> explicitly using total values (e.g. low water mark at 120MB, high water mark 
> at 140MB)?  Or shall we keep for simplicity the single setRAMBufferSizeMB() 
> config method and use something like 90% and 110% for the water marks?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Commented: (SOLR-2113) Create TermsQParser that deals with toInternal() conversion of external terms

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-2113:


It appears what I understood to be "idempotent" is different then the meaning 
here.  I looked this word up in 
[wikipedia|http://en.wikipedia.org/wiki/Idempotence#Computer_science_meaning] 
and it appears in the context of computer science that it has two separate 
meanings.  One meaning has more to do with side-effects, which is the meaning 
I've always attached to the word. It comes up a lot when talking about 
thread-safe code.  The other meaning associated with functional programming is 
the meaning intended by Yonik & Rob here -- a meaning I don't think I would 
ever put to use.  It's unfortunate that this word is ambiguous... since it's 
very useful to use it to say that a method on a class always has the same 
result for the same input, _without_ saying you can give the output back to the 
input again and also get the same result.

> Create TermsQParser that deals with toInternal() conversion of external terms
> -
>
> Key: SOLR-2113
> URL: https://issues.apache.org/jira/browse/SOLR-2113
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Hoss Man
> Fix For: 4.0
>
> Attachments: SOLR-2113.patch
>
>
> For converting facet.field response constraints into filter queries, it would 
> be helpful to have a QParser that generated a TermQuery using the 
> toInternal() converted result of the raw "q" param

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Created: (SOLR-2408) Solr 1.4.1 javaNullPointerException

[Christos Constantinou (JIRA)]

Solr 1.4.1 javaNullPointerException
---

 Key: SOLR-2408
 URL: https://issues.apache.org/jira/browse/SOLR-2408
 Project: Solr
  Issue Type: Bug
Affects Versions: 1.4.1
 Environment: OS X, possibly other *ix as well
Reporter: Christos Constantinou
Priority: Minor


SEVERE: java.lang.NullPointerException
at 
org.apache.solr.request.JSONWriter.writeStr(JSONResponseWriter.java:613)
at org.apache.solr.schema.TextField.write(TextField.java:49)
at org.apache.solr.schema.SchemaField.write(SchemaField.java:113)
at 
org.apache.solr.request.JSONWriter.writeDoc(JSONResponseWriter.java:383)
at 
org.apache.solr.request.JSONWriter.writeDoc(JSONResponseWriter.java:449)
at 
org.apache.solr.request.JSONWriter.writeDocList(JSONResponseWriter.java:496)
at 
org.apache.solr.request.TextResponseWriter.writeVal(TextResponseWriter.java:141)
at 
org.apache.solr.request.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:179)
at 
org.apache.solr.request.JSONWriter.writeNamedList(JSONResponseWriter.java:294)
at 
org.apache.solr.request.JSONWriter.writeResponse(JSONResponseWriter.java:92)
at 
org.apache.solr.request.JSONResponseWriter.write(JSONResponseWriter.java:51)
at 
org.apache.solr.servlet.SolrDispatchFilter.writeResponse(SolrDispatchFilter.java:325)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at 
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at 
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at 
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at 
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
at 
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at 
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at 
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
at 
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
at 
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
at 
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)


To reproduce the exception, the following ingredients are required:
- A query that is sorted by a date field in DESC order, ASC will not crash
- A multivalued field like so 
- Exclude the multivalued field from either the query (AND NOT deleted_in:XXX) 
or with a filter query (-deleted_in:XXX)
- The value XXX of deleted_in MUST MATCH at least one value, if not, the crash 
will not occur.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: [Lucene.Net] ndepend license requirements - apache rules

[Stefan Bodewig]

On 2011-03-07, Michael Herndon wrote:

> Does the following violate any of the rules put forth by apache or
> give anyone pause?

>> If you could put our Powered by NDepend logo on your OSS project
>> website we'd be happy to sponsor Apache Lucene.Net.

Yes it does.

You can't sponsor individual projects at the ASF, only the ASF as a
whole.

Other people and companies have donated licenses - committer only link
 -
and not received this sort of backlink.

Any sort of "thank you" link had to be cleared with fundraising@apache,
see http://www.apache.org/foundation/sponsorship.html and
http://www.apache.org/foundation/thanks.html

Stefan

Solr Cell & DataImport Tika handler broken - fails to index Zip file contents

[Jayendra Patil]

Working with the latest Solr Trunk code and seems the Tika handlers
for Solr Cell (ExtractingDocumentLoader.java) and Data Import handler
(TikaEntityProcessor.java) fails to index the zip file contents again.
It just indexes the file names again.
This issue was addressed some time back, late last year, but seems to
have reappeared with the latest code.

I had raised a jira for the Data Import handler part with the patch
and the testcase - https://issues.apache.org/jira/browse/SOLR-2332.
The same fix is needed for the Solr Cell as well.

I can raise a jira and provide the patch for the same, if the patch
seems good enough.

Regards,
Jayendra

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

[jira] Assigned: (LUCENE-2573) Tiered flushing of DWPTs by RAM with low/high water marks

[Simon Willnauer (JIRA)]

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

Simon Willnauer reassigned LUCENE-2573:
---

Assignee: Simon Willnauer  (was: Michael Busch)

> Tiered flushing of DWPTs by RAM with low/high water marks
> -
>
> Key: LUCENE-2573
> URL: https://issues.apache.org/jira/browse/LUCENE-2573
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: Index
>Reporter: Michael Busch
>Assignee: Simon Willnauer
>Priority: Minor
> Fix For: Realtime Branch
>
> Attachments: LUCENE-2573.patch, LUCENE-2573.patch, LUCENE-2573.patch
>
>
> Now that we have DocumentsWriterPerThreads we need to track total consumed 
> RAM across all DWPTs.
> A flushing strategy idea that was discussed in LUCENE-2324 was to use a 
> tiered approach:  
> - Flush the first DWPT at a low water mark (e.g. at 90% of allowed RAM)
> - Flush all DWPTs at a high water mark (e.g. at 110%)
> - Use linear steps in between high and low watermark:  E.g. when 5 DWPTs are 
> used, flush at 90%, 95%, 100%, 105% and 110%.
> Should we allow the user to configure the low and high water mark values 
> explicitly using total values (e.g. low water mark at 120MB, high water mark 
> at 140MB)?  Or shall we keep for simplicity the single setRAMBufferSizeMB() 
> config method and use something like 90% and 110% for the water marks?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: [VOTE] Lucene and Solr 3.1 release candidate

[Smiley, David W.]

So https://issues.apache.org/jira/browse/SOLR-2405 didn't make it in yesterday 
(apparently it didn't)? :-(  Darn... maybe I shouldn't have waited for a 
committer to agree with the issue. I would have had it in Saturday. 

~ David Smiley

On Mar 7, 2011, at 1:32 AM, Robert Muir wrote:

> Hi all,
> 
> I have posted a release candidate for both Lucene 3.1 and Solr 3.1,
> both from revision 1078688 of
> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_1/
> Thanks for all your help! Please test them and give your votes, the
> tentative release date for both versions is Sunday, March 13th, 2011.
> Only votes from Lucene PMC are binding, but everyone is welcome to
> check the release candidates and voice their approval or disapproval.
> The vote passes if at least three binding +1 votes are cast.
> 
> The release candidates are produced in parallel because in 2010 we
> merged the development of Lucene and Solr in order to produce higher
> quality releases. While we voted to reserve the right to release
> Lucene by itself, in my opinion we should definitely try to avoid this
> unless absolutely necessary, as it would ultimately cause more work
> and complication: instead it would be far easier to just fix whatever
> issues are discovered and respin both releases again.
> 
> Because of this, I ask that you cast a single vote to cover both
> releases. If the vote succeeds, both sets of artifacts can go their
> separate ways to the different websites.
> 
> Artifacts are located here: http://s.apache.org/solrcene31rc0
> 
> -
> 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

[Lucene.Net] ndepend license requirements - apache rules

[Michael Herndon]

Does the following violate any of the rules put forth by apache or
give anyone pause?

---


Hello

We're always happy to sponsor OSS project.
If you could put our Powered by NDepend logo on your OSS project
website we'd be happy to sponsor Apache Lucene.Net.
See the logo for example on this OSS project homepage:
http://fluentvalidation.codeplex.com/

We just need the OSS project leader name, email, postal address +
phone# to emit the license.


-

P.S. we do have a license for ncover as of yesterday =).



- Michael

[jira] Commented: (SOLR-2403) Problem with facet.sort=lex, shards, and facet.mincount

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-2403:


Hmmm, yeah.  Seems like we should use a mincount of 1 when making the shard 
requests.
For higher mincounts we can divide by the number of shards for the shard 
request mincount.
For example, if mincount=10, and we are sending to two shards, we know that at 
least one of the shards must have a count of 5 to make the final mincount cut.

> Problem with facet.sort=lex, shards, and facet.mincount
> ---
>
> Key: SOLR-2403
> URL: https://issues.apache.org/jira/browse/SOLR-2403
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 4.0
> Environment: RHEL5, Ubuntu 10.04
>Reporter: Peter Cline
>
> I tested this on a recent trunk snapshot (2/25), haven't verified with 3.1 or 
> 1.4.1.  I can if necessary and update.
> Solr is not returning the proper number of facet values when sorting 
> alphabetically, using distributed search, and using a facet.mincount that 
> excludes some of the values in the first facet.limit values.
> Easiest explained by example.  Sorting alphabetically, the first 20 values 
> for my "subject_facet" field have few documents.  19 facet values have only 1 
> document associated, and 1 has 2 documents.  There are plenty after that have 
> more than 2.
> {code}
> http://localhost:8082/solr/select?q=*:*&facet=true&facet.field=subject_facet&facet.limit=20&facet.sort=lex&facet.mincount=2
> {code}
> comes back with the expected 20 facet values with >= 2 documents associated.
> If I add a shards parameter that points back to itself, the result is 
> different.
> {code}
> http://localhost:8082/solr/select?q=*:*&facet=true&facet.field=subject_facet&facet.limit=20&facet.sort=lex&facet.mincount=2&shards=localhost:8082/solr
> {code}
> comes back with only 1 facet value: the single value in the first 20 that had 
> more than 1 document.  
> It appears to me that mincount is ignored when doing the original query to 
> the shards, then applied afterwards.
> Let me know if you need any more info.  
> Thanks,
> Peter

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Commented: (SOLR-2403) Problem with facet.sort=lex, shards, and facet.mincount

[Peter Cline (JIRA)]

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

Peter Cline commented on SOLR-2403:
---

Just to note, the reason this came up for me wasn't a mincount > 1, though that 
seemed the easiest way to show it.  A mincount = 1 with a query that doesn't 
return many results demonstrates this same problem (since lots of the first 
alpha-sorted values have count = 0).

> Problem with facet.sort=lex, shards, and facet.mincount
> ---
>
> Key: SOLR-2403
> URL: https://issues.apache.org/jira/browse/SOLR-2403
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 4.0
> Environment: RHEL5, Ubuntu 10.04
>Reporter: Peter Cline
>
> I tested this on a recent trunk snapshot (2/25), haven't verified with 3.1 or 
> 1.4.1.  I can if necessary and update.
> Solr is not returning the proper number of facet values when sorting 
> alphabetically, using distributed search, and using a facet.mincount that 
> excludes some of the values in the first facet.limit values.
> Easiest explained by example.  Sorting alphabetically, the first 20 values 
> for my "subject_facet" field have few documents.  19 facet values have only 1 
> document associated, and 1 has 2 documents.  There are plenty after that have 
> more than 2.
> {code}
> http://localhost:8082/solr/select?q=*:*&facet=true&facet.field=subject_facet&facet.limit=20&facet.sort=lex&facet.mincount=2
> {code}
> comes back with the expected 20 facet values with >= 2 documents associated.
> If I add a shards parameter that points back to itself, the result is 
> different.
> {code}
> http://localhost:8082/solr/select?q=*:*&facet=true&facet.field=subject_facet&facet.limit=20&facet.sort=lex&facet.mincount=2&shards=localhost:8082/solr
> {code}
> comes back with only 1 facet value: the single value in the first 20 that had 
> more than 1 document.  
> It appears to me that mincount is ignored when doing the original query to 
> the shards, then applied afterwards.
> Let me know if you need any more info.  
> Thanks,
> Peter

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Commented: (SOLR-2113) Create TermsQParser that deals with toInternal() conversion of external terms

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-2113:


porter stemming is not idempotent.

stem(hellosing) -> hellos
stem(stem(hellosing)) -> hello

> Create TermsQParser that deals with toInternal() conversion of external terms
> -
>
> Key: SOLR-2113
> URL: https://issues.apache.org/jira/browse/SOLR-2113
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Hoss Man
> Fix For: 4.0
>
> Attachments: SOLR-2113.patch
>
>
> For converting facet.field response constraints into filter queries, it would 
> be helpful to have a QParser that generated a TermQuery using the 
> toInternal() converted result of the raw "q" param

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: [VOTE] Lucene and Solr 3.1 release candidate

[David Smiley (@MITRE.org)]

So https://issues.apache.org/jira/browse/SOLR-2405 didn't make it in
yesterday (apparently it didn't)? :-(  Darn... maybe I shouldn't have waited
for a committer to agree with the issue. I would have had it in Saturday.

~ David Smiley

-
 Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/VOTE-Lucene-and-Solr-3-1-release-candidate-tp2645100p2646445.html
Sent from the Solr - Dev mailing list archive at Nabble.com.

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

RE: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #48: POMs out of sync

[Steven A Rowe]

Thanks Uwe!

> -Original Message-
> From: Uwe Schindler [mailto:u...@thetaphi.de]
> Sent: Monday, March 07, 2011 9:54 AM
> To: dev@lucene.apache.org
> Subject: RE: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #48: POMs out of sync
> 
> Problem solved, Jenkins was still using 3.1 instead of 3.2.
> 
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
> 
> > -Original Message-
> > From: Apache Hudson Server [mailto:hud...@hudson.apache.org]
> > Sent: Monday, March 07, 2011 12:29 PM
> > To: dev@lucene.apache.org
> > Subject: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #48: POMs out of sync
> >
> > Build: https://hudson.apache.org/hudson/job/Lucene-Solr-Maven-3.x/48/
> >
> > 1 tests failed.
> > REGRESSION:
> > org.apache.lucene.index.TestCheckIndex.testLuceneConstantVersion
> >
> > Error Message:
> > Invalid version: 3.1-SNAPSHOT
> >
> > Stack Trace:
> > java.lang.AssertionError: Invalid version: 3.1-SNAPSHOT
> > at org.junit.Assert.fail(Assert.java:91)
> > at org.junit.Assert.assertTrue(Assert.java:43)
> > at
> > org.apache.lucene.index.TestCheckIndex.testLuceneConstantVersion(TestC
> > heckIndex.java:97)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> > ava:57)
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> > sorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:616)
> > at
> > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(Framework
> > Method.java:44)
> > at
> >
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable
> .jav
> > a:15)
> > at
> > org.junit.runners.model.FrameworkMethod.invokeExplosively(Framework
> > Method.java:41)
> > at
> > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMeth
> > od.java:20)
> > at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
> > at
> >
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java
> > :28)
> > at
> >
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31
> > )
> > at
> >
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.j
> > ava:76)
> > at
> > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc
> > eneTestCase.java:1075)
> > at
> > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc
> > eneTestCase.java:1007)
> > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> > at
> > org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> > at
> > org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> > at
> > org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> > at
> >
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java
> > :28)
> > at
> >
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31
> > )
> > at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> > at
> >
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:
> > 35)
> > at
> >
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Prov
> > ider.java:146)
> > at
> >
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java
> > :97)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> > ava:57)
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> > sorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:616)
> > at
> > org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invok
> > e(ProviderFactory.java:103)
> > at $Proxy0.invoke(Unknown Source)
> > at
> >
> org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireSt
> > arter.java:145)
> > at
> >
> org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(Surefi
> > reStarter.java:87)
> > at
> > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:6
> > 9)
> >
> >
> >
> >
> > Build Log (for compile errors):
> > [...truncated 15216 lines...]
> >
> >
> >
> > -
> > 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: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #48: POMs out of sync

[Uwe Schindler]

Problem solved, Jenkins was still using 3.1 instead of 3.2.

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


> -Original Message-
> From: Apache Hudson Server [mailto:hud...@hudson.apache.org]
> Sent: Monday, March 07, 2011 12:29 PM
> To: dev@lucene.apache.org
> Subject: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #48: POMs out of sync
> 
> Build: https://hudson.apache.org/hudson/job/Lucene-Solr-Maven-3.x/48/
> 
> 1 tests failed.
> REGRESSION:
> org.apache.lucene.index.TestCheckIndex.testLuceneConstantVersion
> 
> Error Message:
> Invalid version: 3.1-SNAPSHOT
> 
> Stack Trace:
> java.lang.AssertionError: Invalid version: 3.1-SNAPSHOT
>   at org.junit.Assert.fail(Assert.java:91)
>   at org.junit.Assert.assertTrue(Assert.java:43)
>   at
> org.apache.lucene.index.TestCheckIndex.testLuceneConstantVersion(TestC
> heckIndex.java:97)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> ava:57)
>   at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:616)
>   at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(Framework
> Method.java:44)
>   at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.jav
> a:15)
>   at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(Framework
> Method.java:41)
>   at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMeth
> od.java:20)
>   at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
>   at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java
> :28)
>   at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31
> )
>   at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.j
> ava:76)
>   at
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc
> eneTestCase.java:1075)
>   at
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc
> eneTestCase.java:1007)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
>   at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
>   at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
>   at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
>   at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java
> :28)
>   at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31
> )
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
>   at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:
> 35)
>   at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Prov
> ider.java:146)
>   at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java
> :97)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> ava:57)
>   at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:616)
>   at
> org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invok
> e(ProviderFactory.java:103)
>   at $Proxy0.invoke(Unknown Source)
>   at
> org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireSt
> arter.java:145)
>   at
> org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(Surefi
> reStarter.java:87)
>   at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:6
> 9)
> 
> 
> 
> 
> Build Log (for compile errors):
> [...truncated 15216 lines...]
> 
> 
> 
> -
> 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-2113) Create TermsQParser that deals with toInternal() conversion of external terms

[Robert Muir (JIRA)]

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

Robert Muir commented on SOLR-2113:
---

the easiest example is a synonyms filter: analyze(analyze(x)) will be different 
than analyze(x)


> Create TermsQParser that deals with toInternal() conversion of external terms
> -
>
> Key: SOLR-2113
> URL: https://issues.apache.org/jira/browse/SOLR-2113
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Hoss Man
> Fix For: 4.0
>
> Attachments: SOLR-2113.patch
>
>
> For converting facet.field response constraints into filter queries, it would 
> be helpful to have a QParser that generated a TermQuery using the 
> toInternal() converted result of the raw "q" param

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: [VOTE] Lucene and Solr 3.1 release candidate

[Robert Muir]

On Mon, Mar 7, 2011 at 9:36 AM, Grant Ingersoll  wrote:
> The Solr war (apache-solr-3.1.war) file isn't signed.  Can probably do it by 
> hand.
>

Actually that war file shouldn't even be there. The problem is solr
generates some 'intermediate' stuff in dist/ (used by maven tasks),
and it got accidentally included.

we should fix the maven stuff to use build/ and not put any
intermediate stuff in dist... this is just asking for trouble like
this.

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

[jira] Commented: (SOLR-2113) Create TermsQParser that deals with toInternal() conversion of external terms

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-2113:


Sorry, I'm still confused. Can you please give a simple example as to how an 
analyzer would give different results on a subsequent invocation for the same 
input?

> Create TermsQParser that deals with toInternal() conversion of external terms
> -
>
> Key: SOLR-2113
> URL: https://issues.apache.org/jira/browse/SOLR-2113
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Hoss Man
> Fix For: 4.0
>
> Attachments: SOLR-2113.patch
>
>
> For converting facet.field response constraints into filter queries, it would 
> be helpful to have a QParser that generated a TermQuery using the 
> toInternal() converted result of the raw "q" param

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: [VOTE] Lucene and Solr 3.1 release candidate

[Grant Ingersoll]

The Solr war (apache-solr-3.1.war) file isn't signed.  Can probably do it by 
hand.


On Mar 7, 2011, at 1:32 AM, Robert Muir wrote:

> Hi all,
> 
> I have posted a release candidate for both Lucene 3.1 and Solr 3.1,
> both from revision 1078688 of
> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_1/
> Thanks for all your help! Please test them and give your votes, the
> tentative release date for both versions is Sunday, March 13th, 2011.
> Only votes from Lucene PMC are binding, but everyone is welcome to
> check the release candidates and voice their approval or disapproval.
> The vote passes if at least three binding +1 votes are cast.
> 
> The release candidates are produced in parallel because in 2010 we
> merged the development of Lucene and Solr in order to produce higher
> quality releases. While we voted to reserve the right to release
> Lucene by itself, in my opinion we should definitely try to avoid this
> unless absolutely necessary, as it would ultimately cause more work
> and complication: instead it would be far easier to just fix whatever
> issues are discovered and respin both releases again.
> 
> Because of this, I ask that you cast a single vote to cover both
> releases. If the vote succeeds, both sets of artifacts can go their
> separate ways to the different websites.
> 
> Artifacts are located here: http://s.apache.org/solrcene31rc0
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

[jira] Commented: (LUCENE-2952) Make license checking/maintenance easier/automated

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-2952:
-

+1 to hook this into our 'ant test'. This is more important than if the junit 
tests pass.


> Make license checking/maintenance easier/automated
> --
>
> Key: LUCENE-2952
> URL: https://issues.apache.org/jira/browse/LUCENE-2952
> Project: Lucene - Java
>  Issue Type: Improvement
>Reporter: Grant Ingersoll
>Priority: Minor
>
> Instead of waiting until release to check licenses are valid, we should make 
> it a part of our build process to ensure that all dependencies have proper 
> licenses, etc.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] Created: (LUCENE-2952) Make license checking/maintenance easier/automated

[Grant Ingersoll (JIRA)]

Make license checking/maintenance easier/automated
--

 Key: LUCENE-2952
 URL: https://issues.apache.org/jira/browse/LUCENE-2952
 Project: Lucene - Java
  Issue Type: Improvement
Reporter: Grant Ingersoll
Priority: Minor


Instead of waiting until release to check licenses are valid, we should make it 
a part of our build process to ensure that all dependencies have proper 
licenses, etc.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: [VOTE] Lucene and Solr 3.1 release candidate

[Robert Muir]

On Mon, Mar 7, 2011 at 8:07 AM, Grant Ingersoll  wrote:
>
> I'm fine w/ it being pushed (I was going to suggest it actually), but I guess 
> I missed the mail saying it was yesterday and thought I still might have time 
> to fix it.  What thread was that on?
>

http://www.lucidimagination.com/search/document/fced217ddd7d1769/wind_down_for_3_1

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

[jira] Updated: (LUCENE-2945) Surround Query doesn't properly handle equals/hashcode

[Grant Ingersoll (JIRA)]

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

Grant Ingersoll updated LUCENE-2945:


Affects Version/s: 3.1
Fix Version/s: (was: 3.1)
   3.1.1

> Surround Query doesn't properly handle equals/hashcode
> --
>
> Key: LUCENE-2945
> URL: https://issues.apache.org/jira/browse/LUCENE-2945
> Project: Lucene - Java
>  Issue Type: Bug
>Affects Versions: 3.0.3, 3.1, 4.0
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 3.1.1, 4.0
>
> Attachments: LUCENE-2945-partial1.patch, LUCENE-2945.patch, 
> LUCENE-2945.patch, LUCENE-2945.patch
>
>
> In looking at using the surround queries with Solr, I am hitting issues 
> caused by collisions due to equals/hashcode not being implemented on the 
> anonymous inner classes that are created by things like DistanceQuery (branch 
> 3.x, near line 76)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: [VOTE] Lucene and Solr 3.1 release candidate

[Grant Ingersoll]

On Mar 7, 2011, at 8:02 AM, Robert Muir wrote:

> On Mon, Mar 7, 2011 at 7:56 AM, Grant Ingersoll  wrote:
>> How do we have a release candidate if we still have issues open?  Or is this 
>> just a test run?
>> 
> 
> Anything in JIRA can make it in 3.2 instead. I said already, that
> yesterday was the time I had available to produce this RC build.
> 

I'm fine w/ it being pushed (I was going to suggest it actually), but I guess I 
missed the mail saying it was yesterday and thought I still might have time to 
fix it.  What thread was that on?

-Grant


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

Re: [VOTE] Lucene and Solr 3.1 release candidate

[Robert Muir]

On Mon, Mar 7, 2011 at 7:56 AM, Grant Ingersoll  wrote:
> How do we have a release candidate if we still have issues open?  Or is this 
> just a test run?
>

Anything in JIRA can make it in 3.2 instead. I said already, that
yesterday was the time I had available to produce this RC build.

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

Re: [VOTE] Lucene and Solr 3.1 release candidate

[Grant Ingersoll]

How do we have a release candidate if we still have issues open?  Or is this 
just a test run?

On Mar 7, 2011, at 1:32 AM, Robert Muir wrote:

> Hi all,
> 
> I have posted a release candidate for both Lucene 3.1 and Solr 3.1,
> both from revision 1078688 of
> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_1/
> Thanks for all your help! Please test them and give your votes, the
> tentative release date for both versions is Sunday, March 13th, 2011.
> Only votes from Lucene PMC are binding, but everyone is welcome to
> check the release candidates and voice their approval or disapproval.
> The vote passes if at least three binding +1 votes are cast.
> 
> The release candidates are produced in parallel because in 2010 we
> merged the development of Lucene and Solr in order to produce higher
> quality releases. While we voted to reserve the right to release
> Lucene by itself, in my opinion we should definitely try to avoid this
> unless absolutely necessary, as it would ultimately cause more work
> and complication: instead it would be far easier to just fix whatever
> issues are discovered and respin both releases again.
> 
> Because of this, I ask that you cast a single vote to cover both
> releases. If the vote succeeds, both sets of artifacts can go their
> separate ways to the different websites.
> 
> Artifacts are located here: http://s.apache.org/solrcene31rc0
> 
> -
> 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-2113) Create TermsQParser that deals with toInternal() conversion of external terms

[Robert Muir (JIRA)]

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

Robert Muir commented on SOLR-2113:
---

most analyzers are not idempotent.

this wouldn't be a valuable property to have (useless for a search engine).
its also not practical nor worth the trouble.

one thing to also keep in mind is that analyzers these days take Reader and 
ultimately return byte[], for example at the extreme a collation analyzer 
returns a binary sort key as a term... this isn't reversible back to a String 
at all in any way.


> Create TermsQParser that deals with toInternal() conversion of external terms
> -
>
> Key: SOLR-2113
> URL: https://issues.apache.org/jira/browse/SOLR-2113
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Hoss Man
> Fix For: 4.0
>
> Attachments: SOLR-2113.patch
>
>
> For converting facet.field response constraints into filter queries, it would 
> be helpful to have a QParser that generated a TermQuery using the 
> toInternal() converted result of the raw "q" param

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

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

[Apache Hudson Server]

Build: https://hudson.apache.org/hudson/job/Lucene-Solr-Maven-3.x/48/

1 tests failed.
REGRESSION:  org.apache.lucene.index.TestCheckIndex.testLuceneConstantVersion

Error Message:
Invalid version: 3.1-SNAPSHOT

Stack Trace:
java.lang.AssertionError: Invalid version: 3.1-SNAPSHOT
at org.junit.Assert.fail(Assert.java:91)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.lucene.index.TestCheckIndex.testLuceneConstantVersion(TestCheckIndex.java:97)
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:616)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:146)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97)
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:616)
at 
org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
at $Proxy0.invoke(Unknown Source)
at 
org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:145)
at 
org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:87)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)




Build Log (for compile errors):
[...truncated 15216 lines...]



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

[Lucene.Net] Nudge: Your Board Report Needs Content (was Re: Incubator PMC/Board report for March 2011)

[Stefan Bodewig]

On 2011-03-01, Stefan Bodewig wrote:

> this is one of the pain^H^H^H^Hjoys you've taken on yourself by entering
> the incubator 8-)

> Lucene.NET will be on a monthly schedule the first three month and then
> change to a quarterly schedule for as long as you need to graduate.

> On 2011-03-01,  wrote:

>> The board meeting is scheduled for Wed, 16 March 2011, 10 am
>> Pacific. The report for your podling will form a part of the Incubator
>> PMC report. The Incubator PMC requires your report to be submitted one
>> week before the board meeting, to allow sufficient time for review.

> This means the report has to be ready in
>  by the 9th.  Please let us
> mentors know when you deem it ready so we can review it.

Still looks empty.

Stefan

Re: [Lucene.Net] [jira] Resolved: (LUCENENET-403) Improve site layout and design

[Glyn Darkin]

The site looks great.

Well done!!!

Glyn

On 6 Mar 2011, at 23:04, Prescott Nasser (JIRA) wrote:

> 
> [ 
> https://issues.apache.org/jira/browse/LUCENENET-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>  ]
> 
> Prescott Nasser resolved LUCENENET-403.
> ---
> 
>Resolution: Fixed
> 
> Latest Layout was voted upon and selected. Images were updated by Mike and 
> I've moved it to staging: 
> http://lucene.net.staging.apache.org/lucene.net/index.html.
> 
>> Improve site layout and design
>> --
>> 
>>Key: LUCENENET-403
>>URL: https://issues.apache.org/jira/browse/LUCENENET-403
>>Project: Lucene.Net
>> Issue Type: Sub-task
>> Components: Project Infrastructure
>>   Reporter: Troy Howard
>>   Assignee: Prescott Nasser
>>Fix For: Lucene.Net 2.9.2
>> 
>>Attachments: layout1.zip, layout2.zip
>> 
>> 
>> Improve the website layout and design. Current staging design is based off 
>> an extremely simplistic implementation of Apache CMS basic template using 
>> the default Apache CMS CSS styling. Let's try to make it look better and 
>> have a more intuitive navigational structure.
>> See staging site at:
>> http://lucene.net.staging.apache.org/lucene.net/
>> To edit content, please use:
>> https://cms.apache.org/lucene.net/
> 
> --
> This message is automatically generated by JIRA.
> For more information on JIRA, see: http://www.atlassian.com/software/jira

Glyn Darkin

Darkin Systems Ltd
Mob: 07961815649
Fax: 08717145065
Web: www.darkinsystems.com

Company No: 6173001
VAT No: 906350835

RE: [HUDSON] Solr-3.x - Build # 282 - Still Failing

[Uwe Schindler]

That was me!

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

> -Original Message-
> From: Apache Hudson Server [mailto:hud...@hudson.apache.org]
> Sent: Monday, March 07, 2011 9:02 AM
> To: dev@lucene.apache.org
> Subject: [HUDSON] Solr-3.x - Build # 282 - Still Failing
> 
> Build: https://hudson.apache.org/hudson/job/Solr-3.x/282/
> 
> No tests ran.
> 
> Build Log (for compile errors):
> [...truncated 366 lines...]
> 
> 
> 
> -
> 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

[HUDSON] Solr-3.x - Build # 282 - Still Failing

[Apache Hudson Server]

Build: https://hudson.apache.org/hudson/job/Solr-3.x/282/

No tests ran.

Build Log (for compile errors):
[...truncated 366 lines...]



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