date:20101126

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

3 tests failed.
REGRESSION:  org.apache.solr.schema.TestBinaryField.testSimple

Error Message:
Severe errors in solr configuration.  Check your log files for more detailed 
information on what may be wrong.  
- 
org.apache.solr.common.cloud.ZooKeeperException: Config file contains no 
data:/configs/conf1/solrconfig.xml  at 
org.apache.solr.cloud.ZkController.getConfigFileData(ZkController.java:219)  at 
org.apache.solr.core.CoreContainer.getSolrConfigFromZk(CoreContainer.java:1035) 
 at org.apache.solr.core.CoreContainer.create(CoreContainer.java:598)  at 
org.apache.solr.core.CoreContainer.load(CoreContainer.java:412)  at 
org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:246)
  at 
org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:86)  at 
org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)  at 
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)  at 
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:662)  
at 
org.mortbay.jetty.servlet.ServletHandler.updateMappings(ServletHandler.java:1053)
  at 
org.mortbay.jetty.servlet.ServletHandler.setFilterMappings(ServletHandler.java:1089)
  at 
org.mortbay.jetty.servlet.ServletHandler.addFilterWithMapping(ServletHandler.java:889)
  at 
org.mortbay.jetty.servlet.ServletHandler.addFilterWithMapping(ServletHandler.java:844)
  at org.mortbay.jetty.servlet.Context.addFilter(Context.java:207)  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$1.lifeCycleStarted(JettySolrRunner.java:97)
  at 
org.mortbay.component.AbstractLifeCycle.setStarted(AbstractLifeCycle.java:140)  
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:52)  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:122)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:117)
  at org.apache.solr.schema.TestBinaryField.setUp(TestBinaryField.java:71)  at 
sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)  at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe  Severe errors in 
solr configuration.  Check your log files for more detailed information on what 
may be wrong.  - 
org.apache.solr.common.cloud.ZooKeeperException: Config file contains no 
data:/configs/conf1/solrconfig.xml  at 
org.apache.solr.cloud.ZkController.getConfigFileData(ZkController.java:219)  at 
org.apache.solr.core.CoreContainer.getSolrConfigFromZk(CoreContainer.java:1035) 
 at org.apache.solr.core.CoreContainer.create(CoreContainer.java:598)  at 
org.apache.solr.core.CoreContainer.load(CoreContainer.java:412)  at 
org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:246)
  at 
org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:86)  at 
org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)  at 
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)  at 
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:662)  
at 
org.mortbay.jetty.servlet.ServletHandler.updateMappings(ServletHandler.java:1053)
  at 
org.mortbay.jetty.servlet.ServletHandler.setFilterMappings(ServletHandler.java:1089)
  at 
org.mortbay.jetty.servlet.ServletHandler.addFilterWithMapping(ServletHandler.java:889)
  at 
org.mortbay.jetty.servlet.ServletHandler.addFilterWithMapping(ServletHandler.java:844)
  at org.mortbay.jetty.servlet.Context.addFilter(Context.java:207)  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$1.lifeCycleStarted(JettySolrRunner.java:97)
  at 
org.mortbay.component.AbstractLifeCycle.setStarted(AbstractLifeCycle.java:140)  
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:52)  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:122)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:117)
  at org.apache.solr.schema.TestBinaryField.setUp(TestBinaryField.java:71)  at 
sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)  at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe  request: 
http://localhost:32777/example/update?wt=javabinversion=2

Stack Trace:


request: http://localhost:32777/example/update?wt=javabinversion=2
at 
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:435)
at 
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:244)
at 
org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:105)
at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:65)
at 
org.apache.solr.schema.TestBinaryField.testSimple(TestBinaryField.java:87)
at

Lucene-Solr-tests-only-trunk - Build # 1870 - Still Failing

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

1 tests failed.
REGRESSION:  org.apache.solr.TestDistributedSearch.testDistribSearch

Error Message:
Some threads threw uncaught exceptions!

Stack Trace:
junit.framework.AssertionFailedError: Some threads threw uncaught exceptions!
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:950)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:888)
at 
org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:473)
at org.apache.solr.SolrTestCaseJ4.tearDown(SolrTestCaseJ4.java:92)
at 
org.apache.solr.BaseDistributedSearchTestCase.tearDown(BaseDistributedSearchTestCase.java:144)




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



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

[jira] Commented: (LUCENE-2348) DuplicateFilter incorrectly handles multiple calls to getDocIdSet for segment readers

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

Michael McCandless commented on LUCENE-2348:

bq. if its not doing the work in getdocidset, it shouldn't extend Filter!

I don't think we can or should dictate that.

I think it's fair game for a Filter to compute/cache whatever it
wants. The only requirement for Filter is that it implement
getDocIdSet. Where it does its work, what it's storing in its
instance, etc., is up to it.

Sure, we strive for a strong separation of computing the bits vs
caching them, but for some cases that ideal is not feasible.

In fact in this case the filter is so costly to build that no
realistic app can possibly rely on the filter without first wrapping
it in CachingWrapperFilter. So I see no harm in conflating caching
with this. We could rename it to CachingDuplicateFilter. In fact we
could factor out the FilterCache utility class now inside
CachingWrapperFilter and make it easily reused by other filters like
this one that need to compute cache right off.

This would also be cleaner if we change the filter API so getDocIdSet
receives the top reader and docBase in addition to the sub; this way a
CachingDuplicateFilter instance could be reused across reopened top
readers.

{quote}
If someone wants to make a DuplicateBitSetBuilder that is a factory for
creating a BitSet,
to me that is more natural and obvious as to what is going on.
{quote}

That sounds good... but how would it work? Ie how would an app tie
that into a Filter?

DuplicateFilter incorrectly handles multiple calls to getDocIdSet for segment
readers
-

Key: LUCENE-2348
URL: https://issues.apache.org/jira/browse/LUCENE-2348
Project: Lucene - Java
Issue Type: Bug
Components: contrib/*
Affects Versions: 2.9.2
Reporter: Trejkaz
Attachments: LUCENE-2348.patch, LUCENE-2348.patch

DuplicateFilter currently works by building a single doc ID set, without
taking into account that getDocIdSet() will be called once per segment and
only with each segment's local reader.

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

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

[jira] Commented: (LUCENE-2780) optimize spantermquery

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

Michael McCandless commented on LUCENE-2780:

Looks good Robert! It's a sneaky trap. Maybe add a comment to createWeight
explaining that this is only used when a normal (non-span) Query embeds a
SpanTermQuery?

Someday we need to merge Span* back into the normal queries.

optimize spantermquery
--

Key: LUCENE-2780
URL: https://issues.apache.org/jira/browse/LUCENE-2780
Project: Lucene - Java
Issue Type: Improvement
Components: Search
Reporter: Robert Muir
Fix For: 3.1, 4.0

Attachments: LUCENE-2780.patch

Looking at
http://www.lucidimagination.com/search/document/c2c6f660ddde4f7f/dismaxqparserplugin_and_tokenization
,
I saw a user building DisjunctionMaxQuery / BooleanQuery with SpanTermQuerys.
I wonder if users know that doing this is much slower than just using
TermQuery?
I agree it makes little sense to use SpanTermQuery if you arent going to use
it inside a SpanNear etc,
but on the other hand, I think its a little non-intuitive that it wouldnt be
just as fast in a case like this.
I could see this complicating queryparsing etc for users that want to
sometimes use positions etc.
SpanTermQuery is the same as TermQuery, except tf is computed as (#of spans *
sloppyFreq(spanLength)
For this case, #ofspans = tf and spanLength for a single term is always 1.
Maybe we should optimize SpanTermQuery to return TermScorer, with just this
special tf computation.
This would avoid reading positions for anyone that does this.

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

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

[jira] Commented: (LUCENE-2506) A Stateful Filter That Works Across Index Segments

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

Michael McCandless commented on LUCENE-2506:

bq. That assumption's gonna break very soon. Very very soon, when IndexWriter
learns how to merge non-sequential segments.

Even if we break this assumption on the ootb config we will still have
to provide a way to get it back. EG in this case, a merge policy
which only selects contiguous segments (like the LogMergePolicy
today).

A Stateful Filter That Works Across Index Segments
--

Key: LUCENE-2506
URL: https://issues.apache.org/jira/browse/LUCENE-2506
Project: Lucene - Java
Issue Type: Improvement
Components: Index
Affects Versions: 3.0.2
Reporter: Karthick Sankarachary
Attachments: LUCENE-2506.patch

By design, Lucene's Filter abstraction is applied once for every segment in
the index during searching. In particular, the reader provided to its
#getDocIdSet method does not represent the whole underlying index. In other
words, if the index has more than one segment the given reader only
represents a single segment. As a result, that definition of the filter
suffers the limitation of not having the ability to permit/prohibit documents
in the search results based on the terms that reside in segments that precede
the current one.
To address this limitation, we introduce here a StatefulFilter which
specifically builds on the Filter class so as to make it capable of
remembering terms in segments spanning the whole underlying index. To
reiterate, the need for making filters stateful stems from the fact that
some, although not most, filters care about the terms that they may have come
across in prior segments. It does so by keeping track of the past terms from
prior segments in a cache that is maintained in a StatefulTermsEnum instance
on a per-thread basis.
Additionally, to address the case where a filter might want to accept the
last matching term, we keep track of the TermsEnum#docFreq of the terms in
the segments filtered thus far. By comparing the sum of such
TermsEnum#docFreq with that of the top-level reader, we can tell if the
current segment is the last segment in which the current term appears.
Ideally, for this to work correctly, we require the user to explicitly set
the top-level reader on the StatefulFilter. Knowing what the top-level reader
is also helps the StatefulFilter to clean up after itself once the search has
concluded.
Note that we leave it up to each concrete sub-class of the stateful filter to
decide what to remember in its state and what not to. In other words, it can
choose to remember as much or as little from prior segments as it deems
necessary. In keeping with the TermsEnum interface, which the
StatefulTermsEnum class extends, the filter must decide which terms to accept
or not, based on the holistic state of the search.

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

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

[jira] Commented: (LUCENE-2186) First cut at column-stride fields (index values storage)


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

Michael McCandless commented on LUCENE-2186:


bq. BTW. it is ok to have the same name as a existing field.

It is, usually... but we should add a test to assert this is still the
case for other field + ValuesField?

{quote}
bq. I'm thinking it's really important now to carry over the same FieldInfos 
from the last segment when opening the writer (LUCENE-1737)... because hitting 
that IllegalStateExc during merge is a trap.

I think that should not block us from moving forward and landing on trunk ey?
{quote}

It makes me mighty nervous though... I'll try to get that issue done
soon.

{quote}
Well it is a nice way of extending field but I am not sure if we
should keep it since it is heavy weight. 
{quote}

The ValuesAttr for ValuesField is actually really heavyweight.  Not
only must it fire up an AttrSource, but then ValuesAttrImpl itself has
a field for each type.  Worse, for the type you do actually use, it's
then another object eg FloatsRef, which in turn holds
array/offset/len, a new length 1 array, etc.

Maybe we shouldn't use attrs here?  And instead somehow let
ValuesField store a single value as it's own private member?

FloatsRef, LongsRef are missing the ASL header.  Maybe it's time to
run RAT :)


 First cut at column-stride fields (index values storage)
 

 Key: LUCENE-2186
 URL: https://issues.apache.org/jira/browse/LUCENE-2186
 Project: Lucene - Java
  Issue Type: New Feature
  Components: Index
Reporter: Michael McCandless
Assignee: Simon Willnauer
 Fix For: CSF branch, 4.0

 Attachments: LUCENE-2186.patch, LUCENE-2186.patch, LUCENE-2186.patch, 
 LUCENE-2186.patch, LUCENE-2186.patch, mem.py


 I created an initial basic impl for storing index values (ie
 column-stride value storage).  This is still a work in progress... but
 the approach looks compelling.  I'm posting my current status/patch
 here to get feedback/iterate, etc.
 The code is standalone now, and lives under new package
 oal.index.values (plus some util changes, refactorings) -- I have yet
 to integrate into Lucene so eg you can mark that a given Field's value
 should be stored into the index values, sorting will use these values
 instead of field cache, etc.
 It handles 3 types of values:
   * Six variants of byte[] per doc, all combinations of fixed vs
 variable length, and stored either straight (good for eg a
 title field), deref (good when many docs share the same value,
 but you won't do any sorting) or sorted.
   * Integers (variable bit precision used as necessary, ie this can
 store byte/short/int/long, and all precisions in between)
   * Floats (4 or 8 byte precision)
 String fields are stored as the UTF8 byte[].  This patch adds a
 BytesRef, which does the same thing as flex's TermRef (we should merge
 them).
 This patch also adds basic initial impl of PackedInts (LUCENE-1990);
 we can swap that out if/when we get a better impl.
 This storage is dense (like field cache), so it's appropriate when the
 field occurs in all/most docs.  It's just like field cache, except the
 reading API is a get() method invocation, per document.
 Next step is to do basic integration with Lucene, and then compare
 sort performance of this vs field cache.
 For the sort by String value case, I think RAM usage  GC load of
 this index values API should be much better than field caache, since
 it does not create object per document (instead shares big long[] and
 byte[] across all docs), and because the values are stored in RAM as
 their UTF8 bytes.
 There are abstract Writer/Reader classes.  The current reader impls
 are entirely RAM resident (like field cache), but the API is (I think)
 agnostic, ie, one could make an MMAP impl instead.
 I think this is the first baby step towards LUCENE-1231.  Ie, it
 cannot yet update values, and the reading API is fully random-access
 by docID (like field cache), not like a posting list, though I
 do think we should add an iterator() api (to return flex's DocsEnum)
 -- eg I think this would be a good way to track avg doc/field length
 for BM25/lnu.ltc scoring.

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


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

[jira] Resolved: (LUCENE-2776) indexwriter creates unwanted termvector info


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

Michael McCandless resolved LUCENE-2776.


Resolution: Fixed

 indexwriter creates unwanted termvector info
 

 Key: LUCENE-2776
 URL: https://issues.apache.org/jira/browse/LUCENE-2776
 Project: Lucene - Java
  Issue Type: Bug
  Components: Index
Affects Versions: 3.0.3
Reporter: Yonik Seeley
Assignee: Michael McCandless
 Fix For: 2.9.4, 3.0.3, 3.1, 4.0

 Attachments: TestWriter.java


 I noticed today that when I build a big index in Solr, I get some unwanted 
 termvector info, even though I didn't request any.
 This does not happen on 3x - not sure when it started happening on trunk.

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


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

[jira] Commented: (LUCENE-2186) First cut at column-stride fields (index values storage)


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

Simon Willnauer commented on LUCENE-2186:
-

{quote}
It is, usually... but we should add a test to assert this is still the
case for other field + ValuesField?
{quote}

I already implemented a simple testcase that shows that this works as an 
example (I will commit that soon though) but I think we need to add another 
test that ensures that this works with all types of DocValues though. Yet, I 
work on making the test more atomic and test only a single thing anyway so i 
will add that too.

bq. It makes me mighty nervous though... I'll try to get that issue done soon.
Well until then I just go on and get the remaining stuff done here.


bq. Maybe we shouldn't use attrs here? And instead somehow let ValuesField 
store a single value as it's own private member?
I more and more think we can nuke ValuesAttribute completely since its other 
purpose on ValuesEnum is somewhat obsolete too. It is actually a leftover from 
earlier days where I was experimenting with using DocEnum to serve CSF too. 
There it would have made sense though but now we can provide a dedicated API. 
It still bugs me that Field is so hard to extend. We really need to fix that 
soon!

I think what we should do is extend AbstractField and simply use a 
long/double/BytesRef and force folks to add another field instance if they want 
to have it indexed and stored.
bq. Maybe it's time to run RAT
+1 :)



 First cut at column-stride fields (index values storage)
 

 Key: LUCENE-2186
 URL: https://issues.apache.org/jira/browse/LUCENE-2186
 Project: Lucene - Java
  Issue Type: New Feature
  Components: Index
Reporter: Michael McCandless
Assignee: Simon Willnauer
 Fix For: CSF branch, 4.0

 Attachments: LUCENE-2186.patch, LUCENE-2186.patch, LUCENE-2186.patch, 
 LUCENE-2186.patch, LUCENE-2186.patch, mem.py


 I created an initial basic impl for storing index values (ie
 column-stride value storage).  This is still a work in progress... but
 the approach looks compelling.  I'm posting my current status/patch
 here to get feedback/iterate, etc.
 The code is standalone now, and lives under new package
 oal.index.values (plus some util changes, refactorings) -- I have yet
 to integrate into Lucene so eg you can mark that a given Field's value
 should be stored into the index values, sorting will use these values
 instead of field cache, etc.
 It handles 3 types of values:
   * Six variants of byte[] per doc, all combinations of fixed vs
 variable length, and stored either straight (good for eg a
 title field), deref (good when many docs share the same value,
 but you won't do any sorting) or sorted.
   * Integers (variable bit precision used as necessary, ie this can
 store byte/short/int/long, and all precisions in between)
   * Floats (4 or 8 byte precision)
 String fields are stored as the UTF8 byte[].  This patch adds a
 BytesRef, which does the same thing as flex's TermRef (we should merge
 them).
 This patch also adds basic initial impl of PackedInts (LUCENE-1990);
 we can swap that out if/when we get a better impl.
 This storage is dense (like field cache), so it's appropriate when the
 field occurs in all/most docs.  It's just like field cache, except the
 reading API is a get() method invocation, per document.
 Next step is to do basic integration with Lucene, and then compare
 sort performance of this vs field cache.
 For the sort by String value case, I think RAM usage  GC load of
 this index values API should be much better than field caache, since
 it does not create object per document (instead shares big long[] and
 byte[] across all docs), and because the values are stored in RAM as
 their UTF8 bytes.
 There are abstract Writer/Reader classes.  The current reader impls
 are entirely RAM resident (like field cache), but the API is (I think)
 agnostic, ie, one could make an MMAP impl instead.
 I think this is the first baby step towards LUCENE-1231.  Ie, it
 cannot yet update values, and the reading API is fully random-access
 by docID (like field cache), not like a posting list, though I
 do think we should add an iterator() api (to return flex's DocsEnum)
 -- eg I think this would be a good way to track avg doc/field length
 for BM25/lnu.ltc scoring.

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


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

[jira] Updated: (LUCENE-2781) Drop deprecations from trunk

2010-11-26 Thread Earwin Burrfoot (JIRA)


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

Earwin Burrfoot updated LUCENE-2781:


Attachment: drop-deprecations.patch

Stab one.

Everything works, except Solr - this fails to compile, and a couple of tests 
that are commented-out and marked nocommit - these should be converted from 
DateField to DateUtil or dropped.


 Drop deprecations from trunk
 

 Key: LUCENE-2781
 URL: https://issues.apache.org/jira/browse/LUCENE-2781
 Project: Lucene - Java
  Issue Type: Task
Affects Versions: 4.0
Reporter: Earwin Burrfoot
Priority: Minor
 Attachments: drop-deprecations.patch


 subj.
 Also, to each remaining deprecation add release version when it first 
 appeared.
 Patch incoming.

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


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

[jira] Updated: (LUCENE-2777) Revise PagedBytes#fillUsingLengthPrefix* methods names


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

Simon Willnauer updated LUCENE-2777:


Attachment: LUCENE-2777.patch

here is a patch that renames the methods. I used fill, fillSlice, 
fillAndGetIndex, and fillAndGetNext
I also added javadoc that some of those methods don't support slices spanning 
across blocks.

 Revise PagedBytes#fillUsingLengthPrefix* methods names
 --

 Key: LUCENE-2777
 URL: https://issues.apache.org/jira/browse/LUCENE-2777
 Project: Lucene - Java
  Issue Type: Task
Affects Versions: CSF branch, 4.0
Reporter: Simon Willnauer
Assignee: Simon Willnauer
Priority: Minor
 Attachments: LUCENE-2777.patch


 PagedBytes has 3 different variants of fillUsingLengthPrefix. We need better 
 names for that since CSFBranch already added a 4th one.
 here are some suggestions:
 {code}
 /** Reads length as 1 or 2 byte vInt prefix, starting @ start */
 public BytesRef fillLengthAndOffset(BytesRef b, long start) 
 //was: public BytesRef fillUsingLengthPrefix(BytesRef b, long start) 
  /** @lucene.internal  Reads length as 1 or 2 byte vInt prefix, starting @ 
 start.  Returns the block number of the term. */
 public int getBlockAndFill(BytesRef b, long start) 
 //was: public BytesRef fillUsingLengthPrefix2(BytesRef b, long start) 
 /** @lucene.internal  Reads length as 1 or 2 byte vInt prefix, starting @ 
 start. 
  * Returns the start offset of the next part, suitable as start parameter 
 on next call
  * to sequentially read all BytesRefs. */
 public long getNextOffsetAndFill(BytesRef b, long start) 
 //was: public BytesRef fillUsingLengthPrefix3(BytesRef b, long start) 
 {code}

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


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

[jira] Commented: (LUCENE-2777) Revise PagedBytes#fillUsingLengthPrefix* methods names


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

Michael McCandless commented on LUCENE-2777:


Looks good Simon!

 Revise PagedBytes#fillUsingLengthPrefix* methods names
 --

 Key: LUCENE-2777
 URL: https://issues.apache.org/jira/browse/LUCENE-2777
 Project: Lucene - Java
  Issue Type: Task
Affects Versions: CSF branch, 4.0
Reporter: Simon Willnauer
Assignee: Simon Willnauer
Priority: Minor
 Attachments: LUCENE-2777.patch


 PagedBytes has 3 different variants of fillUsingLengthPrefix. We need better 
 names for that since CSFBranch already added a 4th one.
 here are some suggestions:
 {code}
 /** Reads length as 1 or 2 byte vInt prefix, starting @ start */
 public BytesRef fillLengthAndOffset(BytesRef b, long start) 
 //was: public BytesRef fillUsingLengthPrefix(BytesRef b, long start) 
  /** @lucene.internal  Reads length as 1 or 2 byte vInt prefix, starting @ 
 start.  Returns the block number of the term. */
 public int getBlockAndFill(BytesRef b, long start) 
 //was: public BytesRef fillUsingLengthPrefix2(BytesRef b, long start) 
 /** @lucene.internal  Reads length as 1 or 2 byte vInt prefix, starting @ 
 start. 
  * Returns the start offset of the next part, suitable as start parameter 
 on next call
  * to sequentially read all BytesRefs. */
 public long getNextOffsetAndFill(BytesRef b, long start) 
 //was: public BytesRef fillUsingLengthPrefix3(BytesRef b, long start) 
 {code}

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


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

[jira] Resolved: (LUCENE-2777) Revise PagedBytes#fillUsingLengthPrefix* methods names


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

Simon Willnauer resolved LUCENE-2777.
-

   Resolution: Fixed
Fix Version/s: 4.0

Committed in revision: 1039382

 Revise PagedBytes#fillUsingLengthPrefix* methods names
 --

 Key: LUCENE-2777
 URL: https://issues.apache.org/jira/browse/LUCENE-2777
 Project: Lucene - Java
  Issue Type: Task
Affects Versions: CSF branch, 4.0
Reporter: Simon Willnauer
Assignee: Simon Willnauer
Priority: Minor
 Fix For: 4.0

 Attachments: LUCENE-2777.patch


 PagedBytes has 3 different variants of fillUsingLengthPrefix. We need better 
 names for that since CSFBranch already added a 4th one.
 here are some suggestions:
 {code}
 /** Reads length as 1 or 2 byte vInt prefix, starting @ start */
 public BytesRef fillLengthAndOffset(BytesRef b, long start) 
 //was: public BytesRef fillUsingLengthPrefix(BytesRef b, long start) 
  /** @lucene.internal  Reads length as 1 or 2 byte vInt prefix, starting @ 
 start.  Returns the block number of the term. */
 public int getBlockAndFill(BytesRef b, long start) 
 //was: public BytesRef fillUsingLengthPrefix2(BytesRef b, long start) 
 /** @lucene.internal  Reads length as 1 or 2 byte vInt prefix, starting @ 
 start. 
  * Returns the start offset of the next part, suitable as start parameter 
 on next call
  * to sequentially read all BytesRefs. */
 public long getNextOffsetAndFill(BytesRef b, long start) 
 //was: public BytesRef fillUsingLengthPrefix3(BytesRef b, long start) 
 {code}

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


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

[jira] Created: (SOLR-2254) geodist() sort does not work if sfield parameter is enclosed in LocalParams

2010-11-26 Thread Julien Lirochon (JIRA)

geodist() sort does not work if sfield parameter is enclosed in LocalParams
---

 Key: SOLR-2254
 URL: https://issues.apache.org/jira/browse/SOLR-2254
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Julien Lirochon
Priority: Minor


taking the example from the page : http://wiki.apache.org/solr/SpatialSearch

1) ...q=*:*fq={!geofilt sfield=store}pt=45.15,-93.85d=5
2) ...q=*:*fq={!geofilt}sfield=storept=45.15,-93.85d=5

if you choose the 1st syntax, you can't sort by geodist()

Although it might not be a bug, this behavior is not documented.

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


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

[jira] Commented: (SOLR-2254) geodist() sort does not work if sfield parameter is enclosed in LocalParams

2010-11-26 Thread Yonik Seeley (JIRA)


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

Yonik Seeley commented on SOLR-2254:


This isn't really specific to geosearch.
local params are local (they aren't going to be shared across query parsers).

The geodist function can take it's own arguments instead of relying on the 
global ones (i.e. geodist(10,20,sfield))
I'll try and clarify in the docs.

 geodist() sort does not work if sfield parameter is enclosed in LocalParams
 ---

 Key: SOLR-2254
 URL: https://issues.apache.org/jira/browse/SOLR-2254
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Julien Lirochon
Priority: Minor

 taking the example from the page : http://wiki.apache.org/solr/SpatialSearch
 1) ...q=*:*fq={!geofilt sfield=store}pt=45.15,-93.85d=5
 2) ...q=*:*fq={!geofilt}sfield=storept=45.15,-93.85d=5
 if you choose the 1st syntax, you can't sort by geodist()
 Although it might not be a bug, this behavior is not documented.

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


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

[jira] Resolved: (SOLR-2254) geodist() sort does not work if sfield parameter is enclosed in LocalParams

2010-11-26 Thread Yonik Seeley (JIRA)


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

Yonik Seeley resolved SOLR-2254.


Resolution: Not A Problem

 geodist() sort does not work if sfield parameter is enclosed in LocalParams
 ---

 Key: SOLR-2254
 URL: https://issues.apache.org/jira/browse/SOLR-2254
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Julien Lirochon
Priority: Minor

 taking the example from the page : http://wiki.apache.org/solr/SpatialSearch
 1) ...q=*:*fq={!geofilt sfield=store}pt=45.15,-93.85d=5
 2) ...q=*:*fq={!geofilt}sfield=storept=45.15,-93.85d=5
 if you choose the 1st syntax, you can't sort by geodist()
 Although it might not be a bug, this behavior is not documented.

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


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

[jira] Commented: (SOLR-2254) geodist() sort does not work if sfield parameter is enclosed in LocalParams

2010-11-26 Thread Julien Lirochon (JIRA)


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

Julien Lirochon commented on SOLR-2254:
---

Yes it really makes sense, and works as expected

Thanks for the doc, I suggest you add some example calls for geodist() with 
parameters

 geodist() sort does not work if sfield parameter is enclosed in LocalParams
 ---

 Key: SOLR-2254
 URL: https://issues.apache.org/jira/browse/SOLR-2254
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Julien Lirochon
Priority: Minor

 taking the example from the page : http://wiki.apache.org/solr/SpatialSearch
 1) ...q=*:*fq={!geofilt sfield=store}pt=45.15,-93.85d=5
 2) ...q=*:*fq={!geofilt}sfield=storept=45.15,-93.85d=5
 if you choose the 1st syntax, you can't sort by geodist()
 Although it might not be a bug, this behavior is not documented.

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


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

[jira] Commented: (LUCENE-2778) Allow easy extension of RAMDirectory

2010-11-26 Thread Yonik Seeley (JIRA)

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

Yonik Seeley commented on LUCENE-2778:
--

Why was this committed to 3x and then merged to trunk?
Could we try to not merge to trunk and instead merge to 3x? We're destroying
the usefulness of our history.
I thought Tokenizer just changed in trunk... I went to look at the history and
the last 17 revisions are all identical (except for mergeprops I assume). And
I can't tell at a glance what are real vs fake changes in the history.

Allow easy extension of RAMDirectory

Key: LUCENE-2778
URL: https://issues.apache.org/jira/browse/LUCENE-2778
Project: Lucene - Java
Issue Type: Improvement
Components: Store
Reporter: Shai Erera
Assignee: Shai Erera
Priority: Minor
Fix For: 3.1, 4.0

Attachments: LUCENE-2778.patch

RAMDirectory uses RAMFiles to store the data. RAMFile offers a newBuffer()
method for extensions to override and allocate buffers differently, from e.g.
a pool or something. However, RAMDirectory always allocates RAMFile and
doesn't allow allocating a RAMFile extension, which makes RAMFile.newBuffer()
unusable.
I think we can simply introduce a newRAMFile() method on RAMDirectory and
make the RAMFiles map protected, and it will allow really extending RAMDir.
I will post a patch later.

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

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

[jira] Commented: (LUCENE-2778) Allow easy extension of RAMDirectory


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

Simon Willnauer commented on LUCENE-2778:
-

bq. Looks Good To Me I believe .
correct!

 Allow easy extension of RAMDirectory
 

 Key: LUCENE-2778
 URL: https://issues.apache.org/jira/browse/LUCENE-2778
 Project: Lucene - Java
  Issue Type: Improvement
  Components: Store
Reporter: Shai Erera
Assignee: Shai Erera
Priority: Minor
 Fix For: 3.1, 4.0

 Attachments: LUCENE-2778.patch


 RAMDirectory uses RAMFiles to store the data. RAMFile offers a newBuffer() 
 method for extensions to override and allocate buffers differently, from e.g. 
 a pool or something. However, RAMDirectory always allocates RAMFile and 
 doesn't allow allocating a RAMFile extension, which makes RAMFile.newBuffer() 
 unusable.
 I think we can simply introduce a newRAMFile() method on RAMDirectory and 
 make the RAMFiles map protected, and it will allow really extending RAMDir.
 I will post a patch later.

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


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

[jira] Created: (SOLR-2255) local params are not parsed in facet.pivot parameter

2010-11-26 Thread Julien Lirochon (JIRA)

local params are not parsed in facet.pivot parameter


 Key: SOLR-2255
 URL: https://issues.apache.org/jira/browse/SOLR-2255
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Julien Lirochon


...facet=truefacet.pivot={!ex=category}category_id,subcategory_idfq={!tag=category}category_id=42

generates the following error : undefined field {!ex=category}category_id

If you filter on subcategory_id, the facet.pivot result will contain only 
results from this subcategory. It's a loss of function since you can't alter 
this behavior with local params.

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


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

Newbie question on distributed writes onto SolrCloud

2010-11-26 Thread Manuel Gonzalo

Hi all,

while investigating SolrCloud for our distributed search needs  I can't seem to 
find the means to perform distributed writes/updates ... Distributed access to 
data is available but from what I understood each node has to be accessed 
independently in order to write/update a value.

Is this so or am I missing something?

Thanks in advance,


Manuel Gonzalo
Software Engineer

http://recommender.strands.com





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

Lucene-Solr-tests-only-trunk - Build # 1889 - Failure

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

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

Error Message:
KeeperErrorCode = ConnectionLoss for /configs

Stack Trace:
org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = 
ConnectionLoss for /configs
at org.apache.zookeeper.KeeperException.create(KeeperException.java:90)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:42)
at org.apache.zookeeper.ZooKeeper.create(ZooKeeper.java:637)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:348)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:309)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:291)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:256)
at 
org.apache.solr.common.cloud.SolrZkClient.setData(SolrZkClient.java:385)
at 
org.apache.solr.common.cloud.SolrZkClient.setData(SolrZkClient.java:411)
at 
org.apache.solr.cloud.AbstractZkTestCase.putConfig(AbstractZkTestCase.java:97)
at 
org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:84)
at 
org.apache.solr.cloud.AbstractDistributedZkTestCase.setUp(AbstractDistributedZkTestCase.java:47)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:950)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:888)


FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.BasicZkTest

Error Message:
org.apache.solr.common.cloud.ZooKeeperException: 

Stack Trace:
java.lang.RuntimeException: org.apache.solr.common.cloud.ZooKeeperException: 
at org.apache.solr.util.TestHarness.init(TestHarness.java:152)
at org.apache.solr.util.TestHarness.init(TestHarness.java:134)
at org.apache.solr.util.TestHarness.init(TestHarness.java:124)
at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:247)
at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:110)
at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:98)
at 
org.apache.solr.cloud.AbstractZkTestCase.azt_beforeClass(AbstractZkTestCase.java:64)
Caused by: org.apache.solr.common.cloud.ZooKeeperException: 
at org.apache.solr.core.CoreContainer.register(CoreContainer.java:530)
at 
org.apache.solr.util.TestHarness$Initializer.initialize(TestHarness.java:191)
at org.apache.solr.util.TestHarness.init(TestHarness.java:139)
Caused by: org.apache.zookeeper.KeeperException$ConnectionLossException: 
KeeperErrorCode = ConnectionLoss for /collections
at org.apache.zookeeper.KeeperException.create(KeeperException.java:90)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:42)
at org.apache.zookeeper.ZooKeeper.setData(ZooKeeper.java:1038)
at 
org.apache.solr.common.cloud.SolrZkClient.setData(SolrZkClient.java:225)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:355)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:309)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:291)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:256)
at 
org.apache.solr.common.cloud.SolrZkClient.setData(SolrZkClient.java:385)
at org.apache.solr.cloud.ZkController.register(ZkController.java:486)
at org.apache.solr.core.CoreContainer.register(CoreContainer.java:521)


FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.BasicZkTest

Error Message:
ERROR: SolrIndexSearcher opens=1 closes=0

Stack Trace:
junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=1 closes=0
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:128)
at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:302)
at 
org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:79)


REGRESSION:  org.apache.solr.cloud.CloudStateUpdateTest.testCoreRegistration

Error Message:
null

Stack Trace:
org.apache.solr.common.cloud.ZooKeeperException: 
at org.apache.solr.cloud.ZkController.init(ZkController.java:280)
at org.apache.solr.cloud.ZkController.init(ZkController.java:133)
at 
org.apache.solr.core.CoreContainer.initZooKeeper(CoreContainer.java:159)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:338)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:294)
at 
org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:243)
at 
org.apache.solr.cloud.CloudStateUpdateTest.testCoreRegistration(CloudStateUpdateTest.java:216)
at

Re: Newbie question on distributed writes onto SolrCloud

2010-11-26 Thread Upayavira



On Fri, 26 Nov 2010 18:56 +0100, Manuel Gonzalo gonz...@strands.com
wrote:
 Hi all,
 
 while investigating SolrCloud for our distributed search needs  I can't
 seem to find the means to perform distributed writes/updates ...
 Distributed access to data is available but from what I understood each
 node has to be accessed independently in order to write/update a value.
 
 Is this so or am I missing something?

 Thanks in advance,

As I understand it, distributed write is a TODO as a part of SolrCloud. 

It would require a ShardStrategy interface, and probably a default
interface that simply does a MOD shard_count on the document ID.

Also, it would have to split incoming posts and distrubute amongst
shards (an incoming block of 500 documents would maybe end up as 5 posts
of 100 if we had five shards).

Upayavira

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

[jira] Commented: (LUCENE-2778) Allow easy extension of RAMDirectory

2010-11-26 Thread Shai Erera (JIRA)

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

Shai Erera commented on LUCENE-2778:

That's how I worked so far ... I usually develop on 3x and then merge to trunk.
I didn't think it will cause troubles :). I don't mind developing on trunk and
merging to 3x if that will improve anything, but would the history of 3x look
like then? Perhaps we should avoid merging on a regular basis and instead apply
the patch on both, and then once in a while we do a big mergeprops merge?

Allow easy extension of RAMDirectory

Attachments: LUCENE-2778.patch

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

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

Lucene-Solr-tests-only-trunk - Build # 1895 - Failure

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

1 tests failed.
REGRESSION:  org.apache.solr.cloud.CloudStateUpdateTest.testCoreRegistration

Error Message:
null

Stack Trace:
org.apache.solr.common.cloud.ZooKeeperException: 
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:601)
at 
org.apache.solr.cloud.CloudStateUpdateTest.testCoreRegistration(CloudStateUpdateTest.java:155)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:950)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:888)
Caused by: org.apache.zookeeper.KeeperException$SessionExpiredException: 
KeeperErrorCode = Session expired for /collections/testcore
at org.apache.zookeeper.KeeperException.create(KeeperException.java:118)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:42)
at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:809)
at 
org.apache.solr.common.cloud.SolrZkClient.exists(SolrZkClient.java:173)
at 
org.apache.solr.cloud.ZkController.createCollectionZkNode(ZkController.java:577)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:589)




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



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

[jira] Commented: (SOLR-2245) MailEntityProcessor Update

2010-11-26 Thread Lance Norskog (JIRA)

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

Lance Norskog commented on SOLR-2245:
-

bq. Tested on the 3.x trunk ...
3.x or trunk or both? Just 3.x is fine;

Please add 'in-reply-to' to the fetched stored headers. This is necessary to
reconstruct mail threads.

Also, please add or update the unit tests.

MailEntityProcessor Update
--

Key: SOLR-2245
URL: https://issues.apache.org/jira/browse/SOLR-2245
Project: Solr
Issue Type: Improvement
Components: contrib - DataImportHandler
Affects Versions: 1.4, 1.4.1
Reporter: Peter Sturge
Priority: Minor
Fix For: 1.4.2

Attachments: SOLR-2245.patch, SOLR-2245.patch, SOLR-2245.zip

This patch addresses a number of issues in the MailEntityProcessor
contrib-extras module.
The changes are outlined here:
* Added an 'includeContent' entity attribute to allow specifying content to
be included independently of processing attachments
e.g. entity includeContent=true processAttachments=false . . . /
would include message content, but not attachment content
* Added a synonym called 'processAttachments', which is synonymous to the
mis-spelled (and singular) 'processAttachement' property. This property
functions the same as processAttachement. Default= 'true' - if either is
false, then attachments are not processed. Note that only one of these should
really be specified in a given entity tag.
* Added a FLAGS.NONE value, so that if an email has no flags (i.e. it is
unread, not deleted etc.), there is still a property value stored in the
'flags' field (the value is the string none)
Note: there is a potential backward compat issue with FLAGS.NONE for clients
that expect the absence of the 'flags' field to mean 'Not read'. I'm
calculating this would be extremely rare, and is inadviasable in any case as
user flags can be arbitrarily set, so fixing it up now will ensure future
client access will be consistent.
* The folder name of an email is now included as a field called 'folder'
(e.g. folder=INBOX.Sent). This is quite handy in search/post-indexing
processing
* The addPartToDocument() method that processes attachments is significantly
re-written, as there looked to be no real way the existing code would ever
actually process attachment content and add it to the row data
Tested on the 3.x trunk with a number of popular imap servers.

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

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

Re: Field Collapse backport for Solr 1.4 (1.4.1)?

2010-11-26 Thread Lance Norskog

It is a hard problem.The old field collapsing JIRA (236) project sat
open and active for 3.5 years without being committed. This
implementation in the trunk is completely different.  It tries to do a
lot of things efficiently and needs systemic changes to Solr and
Lucene. It will take awhile before all the features and problems are
worked out. The theme of 3.x is bug fixes and solid features, and
field collapsing does not fall in this category.

On Wed, Nov 24, 2010 at 7:05 AM, Grant Ingersoll gsing...@apache.org wrote:

 On Nov 23, 2010, at 5:42 PM, Adam H. wrote:

 Is there an easy way of enabling this feature on a stock build of solr 1.4 / 
 1.4.1 ? would very much like to incorporate it without having
 to carry over all the solr 4.0 trunk..

 You could do it yourself, but 1.4.X is bug fix only at this point, so we 
 won't be backporting.  It will likely be in 3.x, which is roughly the 
 equivalent of 1.5 (since we changed version numbers).

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





-- 
Lance Norskog
goks...@gmail.com

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

[jira] Commented: (SOLR-1143) Return partial results when a connection to a shard is refused

2010-11-26 Thread Rich Cariens (JIRA)


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

Rich Cariens commented on SOLR-1143:


Looks like this issue's been starving for attention...

What's the status on this patch?  Are we waiting for SolrCloud?

 Return partial results when a connection to a shard is refused
 --

 Key: SOLR-1143
 URL: https://issues.apache.org/jira/browse/SOLR-1143
 Project: Solr
  Issue Type: Improvement
  Components: search
Reporter: Nicolas Dessaigne
Assignee: Grant Ingersoll
 Fix For: Next

 Attachments: SOLR-1143-2.patch, SOLR-1143-3.patch, SOLR-1143.patch


 If any shard is down in a distributed search, a ConnectException it thrown.
 Here's a little patch that change this behaviour: if we can't connect to a 
 shard (ConnectException), we get partial results from the active shards. As 
 for TimeOut parameter (https://issues.apache.org/jira/browse/SOLR-502), we 
 set the parameter partialResults at true.
 This patch also adresses a problem expressed in the mailing list about a year 
 ago 
 (http://www.nabble.com/partialResults,-distributed-search---SOLR-502-td19002610.html)
 We have a use case that needs this behaviour and we would like to know your 
 thougths about such a behaviour? Should it be the default behaviour for 
 distributed search?

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


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

Lucene-Solr-tests-only-trunk - Build # 1901 - Failure