date:20130722


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

Erick Erickson resolved SOLR-5054.
--

Resolution: Invalid

Please raise kind of question on the user's or dev list before raising a JIRA, 
this sounds a lot more like a usage question than a development task.

But my first guess is that you haven't put your custom jar files on all your 
nodes.

 My  private query component does not work in solrcloud
 --

 Key: SOLR-5054
 URL: https://issues.apache.org/jira/browse/SOLR-5054
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.3.1
 Environment: Linux x64 
Reporter: che
  Labels: solr, solrcloud
   Original Estimate: 5m
  Remaining Estimate: 5m

  I user my HQ.jar  in one solr is ok every query is entry in my HQ.
   But I make a solrcloud with three  shards. The HQ.jar is not work.The log 
 is not print  .so I think it is not entry in. 
   Do you know why ,thank you any help.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-5056) Further clean up of ConfigSolr interface and CoreContainer construction

2013-07-22 Thread Alan Woodward (JIRA)

Alan Woodward created SOLR-5056:
---

 Summary: Further clean up of ConfigSolr interface and 
CoreContainer construction
 Key: SOLR-5056
 URL: https://issues.apache.org/jira/browse/SOLR-5056
 Project: Solr
  Issue Type: Improvement
Reporter: Alan Woodward
Assignee: Alan Woodward
Priority: Minor


Makes ConfigSolr a bit more typesafe, and pushes a bunch of cloud-specific 
config into ZkController.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-5056) Further clean up of ConfigSolr interface and CoreContainer construction

2013-07-22 Thread Alan Woodward (JIRA)


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

Alan Woodward updated SOLR-5056:


Attachment: SOLR-5056.patch

 Further clean up of ConfigSolr interface and CoreContainer construction
 ---

 Key: SOLR-5056
 URL: https://issues.apache.org/jira/browse/SOLR-5056
 Project: Solr
  Issue Type: Improvement
Reporter: Alan Woodward
Assignee: Alan Woodward
Priority: Minor
 Attachments: SOLR-5056.patch


 Makes ConfigSolr a bit more typesafe, and pushes a bunch of cloud-specific 
 config into ZkController.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-5127) FixedGapTermsIndex should use monotonic compression

2013-07-22 Thread Michael McCandless (JIRA)


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

Michael McCandless commented on LUCENE-5127:


+1

I think we should just nuke the divisor?

 FixedGapTermsIndex should use monotonic compression
 ---

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


 for the addresses in the big in-memory byte[] and disk blocks, we could save 
 a good deal of RAM here.
 I think this codec just never got upgraded when we added these new packed 
 improvements, but it might be interesting to try to use for the terms data of 
 sorted/sortedset DV implementations.
 patch works, but has nocommits and currently ignores the divisor. The 
 annoying problem there being that we have the shared interface with 
 get(int) for PackedInts.Mutable/Reader, but no equivalent base class for 
 monotonics get(long)... 
 Still its enough that we could benchmark/compare for now.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-5057) queryResultCache should not related with the order of fq's list

2013-07-22 Thread huangfeihong (JIRA)

huangfeihong created SOLR-5057:
--

 Summary: queryResultCache should not related with the order of 
fq's list
 Key: SOLR-5057
 URL: https://issues.apache.org/jira/browse/SOLR-5057
 Project: Solr
  Issue Type: Improvement
  Components: search
Affects Versions: 4.3, 4.2, 4.1, 4.0
Reporter: huangfeihong
Priority: Minor


There are two case in the same meaning below. But the case2 can't use the 
queryResultCache when case1 is executed.

case1: q=*:*fq=field1:value1fq=field2:value2
case2: q=*:*fq=field2:value2fq=field1:value1

I think queryResultCache should not be related with the order of fq's list.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4956) make maxBufferedAddsPerServer configurable

2013-07-22 Thread Yonik Seeley (JIRA)

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

Yonik Seeley commented on SOLR-4956:

Yes, if we're buffering per-thread/request, then the larger the buffer, the
larger the practical chances that big update reorderings can happen on
replicas. If the reordering is big enough, a recovering node using peer sync
could think it was pretty much up to date. It's not just peer sync either -
other things like deletes, and deleteByQuery have limited lookback to handle
reorders.

Buffering isn't ideal for a lot of reasons
- update reorderings on the order of nIndexingThreads * bufferSize
- increases the intermediate difference between replicas and leaders (wrt
queries)
- memory size - we don't know how big documents are... they could be huge

It would be nice to move in the other direction and do less buffering.

make maxBufferedAddsPerServer configurable
--

Key: SOLR-4956
URL: https://issues.apache.org/jira/browse/SOLR-4956
Project: Solr
Issue Type: Improvement
Affects Versions: 4.3, 5.0
Reporter: Erick Erickson

Anecdotal user's list evidence indicates that in high-throughput situations,
the default of 10 docs/batch for inter-shard batching can generate
significant CPU load. See the thread titled Sharding and Replication on
June 19th, but the gist is below.
I haven't poked around, but it's a little surprising on the surface that Asif
is seeing this kind of difference. So I'm wondering if this change indicates
some other underlying issue. Regardless, this seems like it would be good to
investigate.
Here's the gist of Asif's experience from the thread:
Its a completely practical problem - we are exploring Solr to build a real
time analytics/data solution for a system handling about 1000 qps. We have
various metrics that are stored as different collections on the cloud,
which means very high amount of writes. The cloud also needs to support
about 300-400 qps.
We initially tested with a single Solr node on a 16 core / 24 GB box for a
single metric. We saw that writes were not a issue at all - Solr was
handling it extremely well. We were also able to achieve about 200 qps from
a single node.
When we set up the cloud ( a ensemble on 6 boxes), we saw very high CPU
usage on the replicas. Up to 10 cores were getting used for writes on the
replicas. Hence my concern with respect to batch updates for the replicas.
BTW, I altered the maxBufferedAddsPerServer to 1000 - and now CPU usage is
very similar to single node installation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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

[RESULT][VOTE] Release 4.4 RC1

2013-07-22 Thread Steve Rowe

This vote has passed.

I'll start the release process now.

Steve

On Jul 19, 2013, at 10:05 AM, Steve Rowe sar...@gmail.com wrote:
 Please vote to release Lucene and Solr 4.4, built off revision 1504776 of 
 https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_4.
 
 RC1 artifacts are available at:
 
 http://people.apache.org/~sarowe/staging_area/lucene-solr-4.4.0-RC1-rev1504776
 
 The smoke tester passes for me.
 
 Here's my +1.
 
 Steve
 


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

[jira] [Commented] (LUCENE-5128) Calling IndexSearcher.searchAfter beyond the number of stored documents causes ArrayIndexOutOfBoundsException

2013-07-22 Thread Shai Erera (JIRA)

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

Shai Erera commented on LUCENE-5128:

bq. it should do its own tracking

That's the part that bothers me. If we don't allow passing such searchAfter,
we're basically telling apps that they should keep track of their shards, which
means they need to maintain state (not that it's hard to maintain in this
case). I'd rather first see the exception because from what I checked both
TopScoreDocsCollector and TopFieldsCollector should be fine with searchAfter =
reader.maxDoc(), and IndexSearch.searchAfter returns a TopDocs so there aren't
many collectors which can be affected. Except maybe if crocket uses
DrillSideways...

On one hand the core fix makes sense, on the other hand it may unnecessarily
complicate apps life. Especially if they need to obtain totalHits ... I wonder
if in that case they can run with TotalHitCountCollector instead and construct
an empty TopDocs? That's what happens when you currently pass
searchAfter=Integer.MAX_VALUE. I'll try to fix the test like that to see if it
helps.

Calling IndexSearcher.searchAfter beyond the number of stored documents
causes ArrayIndexOutOfBoundsException
-

Key: LUCENE-5128
URL: https://issues.apache.org/jira/browse/LUCENE-5128
Project: Lucene - Core
Issue Type: Bug
Components: core/search
Affects Versions: 4.2
Reporter: crocket
Attachments: LUCENE-5128.patch

ArrayIndexOutOfBoundsException makes it harder to reason about the cause.
Is there a better way to notify programmers of the cause?

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

[jira] [Updated] (SOLR-5057) queryResultCache should not related with the order of fq's list

2013-07-22 Thread Feihong Huang (JIRA)

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

Feihong Huang updated SOLR-5057:

Description:
There are two case query with the same meaning below. But the case2 can't use
the queryResultCache when case1 is executed.

case1: q=*:*fq=field1:value1fq=field2:value2
case2: q=*:*fq=field2:value2fq=field1:value1

I think queryResultCache should not be related with the order of fq's list.

was:
There are two case in the same meaning below. But the case2 can't use the
queryResultCache when case1 is executed.

case1: q=*:*fq=field1:value1fq=field2:value2
case2: q=*:*fq=field2:value2fq=field1:value1

I think queryResultCache should not be related with the order of fq's list.

queryResultCache should not related with the order of fq's list
---

Key: SOLR-5057
URL: https://issues.apache.org/jira/browse/SOLR-5057
Project: Solr
Issue Type: Improvement
Components: search
Affects Versions: 4.0, 4.1, 4.2, 4.3
Reporter: Feihong Huang
Priority: Minor
Original Estimate: 48h
Remaining Estimate: 48h

There are two case query with the same meaning below. But the case2 can't use
the queryResultCache when case1 is executed.
case1: q=*:*fq=field1:value1fq=field2:value2
case2: q=*:*fq=field2:value2fq=field1:value1
I think queryResultCache should not be related with the order of fq's list.

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

Re: [VOTE] Release 4.4 RC1

2013-07-22 Thread Yonik Seeley

+1

-Yonik
http://lucidworks.com


On Fri, Jul 19, 2013 at 10:05 AM, Steve Rowe sar...@gmail.com wrote:
 Please vote to release Lucene and Solr 4.4, built off revision 1504776 of 
 https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_4.

 RC1 artifacts are available at:

 http://people.apache.org/~sarowe/staging_area/lucene-solr-4.4.0-RC1-rev1504776

 The smoke tester passes for me.

 Here's my +1.

 Steve


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


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

[jira] [Commented] (SOLR-5057) queryResultCache should not related with the order of fq's list

2013-07-22 Thread ASF subversion and git services (JIRA)


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

Erick Erickson commented on SOLR-5057:
--

Hmmm, my initial reaction was that it'd be hard to figure out what clauses were 
equivalent. But I suppose a simple lexical ordering of all the relevant 
clauses would work for this. Of course the work-around is to generate your fq 
clauses in the same order every time.

 queryResultCache should not related with the order of fq's list
 ---

 Key: SOLR-5057
 URL: https://issues.apache.org/jira/browse/SOLR-5057
 Project: Solr
  Issue Type: Improvement
  Components: search
Affects Versions: 4.0, 4.1, 4.2, 4.3
Reporter: Feihong Huang
Priority: Minor
   Original Estimate: 48h
  Remaining Estimate: 48h

 There are two case query with the same meaning below. But the case2 can't use 
 the queryResultCache when case1 is executed.
 case1: q=*:*fq=field1:value1fq=field2:value2
 case2: q=*:*fq=field2:value2fq=field1:value1
 I think queryResultCache should not be related with the order of fq's list.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4478) Allow cores to specify a named config set

2013-07-22 Thread Noble Paul (JIRA)

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

Noble Paul commented on SOLR-4478:
--

handling the ${} substitutions are more work. But a lot of users who need
sharing of solrconfig would be happy to sacrifice that feature. if there are
${} is solrconfig.xml and shareConfig=true we can just fail.

Longer term we can support that too but will need some more changes the way
properties are read

Allow cores to specify a named config set
-

Key: SOLR-4478
URL: https://issues.apache.org/jira/browse/SOLR-4478
Project: Solr
Issue Type: Improvement
Affects Versions: 4.2, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Attachments: SOLR-4478.patch, SOLR-4478.patch

Part of moving forward to the new way, after SOLR-4196 etc... I propose an
additional parameter specified on the core node in solr.xml or as a
parameter in the discovery mode core.properties file, call it configSet,
where the value provided is a path to a directory, either absolute or
relative. Really, this is as though you copied the conf directory somewhere
to be used by more than one core.
Straw-man: There will be a directory solr_home/configsets which will be the
default. If the configSet parameter is, say, myconf, then I'd expect a
directory named myconf to exist in solr_home/configsets, which would look
something like
solr_home/configsets/myconf/schema.xml
solrconfig.xml
stopwords.txt
velocity
velocity/query.vm
etc.
If multiple cores used the same configSet, schema, solrconfig etc. would all
be shared (i.e. shareSchema=true would be assumed). I don't see a good
use-case for _not_ sharing schemas, so I don't propose to allow this to be
turned off. Hmmm, what if shareSchema is explicitly set to false in the
solr.xml or properties file? I'd guess it should be honored but maybe log a
warning?
Mostly I'm putting this up for comments. I know that there are already
thoughts about how this all should work floating around, so before I start
any work on this I thought I'd at least get an idea of whether this is the
way people are thinking about going.
Configset can be either a relative or absolute path, if relative it's assumed
to be relative to solr_home.
Thoughts?

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

[jira] [Commented] (LUCENE-5127) FixedGapTermsIndex should use monotonic compression

2013-07-22 Thread Robert Muir (JIRA)


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

Robert Muir commented on LUCENE-5127:
-

Maybe, though we could also add a minimal get(long) interface to 
blockpacked/monotonicblockpacked/appending/monotonicappending.

A few notes:
* Current patch changes both the disk offsets (termsDictOffsets) and the 
offsets into the in-ram terms data (termOffsets)
* With the current patch as-is, we could remove the interval*2B #terms 
limitation, as long addressing is used everywhere.
* Current patch saves RAM, savings increase as termsindex/termsdict gets 
larger. With 10M:
||Checkout||TIB||TII||
|Trunk|519329144|19300603|
|Patch|519329144|14149524|
* Current patch slows down seek-heavy queries a bit:
{noformat}
Task   QPS trunk  StdDev   QPS patch  StdDev
Pct diff
PKLookup   86.02  (2.9%)   76.17  (2.4%)  
-11.4% ( -16% -   -6%)
 Respell   39.76  (3.0%)   36.58  (2.5%)   
-8.0% ( -13% -   -2%)
  Fuzzy2   35.49  (4.1%)   32.88  (2.6%)   
-7.3% ( -13% -0%)
  Fuzzy1   31.49  (4.1%)   29.18  (2.6%)   
-7.3% ( -13% -0%)
{noformat}
* termOffsets are read twice per seek / binary search iteration:
{code}
  final long offset = fieldIndex.termOffsets.get(idx);
  final int length = (int) (fieldIndex.termOffsets.get(1+idx) - offset);
{code}
* termsDictOffsets are only read once... and this is really just an unfortunate 
consequence of TermsIndexReaderBase's API... ideally they would lazy-decode 
this until you really needed it, like BlockTree.

So I see a few things we could do:
# go forward with current patch (maybe add the divisor stuff via a simple get() 
interface). clean up int-long everywhere. I'm not sure if these perf diffs 
matter for the use cases where someone needs an ord-enabled terms index?
# hybrid patch, where termOffsets stay absolute but termDictOffsets use 
monotonicpacked. This would still save some space, but restore the seek-heavy 
perf. But then we wouldnt be able to cleanup int-long and so on.
# do nothing, maybe fork the logic of this thing so it can be used in DV. For 
how DV is used, it'd be the right tradeoff so its no issue there.

 FixedGapTermsIndex should use monotonic compression
 ---

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


 for the addresses in the big in-memory byte[] and disk blocks, we could save 
 a good deal of RAM here.
 I think this codec just never got upgraded when we added these new packed 
 improvements, but it might be interesting to try to use for the terms data of 
 sorted/sortedset DV implementations.
 patch works, but has nocommits and currently ignores the divisor. The 
 annoying problem there being that we have the shared interface with 
 get(int) for PackedInts.Mutable/Reader, but no equivalent base class for 
 monotonics get(long)... 
 Still its enough that we could benchmark/compare for now.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] Release 4.4 RC1

2013-07-22 Thread Mark Miller

+1

- Mark

On Jul 19, 2013, at 10:05 AM, Steve Rowe sar...@gmail.com wrote:

 Please vote to release Lucene and Solr 4.4, built off revision 1504776 of 
 https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_4.
 
 RC1 artifacts are available at:
 
 http://people.apache.org/~sarowe/staging_area/lucene-solr-4.4.0-RC1-rev1504776
 
 The smoke tester passes for me.
 
 Here's my +1.
 
 Steve
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 


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

RE: [VOTE] Release 4.4 RC1

2013-07-22 Thread Uwe Schindler

Sorry a little bit late, here is my +1

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


 -Original Message-
 From: Steve Rowe [mailto:sar...@gmail.com]
 Sent: Friday, July 19, 2013 4:06 PM
 To: dev@lucene.apache.org
 Subject: [VOTE] Release 4.4 RC1
 
 Please vote to release Lucene and Solr 4.4, built off revision 1504776 of
 https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_4
 .
 
 RC1 artifacts are available at:
 
 http://people.apache.org/~sarowe/staging_area/lucene-solr-4.4.0-RC1-
 rev1504776
 
 The smoke tester passes for me.
 
 Here's my +1.
 
 Steve
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
 commands, e-mail: dev-h...@lucene.apache.org


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

Re: svn commit: r870606 - in /websites/production/lucene/content: core/4_4_0/ core/4_4_0/analyzers-common/ core/4_4_0/analyzers-common/org/ core/4_4_0/analyzers-common/org/apache/ core/4_4_0/analyzers

2013-07-22 Thread Uwe Schindler

Yeah, you managed it in one commit! 



sar...@apache.org schrieb:
Author: sarowe
Date: Mon Jul 22 16:25:46 2013
New Revision: 870606

Log:
Lucene/Solr 4.4.0 documentation


[This commit notification would consist of 1693 parts, 
which exceeds the limit of 50 ones, so it was shortened to the
summary.]

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

[jira] [Commented] (LUCENE-4734) FastVectorHighlighter Overlapping Proximity Queries Do Not Highlight


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

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

Commit 1505731 from [~jpountz] in branch 'dev/trunk'
[ https://svn.apache.org/r1505731 ]

LUCENE-4734: Better memory efficiency.

 FastVectorHighlighter Overlapping Proximity Queries Do Not Highlight
 

 Key: LUCENE-4734
 URL: https://issues.apache.org/jira/browse/LUCENE-4734
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/highlighter
Affects Versions: 4.0, 4.1, 5.0
Reporter: Ryan Lauck
Assignee: Adrien Grand
  Labels: fastvectorhighlighter, highlighter
 Fix For: 4.4

 Attachments: LUCENE-4734-2.patch, lucene-4734.patch, LUCENE-4734.patch


 If a proximity phrase query overlaps with any other query term it will not be 
 highlighted.
 Example Text:  A B C D E F G
 Example Queries: 
 B E~10 D
 (D will be highlighted instead of B C D E)
 B E~10 C F~10
 (nothing will be highlighted)
 This can be traced to the FieldPhraseList constructor's inner while loop. 
 From the first example query, the first TermInfo popped off the stack will be 
 B. The second TermInfo will be D which will not be found in the submap 
 for B E~10 and will trigger a failed match.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4734) FastVectorHighlighter Overlapping Proximity Queries Do Not Highlight

2013-07-22 Thread ASF subversion and git services (JIRA)


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

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

Commit 1505732 from [~jpountz] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1505732 ]

LUCENE-4734: Better memory efficiency.

 FastVectorHighlighter Overlapping Proximity Queries Do Not Highlight
 

 Key: LUCENE-4734
 URL: https://issues.apache.org/jira/browse/LUCENE-4734
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/highlighter
Affects Versions: 4.0, 4.1, 5.0
Reporter: Ryan Lauck
Assignee: Adrien Grand
  Labels: fastvectorhighlighter, highlighter
 Fix For: 4.4

 Attachments: LUCENE-4734-2.patch, lucene-4734.patch, LUCENE-4734.patch


 If a proximity phrase query overlaps with any other query term it will not be 
 highlighted.
 Example Text:  A B C D E F G
 Example Queries: 
 B E~10 D
 (D will be highlighted instead of B C D E)
 B E~10 C F~10
 (nothing will be highlighted)
 This can be traced to the FieldPhraseList constructor's inner while loop. 
 From the first example query, the first TermInfo popped off the stack will be 
 B. The second TermInfo will be D which will not be found in the submap 
 for B E~10 and will trigger a failed match.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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: svn commit: r870606 - in /websites/production/lucene/content: core/4_4_0/ core/4_4_0/analyzers-common/ core/4_4_0/analyzers-common/org/ core/4_4_0/analyzers-common/org/apache/ core/4_4_0/analyzers

2013-07-22 Thread Steve Rowe

Yes, only 48 minutes to upload!!!  

Since Shalin disabled the hourly website update for twitter/svn, checkouts 
don't get stale, and long commits can succeed.

Steve

On Jul 22, 2013, at 12:57 PM, Uwe Schindler u...@thetaphi.de wrote:

 Yeah, you managed it in one commit! 
 
 
 
 sar...@apache.org schrieb:
 Author: sarowe
 Date: Mon Jul 22 16:25:46 2013
 New Revision: 870606
 
 Log:
 Lucene/Solr 4.4.0 documentation
 
 
 [This commit notification would consist of 1693 parts, 
 which exceeds the limit of 50 ones, so it was shortened to the summary.]
 
 --
 Uwe Schindler
 H.-H.-Meier-Allee 63, 28213 Bremen
 http://www.thetaphi.de


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

Re: [JENKINS] Lucene-Solr-4.x-Linux (64bit/jdk1.8.0-ea-b98) - Build # 6591 - Failure!

2013-07-22 Thread Smiley, David W.

I'll look into this.

On 7/21/13 1:04 PM, Policeman Jenkins Server jenk...@thetaphi.de wrote:

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/6591/
Java: 64bit/jdk1.8.0-ea-b98 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.testCont
ains {#6 seed=[8C5C2CF3C312F7E6:6F314F7E2AA1141]}

Error Message:


Stack Trace:
java.lang.NullPointerException
   at 
__randomizedtesting.SeedInfo.seed([8C5C2CF3C312F7E6:6F314F7E2AA1141]:0)
   at 
org.apache.lucene.spatial.prefix.ContainsPrefixTreeFilter$ContainsVisitor.
seekExact(ContainsPrefixTreeFilter.java:137)
   at 
org.apache.lucene.spatial.prefix.ContainsPrefixTreeFilter$ContainsVisitor.
visit(ContainsPrefixTreeFilter.java:108)
   at 
org.apache.lucene.spatial.prefix.ContainsPrefixTreeFilter$ContainsVisitor.
access$000(ContainsPrefixTreeFilter.java:80)
   at 
org.apache.lucene.spatial.prefix.ContainsPrefixTreeFilter.getDocIdSet(Cont
ainsPrefixTreeFilter.java:77)
   at 
org.apache.lucene.search.ConstantScoreQuery$ConstantWeight.scorer(Constant
ScoreQuery.java:131)
   at 
org.apache.lucene.search.AssertingWeight.scorer(AssertingWeight.java:66)
   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
   at 
org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearc
her.java:93)
   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:488)
   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:444)
   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:281)
   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:269)
   at 
org.apache.lucene.spatial.SpatialTestCase.executeQuery(SpatialTestCase.jav
a:99)
   at 
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.doTest(S
patialOpRecursivePrefixTreeTest.java:281)
   at 
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.testCont
ains(SpatialOpRecursivePrefixTreeTest.java:103)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
57)
   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm
pl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:491)
   at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunne
r.java:1559)
   at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedR
unner.java:79)
   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedR
unner.java:737)
   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedR
unner.java:773)
   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedR
unner.java:787)
   at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSet
upTeardownChained.java:50)
   at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCa
cheSanity.java:51)
   at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf
terRule.java:46)
   at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.e
valuate(SystemPropertiesInvariantRule.java:55)
   at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThread
AndTestName.java:49)
   at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI
gnoreAfterMaxFailures.java:70)
   at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.
java:48)
   at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stateme
ntAdapter.java:36)
   at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(T
hreadLeakControl.java:358)
   at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(Th
readLeakControl.java:782)
   at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeak
Control.java:442)
   at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Randomiz
edRunner.java:746)
   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedR
unner.java:648)
   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedR
unner.java:682)
   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedR
unner.java:693)
   at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf
terRule.java:46)
   at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClas
sName.java:42)
   at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.e
valuate(SystemPropertiesInvariantRule.java:55)
   at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRu

[jira] [Commented] (LUCENE-4734) FastVectorHighlighter Overlapping Proximity Queries Do Not Highlight

2013-07-22 Thread Ryan Lauck (JIRA)


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

Ryan Lauck commented on LUCENE-4734:


I'm curious what you think about the comment I had in my original patch before 
calling addIfNoOverlap. It seems wasteful to traverse the phrase candidate list 
from the beginning every iteration to search for overlaps, and also prevents 
gathering the raw highlights as mentioned in my previous comment. What do you 
think about waiting until all phrase candidates are gathered to optionally 
filter overlaps?

 FastVectorHighlighter Overlapping Proximity Queries Do Not Highlight
 

 Key: LUCENE-4734
 URL: https://issues.apache.org/jira/browse/LUCENE-4734
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/highlighter
Affects Versions: 4.0, 4.1, 5.0
Reporter: Ryan Lauck
Assignee: Adrien Grand
  Labels: fastvectorhighlighter, highlighter
 Fix For: 4.4

 Attachments: LUCENE-4734-2.patch, lucene-4734.patch, LUCENE-4734.patch


 If a proximity phrase query overlaps with any other query term it will not be 
 highlighted.
 Example Text:  A B C D E F G
 Example Queries: 
 B E~10 D
 (D will be highlighted instead of B C D E)
 B E~10 C F~10
 (nothing will be highlighted)
 This can be traced to the FieldPhraseList constructor's inner while loop. 
 From the first example query, the first TermInfo popped off the stack will be 
 B. The second TermInfo will be D which will not be found in the submap 
 for B E~10 and will trigger a failed match.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4734) FastVectorHighlighter Overlapping Proximity Queries Do Not Highlight

2013-07-22 Thread Adrien Grand (JIRA)


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

Adrien Grand commented on LUCENE-4734:
--

I agree this seems wasteful. Maybe we could open an issue about it?

 FastVectorHighlighter Overlapping Proximity Queries Do Not Highlight
 

 Key: LUCENE-4734
 URL: https://issues.apache.org/jira/browse/LUCENE-4734
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/highlighter
Affects Versions: 4.0, 4.1, 5.0
Reporter: Ryan Lauck
Assignee: Adrien Grand
  Labels: fastvectorhighlighter, highlighter
 Fix For: 4.4

 Attachments: LUCENE-4734-2.patch, lucene-4734.patch, LUCENE-4734.patch


 If a proximity phrase query overlaps with any other query term it will not be 
 highlighted.
 Example Text:  A B C D E F G
 Example Queries: 
 B E~10 D
 (D will be highlighted instead of B C D E)
 B E~10 C F~10
 (nothing will be highlighted)
 This can be traced to the FieldPhraseList constructor's inner while loop. 
 From the first example query, the first TermInfo popped off the stack will be 
 B. The second TermInfo will be D which will not be found in the submap 
 for B E~10 and will trigger a failed match.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-5058) org.apache.solr.update.PeerSync Logging Warning Typo

2013-07-22 Thread Thomas Murphy (JIRA)

Thomas Murphy created SOLR-5058:
---

 Summary: org.apache.solr.update.PeerSync Logging Warning Typo
 Key: SOLR-5058
 URL: https://issues.apache.org/jira/browse/SOLR-5058
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.3
Reporter: Thomas Murphy
Priority: Trivial


Log entry appears on Solr Admin Logging interface:
WARNPeerSyncno frame of reference to tell of we've missed updates

There is a typo, this looks like it should read to tell if we've

PeerSync expands to org.apache.solr.update.PeerSync

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4677) Improve Solr's use of spec version.

2013-07-22 Thread ASF subversion and git services (JIRA)


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

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

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

SOLR-4677: stop adding obsolete '-Dspecversion=...' to 'ant prepare-release' 
cmds

 Improve Solr's use of spec version.
 ---

 Key: SOLR-4677
 URL: https://issues.apache.org/jira/browse/SOLR-4677
 Project: Solr
  Issue Type: Improvement
  Components: Build
Reporter: Mark Miller
 Fix For: 4.3, 5.0

 Attachments: SOLR-4677.patch, SOLR-4677.patch, SOLR-4677.patch


 Solr 4.2.1 went out with an impl version of 4.2.1 and a spec version of 4.2.0.
 This is because you must update the spec version in common-build.xml while 
 the impl is set by the version you pass as a sys prop when doing 
 prepare-release.
 Do we need this spec version? Does it serve any purpose? I think we should 
 either stop dealing with it or just set it the same way as the impl...or?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4677) Improve Solr's use of spec version.

2013-07-22 Thread ASF subversion and git services (JIRA)


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

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

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

SOLR-4677: stop adding obsolete '-Dspecversion=...' to 'ant prepare-release' 
cmds (merged trunk r1505776)

 Improve Solr's use of spec version.
 ---

 Key: SOLR-4677
 URL: https://issues.apache.org/jira/browse/SOLR-4677
 Project: Solr
  Issue Type: Improvement
  Components: Build
Reporter: Mark Miller
 Fix For: 4.3, 5.0

 Attachments: SOLR-4677.patch, SOLR-4677.patch, SOLR-4677.patch


 Solr 4.2.1 went out with an impl version of 4.2.1 and a spec version of 4.2.0.
 This is because you must update the spec version in common-build.xml while 
 the impl is set by the version you pass as a sys prop when doing 
 prepare-release.
 Do we need this spec version? Does it serve any purpose? I think we should 
 either stop dealing with it or just set it the same way as the impl...or?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Comment Edited] (SOLR-5036) Solr Ref Guide updates for Solr 4.4


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

Hoss Man edited comment on SOLR-5036 at 7/22/13 7:51 PM:
-

I made some more progress on Cassandra's list...

* 
https://cwiki.apache.org/confluence/display/solr/RequestDispatcher+in+SolrConfig
** SOLR-2079 - addHttpRequestToContext verbage
* https://cwiki.apache.org/confluence/display/solr/Query+Screen
** SOLR-3838 - fq verbage and updated creenshot
** SOLR-4719 - json default verbage  updated screenshot
* https://cwiki.apache.org/confluence/display/solr/Core-Specific+Tools
** update order of links to children and actual order of children in navigation
* https://cwiki.apache.org/confluence/display/solr/IndexConfig+in+SolrConfig
** SOLR-4941, SOLR-4934 and LUCENE-5038 - already ok, page doesn't go into 
depth about mergePolicy, example alreayd used correct compound file syntax
** SOLR-4761: added section on mergedSegmentWarmer
* https://cwiki.apache.org/confluence/display/solr/Command+Line+Utilities
** SOLR-4972: Add PUT command to ZkCli tool
* https://cwiki.apache.org/confluence/display/solr/Other+Parsers
** SOLR-4785: MaxScoreQParser
* https://cwiki.apache.org/confluence/display/solr/Upgrading+to+Solr+4.4
** New page on upgrading to 4.4 
** child of 
https://cwiki.apache.org/confluence/display/solr/Major+Changes+from+Solr+3+to+Solr+4
** clone of 
https://cwiki.apache.org/confluence/display/solr/Upgrading+to+Solr+4.3
** mention SOLR-4941, SOLR-4934 and LUCENE-5038
** mention SOLR-4778 and new LogWatcher API

* 
https://cwiki.apache.org/confluence/display/solr/Detecting+Languages+During+Indexing
** SOLR-4412: New parameter langid.lcmap

* https://cwiki.apache.org/confluence/display/solr/Spell+Checking
** SOLR-3240: Add spellcheck.collateMaxCollectDocs

* https://cwiki.apache.org/confluence/display/solr/Documents+Screen
** Added a basic stub page with a screenshoot
** linked from parent page
** ensured the page order was correct in navigation



But there is still a lot more that needs written -- stuff below i either don't 
understand the new feature enough to document myself, or didn't have the energy 
to try to tackle because it needs a lot written about it and i don't know it 
well enough to have a good sense of how to go about it...

* https://cwiki.apache.org/confluence/display/solr/Core-Specific+Tools
** SOLR-4921: Admin UI now supports adding documents to Solr (gsingers, 
steffkes)
** stub page with screenshot exists, but it needs verbage

* Completley new docs about the HDFS SolrCloud support ... somewhere
** SOLR-4916: Add support to write and read Solr index files and transaction 
log files to and from HDFS. (phunt, Mark Miller, Greg Chanan)
*** CT: Without studying this more, it's hard to know where this should go. 
It's not really SolrCloud, and it's not really a client, but depending on why 
it's being done it could overlap with either...If someone writes up what you'd 
tell someone about using it, I could give a better idea of where it fits in the 
existing page organization (if it does).

* 
https://cwiki.apache.org/confluence/display/solr/Documents%2C+Fields%2C+and+Schema+Design
** SOLR-4897: Add solr/example/example-schemaless/, an example config set for 
schemaless mode. (Steve Rowe)
*** CT: Schemaless in general needs to be added. The most likely place today is 
a new page under 
https://cwiki.apache.org/confluence/display/solr/Documents%2C+Fields%2C+and+Schema+Design

* 
https://cwiki.apache.org/confluence/display/solr/Core+Admin+and+Configuring+solr.xml
** SOLR-4757: Change the example to use the new solr.xml format and core 
discovery by directory structure. (Mark Miller)
*** CT: There is a page on solr.xml: 
https://cwiki.apache.org/confluence/display/solr/Core+Admin+and+Configuring+solr.xml.
 This should be updated to show the new format and still include information on 
the old format for anyone with the old format who uses this guide for reference.
** SOLR-4655: Add option to have Overseer assign generic node names so that new 
addresses can host shards without naming confusion. (Mark Miller, Anshum Gupta)
*** CT: I think this only needs to be added to any new content for solr.xml at 
https://cwiki.apache.org/confluence/display/solr/Core+Admin+and+Configuring+solr.xml

* https://cwiki.apache.org/confluence/display/solr/Collections+API
** SOLR-4693: A deleteshard collections API that unloads all replicas of a 
given shard and then removes it from the cluster state. It will remove only 
those shards which are INACTIVE or have no range (created for custom sharding). 
(Anshum Gupta, shalin)
*** CT: Add to https://cwiki.apache.org/confluence/display/solr/Collections+API

* https://cwiki.apache.org/confluence/display/solr/Schema+API
** SOLR-3251: Dynamically add fields to schema. (Steve Rowe, Robert Muir, yonik)
*** CT: Add to

[jira] [Created] (SOLR-5059) 4.4 refguide pages on schemaless schema rest api for adding fields

Hoss Man created SOLR-5059:
--

 Summary: 4.4 refguide pages on schemaless  schema rest api for 
adding fields
 Key: SOLR-5059
 URL: https://issues.apache.org/jira/browse/SOLR-5059
 Project: Solr
  Issue Type: Sub-task
  Components: documentation
Reporter: Hoss Man
Assignee: Steve Rowe


breaking off from parent...


* 
https://cwiki.apache.org/confluence/display/solr/Documents%2C+Fields%2C+and+Schema+Design
** SOLR-4897: Add solr/example/example-schemaless/, an example config set for 
schemaless mode. (Steve Rowe)
*** CT: Schemaless in general needs to be added. The most likely place today is 
a new page under 
https://cwiki.apache.org/confluence/display/solr/Documents%2C+Fields%2C+and+Schema+Design

* https://cwiki.apache.org/confluence/display/solr/Schema+API
** SOLR-3251: Dynamically add fields to schema. (Steve Rowe, Robert Muir, yonik)
*** CT: Add to https://cwiki.apache.org/confluence/display/solr/Schema+API
** SOLR-5010: Add support for creating copy fields to the Fields REST API 
(gsingers)
*** CT: Add to https://cwiki.apache.org/confluence/display/solr/Schema+API


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-5060) 4.4 refguide pages on hdfs support

Hoss Man created SOLR-5060:
--

 Summary: 4.4 refguide pages on hdfs support
 Key: SOLR-5060
 URL: https://issues.apache.org/jira/browse/SOLR-5060
 Project: Solr
  Issue Type: Sub-task
  Components: documentation
Reporter: Hoss Man
Assignee: Mark Miller


breaking off from parent...


* Completley new docs about the HDFS SolrCloud support ... somewhere
** SOLR-4916: Add support to write and read Solr index files and transaction 
log files to and from HDFS. (phunt, Mark Miller, Greg Chanan)
*** CT: Without studying this more, it's hard to know where this should go. 
It's not really SolrCloud, and it's not really a client, but depending on why 
it's being done it could overlap with either...If someone writes up what you'd 
tell someone about using it, I could give a better idea of where it fits in the 
existing page organization (if it does).


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-5061) 4.4 refguide pages new solr.xml format

Hoss Man created SOLR-5061:
--

 Summary: 4.4 refguide pages new solr.xml format
 Key: SOLR-5061
 URL: https://issues.apache.org/jira/browse/SOLR-5061
 Project: Solr
  Issue Type: Sub-task
  Components: documentation
Reporter: Hoss Man
Assignee: Erick Erickson


breaking off from parent issue...

* 
https://cwiki.apache.org/confluence/display/solr/Core+Admin+and+Configuring+solr.xml
** SOLR-4757: Change the example to use the new solr.xml format and core 
discovery by directory structure. (Mark Miller)
*** CT: There is a page on solr.xml: 
https://cwiki.apache.org/confluence/display/solr/Core+Admin+and+Configuring+solr.xml.
 This should be updated to show the new format and still include information on 
the old format for anyone with the old format who uses this guide for reference.
** SOLR-4655: Add option to have Overseer assign generic node names so that new 
addresses can host shards without naming confusion. (Mark Miller, Anshum Gupta)
*** CT: I think this only needs to be added to any new content for solr.xml at 
https://cwiki.apache.org/confluence/display/solr/Core+Admin+and+Configuring+solr.xml


It should also be noted that cassandra posted some additional deailed suggests 
in a comment on the existing page in the ref guide...

https://cwiki.apache.org/confluence/display/solr/Core+Admin+and+Configuring+solr.xml?focusedCommentId=33296160#comment-33296160

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-5062) 4.4 refguide updates related to shardsplitting and deleteshard

Hoss Man created SOLR-5062:
--

 Summary: 4.4 refguide updates related to shardsplitting and 
deleteshard
 Key: SOLR-5062
 URL: https://issues.apache.org/jira/browse/SOLR-5062
 Project: Solr
  Issue Type: Sub-task
  Components: documentation
Reporter: Hoss Man
Assignee: Shalin Shekhar Mangar


breaking off from parent issue...


* https://cwiki.apache.org/confluence/display/solr/Collections+API
** in general, we need to review this in page in lite of all the shardsplitting 
stuff and make sure everything is up to date.
** SOLR-4693: A deleteshard collections API that unloads all replicas of a 
given shard and then removes it from the cluster state. It will remove only 
those shards which are INACTIVE or have no range (created for custom sharding). 
(Anshum Gupta, shalin)
*** CT: Add to https://cwiki.apache.org/confluence/display/solr/Collections+API


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-5063) 4.4 refguide improvements on new doc adding screen in ui

Hoss Man created SOLR-5063:
--

 Summary: 4.4 refguide improvements on new doc adding screen in ui
 Key: SOLR-5063
 URL: https://issues.apache.org/jira/browse/SOLR-5063
 Project: Solr
  Issue Type: Sub-task
  Components: documentation
Reporter: Hoss Man
Assignee: Grant Ingersoll


breaking off from parent issue...

* https://cwiki.apache.org/confluence/display/solr/Core-Specific+Tools
** SOLR-4921: Admin UI now supports adding documents to Solr (gsingers, 
steffkes)
** stub page with screenshot exists, but it needs verbage explaining how it 
works and what the diff options mean


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3688) Bucketing of association value of a certain category

2013-07-22 Thread Sivan Yogev (JIRA)


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

Sivan Yogev commented on LUCENE-3688:
-

I want to do this, but not sure when I will get to it.

 Bucketing of association value of a certain category
 

 Key: LUCENE-3688
 URL: https://issues.apache.org/jira/browse/LUCENE-3688
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Reporter: Sivan Yogev
Priority: Minor
  Labels: bucket, facet
 Attachments: LUCENE-association-buckets.patch, 
 LUCENE-association-buckets.r1292224.patch


 Add facet requests which collect associations of a certain category into 
 buckets, and returns each bucket as a facet result node. Association type is 
 either int or float, and there are two methods to define buckets. The first 
 by providing buckets which contain pre-defined ranges. The other is by 
 declaring the required number of buckets, where the ranges of the different 
 buckets are dynamicly set to create balanced bucket sizes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-5036) Solr Ref Guide updates for Solr 4.4


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

Hoss Man commented on SOLR-5036:


FYI: I've taken the list of the remaining edits that need to be made, and split 
them all out into sub-tasks assigned to the individuals who have at one point 
or another told me they were working on (or planed to work on) these edits.

 Solr Ref Guide updates for Solr 4.4
 ---

 Key: SOLR-5036
 URL: https://issues.apache.org/jira/browse/SOLR-5036
 Project: Solr
  Issue Type: Improvement
  Components: documentation
Reporter: Cassandra Targett
 Fix For: 4.4


 In response to Hoss' email about updating the Solr Ref Guide, I thought it 
 would be helpful if I went through the CHANGES.txt file and noted what I 
 think might need an update (or a new page) and what pages should be reviewed 
 for each change. I hope this helps those who aren't yet fully versed with the 
 way it's organized.
 I commented on every item in CHANGES.txt, so I'll post my suggestions in a 
 couple of comments. Many items (like bug fixes) don't really need updates, 
 but more eyes on that would be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-5064) Update dependency org=org.codehaus.woodstox name=wstx-asl rev=3.2.7 transitive=false/ to a more recent version.

2013-07-22 Thread Mark Miller (JIRA)

Mark Miller created SOLR-5064:
-

 Summary: Update dependency org=org.codehaus.woodstox 
name=wstx-asl rev=3.2.7 transitive=false/ to a more recent version.
 Key: SOLR-5064
 URL: https://issues.apache.org/jira/browse/SOLR-5064
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 5.0, 4.5


@whoschek mentioned to me earlier that we were using a fairly old version.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-5062) 4.4 refguide updates related to shardsplitting and deleteshard

2013-07-22 Thread Cassandra Targett (JIRA)


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

Cassandra Targett commented on SOLR-5062:
-

[~shalinmangar]: I made some suggestions on how to add doc on this as a comment 
to the page Hoss referenced. Feel free to edit as needed.

 4.4 refguide updates related to shardsplitting and deleteshard
 --

 Key: SOLR-5062
 URL: https://issues.apache.org/jira/browse/SOLR-5062
 Project: Solr
  Issue Type: Sub-task
  Components: documentation
Reporter: Hoss Man
Assignee: Shalin Shekhar Mangar
 Fix For: 4.4


 breaking off from parent issue...
 * https://cwiki.apache.org/confluence/display/solr/Collections+API
 ** in general, we need to review this in page in lite of all the 
 shardsplitting stuff and make sure everything is up to date.
 ** SOLR-4693: A deleteshard collections API that unloads all replicas of a 
 given shard and then removes it from the cluster state. It will remove only 
 those shards which are INACTIVE or have no range (created for custom 
 sharding). (Anshum Gupta, shalin)
 *** CT: Add to 
 https://cwiki.apache.org/confluence/display/solr/Collections+API

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-5128) Calling IndexSearcher.searchAfter beyond the number of stored documents causes ArrayIndexOutOfBoundsException

2013-07-22 Thread Shai Erera (JIRA)


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

Shai Erera updated LUCENE-5128:
---

Attachment: LUCENE-5128.patch

I had a chat w/ Mike about what's going on in the test and turns out the test 
is fine, comments needed some improvements. So I fixed IndexSearcher to throw 
IllegalArgEx if searchAfter.doc = maxDoc + fixed test comments (I think they 
better explain what's going on there -- Mike, appreciate your review!) and set 
after.doc to maxDoc-1.

I think it's ready. This all makes sense now (to me). Core tests pass. I'd 
appreciate some review, but I intend to commit this tomorrow.

 Calling IndexSearcher.searchAfter beyond the number of stored documents 
 causes ArrayIndexOutOfBoundsException
 -

 Key: LUCENE-5128
 URL: https://issues.apache.org/jira/browse/LUCENE-5128
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/search
Affects Versions: 4.2
Reporter: crocket
 Attachments: LUCENE-5128.patch, LUCENE-5128.patch


 ArrayIndexOutOfBoundsException makes it harder to reason about the cause.
 Is there a better way to notify programmers of the cause?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Resolved] (SOLR-5030) determine document specific steps to publish ref guide with each release


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

Hoss Man resolved SOLR-5030.


Resolution: Fixed

I'm calling this done -- the initial version is live, but it's a living doc 
that will evolve with each release.

 determine  document specific steps to publish ref guide with each release
 

 Key: SOLR-5030
 URL: https://issues.apache.org/jira/browse/SOLR-5030
 Project: Solr
  Issue Type: Sub-task
  Components: documentation
Reporter: Hoss Man
Assignee: Hoss Man

 need to document the release process for the documentation...
 * how is the PDF generated (SOLR-4886
 * when should things happen (ie: wait until code release vote is final for 
 last minute doc fixes?)
 * call a vote on the PDF
 * where should PDF live once vote is done?
 * where to link to released PDF(s) from site, moinmoin, confluence nav
 * what content needs changed after being published (ie: 4.3 - 4.4)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-5128) Calling IndexSearcher.searchAfter beyond the number of stored documents causes ArrayIndexOutOfBoundsException

2013-07-22 Thread Michael McCandless (JIRA)


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

Michael McCandless commented on LUCENE-5128:


+1, patch looks great.  Thanks Shai!

 Calling IndexSearcher.searchAfter beyond the number of stored documents 
 causes ArrayIndexOutOfBoundsException
 -

 Key: LUCENE-5128
 URL: https://issues.apache.org/jira/browse/LUCENE-5128
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/search
Affects Versions: 4.2
Reporter: crocket
 Attachments: LUCENE-5128.patch, LUCENE-5128.patch


 ArrayIndexOutOfBoundsException makes it harder to reason about the cause.
 Is there a better way to notify programmers of the cause?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-2894) Implement distributed pivot faceting

2013-07-22 Thread Andrew Muldowney (JIRA)


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

Andrew Muldowney updated SOLR-2894:
---

Attachment: SOLR-2894.patch

This version fixes the following:

1) Indecisive faceting not being respected on refinement queries
2) Key not being respected
3) Facet.offset not being respected
4) datetimes breaking when trying to refine


One point of contention is this:
The SolrExampleTests.java (for the SolrJ stuff) had a check that required pivot 
facet boolean results as strict Boolean.TRUE as opposed to the string true.

This came about from the change that was required to fix datetime. 

I can't find anywhere else where we require a boolean field's value to equal 
Boolean.True so I think this test was just an artifact of how the original 
pivot facetting code was written.

As it stands now the SolrExampleTests.doPivotFacetTest:1151 has been changed to 
true instead of Boolean.TRUE

 Implement distributed pivot faceting
 

 Key: SOLR-2894
 URL: https://issues.apache.org/jira/browse/SOLR-2894
 Project: Solr
  Issue Type: Improvement
Reporter: Erik Hatcher
 Fix For: 4.5

 Attachments: SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
 SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
 SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
 SOLR-2894.patch, SOLR-2894-reworked.patch


 Following up on SOLR-792, pivot faceting currently only supports 
 undistributed mode.  Distributed pivot faceting needs to be implemented.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Comment Edited] (SOLR-2894) Implement distributed pivot faceting

2013-07-22 Thread Andrew Muldowney (JIRA)


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

Andrew Muldowney edited comment on SOLR-2894 at 7/22/13 9:22 PM:
-

Built on 4_4
This version fixes the following:

1) Indecisive faceting not being respected on refinement queries
2) Key not being respected
3) Facet.offset not being respected
4) datetimes breaking when trying to refine


One point of contention is this:
The SolrExampleTests.java (for the SolrJ stuff) had a check that required pivot 
facet boolean results as strict Boolean.TRUE as opposed to the string true.

This came about from the change that was required to fix datetime. 

I can't find anywhere else where we require a boolean field's value to equal 
Boolean.True so I think this test was just an artifact of how the original 
pivot facetting code was written.

As it stands now the SolrExampleTests.doPivotFacetTest:1151 has been changed to 
true instead of Boolean.TRUE

  was (Author: andrew.muldowney):
This version fixes the following:

1) Indecisive faceting not being respected on refinement queries
2) Key not being respected
3) Facet.offset not being respected
4) datetimes breaking when trying to refine


One point of contention is this:
The SolrExampleTests.java (for the SolrJ stuff) had a check that required pivot 
facet boolean results as strict Boolean.TRUE as opposed to the string true.

This came about from the change that was required to fix datetime. 

I can't find anywhere else where we require a boolean field's value to equal 
Boolean.True so I think this test was just an artifact of how the original 
pivot facetting code was written.

As it stands now the SolrExampleTests.doPivotFacetTest:1151 has been changed to 
true instead of Boolean.TRUE
  
 Implement distributed pivot faceting
 

 Key: SOLR-2894
 URL: https://issues.apache.org/jira/browse/SOLR-2894
 Project: Solr
  Issue Type: Improvement
Reporter: Erik Hatcher
 Fix For: 4.5

 Attachments: SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
 SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
 SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
 SOLR-2894.patch, SOLR-2894-reworked.patch


 Following up on SOLR-792, pivot faceting currently only supports 
 undistributed mode.  Distributed pivot faceting needs to be implemented.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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

DISCUSS: First official Solr documentation release, plan to vote on wed.

2013-07-22 Thread Chris Hostetter



Now that the 4.4 release vote is official and gradually making it's way to 
the mirrors, I'd like to draw attention to the efforts that have been made 
to get the Solr Reference Guide into releasable shape, so that we can 
plan on holding a VOTE to release the 4.4 version ASAP...


https://cwiki.apache.org/confluence/display/solr/Apache+Solr+Reference+Guide
https://people.apache.org/~hossman/apache-solr-ref-guide-snapshot.pdf

TL;DR: I plan to call a vote to formaly release this doc in ~40 hours. 
Please help out by reviewing/improving the content -- especially if one of 
the subtasks of SOLR-5036 is asigned to you (because that means you 
already agreed you would).


- - -

For those of you who haven't been following along closely, there were a 
lot of hicups related to the Apache Confluence instance that slowed us 
down on getting hte RefGuide content donated by LucidWorks up and running 
and editable.  Some of those issues are still outstanding, notably because 
the ASF is still in the process of trying ot upgrade to Confluence 5.x, 
and that process is on hold indefinitely (See SOLR-4618 and it's subtasks 
for history) which means we may have to re-visit a lot of little things 
once the Confluence upgrade is complete.


In the meantime the Ref Guide is in fact up and live and and editable, and 
progress has been made on two fronts:


 * Getting the doc up to date with Solr 4.4 (SOLR-5036)
 * Getting a process in place to release/publish the doc with each
   minor solr release.

There are 4-5 major additions needed to the doc to cover Solr 4.4 
adequately, see the children of SOLR-5036 for details.  My hope is that 
the folks who volunteered to help out in writing those new sections of the 
doc can work on their edits over the next ~40 hours or so, and then on Wed 
morning (my time) I plan to vall a VOTE to formally release this doc 
(i'm volunteering to be the Doc RM this time arround)...


http://s.apache.org/exs

If you are one of the people assigned an outstanding doc issue, please 
speak up if you don't think you'll have your edits finished by then, or if 
you would like assistance with structure, wording or formatting...


 * SOLR-5059 - sarowe - schemaless  schema REST
 * SOLR-5060 - miller - HDFS
 * SOLR-5061 - erick  - new solr.xml format
 * SOLR-5062 - shalin - shard splitting review  new deleteshard cmd
 * SOLR-5063 - grant  - UI screen for adding docs

Even if you are not one of the people listed above, there is still a 
lot you can do to help out...


 * Reviewing any/all sections of the guide looking for content
   improvements that can be made (edit or post comments directly on the
   affected pages as you find them)

 * Reviewing the snapshot PDF looking for *general* formatting problems
   that need to be addressed. (reply to this thread or open a Jira)

 * Reviewing  sanity checking the process docs for how we will be
   maintaining  releasing hte guide looking for potential probems
   (edit or post comments if you see problems)...

https://cwiki.apache.org/confluence/display/solr/Internal+-+Maintaining+Documentation
https://cwiki.apache.org/confluence/display/solr/Internal+-+How+To+Publish+This+Documentation


If anyone has any general comments / concerns, please reply here.

-Hoss

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

[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 667 - Failure!

2013-07-22 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/667/
Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
REGRESSION:  org.apache.solr.client.solrj.TestBatchUpdate.testWithXml

Error Message:
IOException occured when talking to server at: 
https://127.0.0.1:51913/solr/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: https://127.0.0.1:51913/solr/collection1
at 
__randomizedtesting.SeedInfo.seed([C25C53179091FCC5:69BEEAE11297E5A8]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:435)
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180)
at 
org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:117)
at org.apache.solr.client.solrj.SolrServer.commit(SolrServer.java:168)
at org.apache.solr.client.solrj.SolrServer.commit(SolrServer.java:146)
at 
org.apache.solr.client.solrj.TestBatchUpdate.doIt(TestBatchUpdate.java:130)
at 
org.apache.solr.client.solrj.TestBatchUpdate.testWithXml(TestBatchUpdate.java:54)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at

[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #916: POMs out of sync

2013-07-22 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/916/

2 tests failed.
FAILED:  
org.apache.solr.cloud.BasicDistributedZkTest.org.apache.solr.cloud.BasicDistributedZkTest

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.cloud.BasicDistributedZkTest: 
   1) Thread[id=6524, name=recoveryCmdExecutor-3585-thread-1, state=RUNNABLE, 
group=TGRP-BasicDistributedZkTest]
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
at java.net.Socket.connect(Socket.java:579)
at 
org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:127)
at 
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
at 
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645)
at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480)
at 
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at 
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at 
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:365)
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180)
at org.apache.solr.cloud.SyncStrategy$1.run(SyncStrategy.java:291)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.cloud.BasicDistributedZkTest: 
   1) Thread[id=6524, name=recoveryCmdExecutor-3585-thread-1, state=RUNNABLE, 
group=TGRP-BasicDistributedZkTest]
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
at java.net.Socket.connect(Socket.java:579)
at 
org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:127)
at 
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
at 
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645)
at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480)
at 
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at 
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at 
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:365)
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180)
at org.apache.solr.cloud.SyncStrategy$1.run(SyncStrategy.java:291)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
at __randomizedtesting.SeedInfo.seed([8B462EA1B448E33C]:0)


FAILED:  
org.apache.solr.cloud.BasicDistributedZkTest.org.apache.solr.cloud.BasicDistributedZkTest

Error Message:
There are still zombie threads that couldn't be terminated:
   1) Thread[id=6524, name=recoveryCmdExecutor-3585-thread-1, state=RUNNABLE, 
group=TGRP-BasicDistributedZkTest]
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at

[jira] [Created] (SOLR-5065) ParseDoubleFieldUpdateProcessorFactory is unable to parse + in exponent

2013-07-22 Thread Jack Krupansky (JIRA)

Jack Krupansky created SOLR-5065:


 Summary: ParseDoubleFieldUpdateProcessorFactory is unable to parse 
+ in exponent
 Key: SOLR-5065
 URL: https://issues.apache.org/jira/browse/SOLR-5065
 Project: Solr
  Issue Type: Bug
  Components: update
Affects Versions: 4.4
Reporter: Jack Krupansky


The ParseDoubleFieldUpdateProcessorFactory is unable to parse the full syntax 
of Java/JSON scientific notation. Parse fails for 4.5E+10, but does succeed 
for 4.5E10 and 4.5E-10.

Using the schema and config from example-schemaless, I added this data:

{code}
  curl http://localhost:8983/solr/update?commit=true; \
  -H 'Content-type:application/json' -d '
  [{id: doc-1,
a1: Hello World,
a2: 123,
a3: 123.0,
a4: 1.23,
a5: 4.5E+10,
a6: 123,
a7: true,
a8: false,
a9: true,
a10: 2013-07-22,
a11: 4.5E10,
a12: 4.5E-10,
a13: 4.5E+10,
a14: 4.5E10,
a15: 4.5E-10}]'
{code}

A query returns:
{code}
  doc
str name=iddoc-1/str
arr name=a1
  strHello World/str
/arr
arr name=a2
  long123/long
/arr
arr name=a3
  double123.0/double
/arr
arr name=a4
  double1.23/double
/arr
arr name=a5
  double4.5E10/double
/arr
arr name=a6
  long123/long
/arr
arr name=a7
  booltrue/bool
/arr
arr name=a8
  boolfalse/bool
/arr
arr name=a9
  booltrue/bool
/arr
arr name=a10
  date2013-07-22T00:00:00Z/date
/arr
arr name=a11
  double4.5E10/double
/arr
arr name=a12
  double4.5E-10/double
/arr
arr name=a13
  str4.5E+10/str
/arr
arr name=a14
  double4.5E10/double
/arr
arr name=a15
  double4.5E-10/double
/arr
long name=_version_1441308941516537856/long/doc
{code}

The input value of a13 was the same as a5, but was treated as a string, rather 
than parsed as a double. So, JSON/Java was able to parse 4.5E+10, but this 
update processor was not.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4787) Join Contrib


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

Kranti Parisa commented on SOLR-4787:
-

Joel,

I wanted to try implementing pjoin for the following use case.

masterCore = 1M keys (id field, long)
childCore = 5M documents (with parentid field, long, whose values are equal to 
the values of id field in the masterCore

And syntax looks like
http://localhost:8180/solr/masterCore/select?q=title:afq=({!pjoin%20fromIndex=childCore%20from=parentid%20to=id%20v=$childQ})childQ=(fieldOne:somevalue
 AND fieldTwo:[1 TO 100])

I am getting SyntaxError, but the same syntax works with normal join. any 
ideas?

Also it seems currently pjoin supports only int keys, can you please update 
pjoin to allow for longs

-
Kranti



 Join Contrib
 

 Key: SOLR-4787
 URL: https://issues.apache.org/jira/browse/SOLR-4787
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 4.2.1
Reporter: Joel Bernstein
Priority: Minor
 Fix For: 4.4

 Attachments: SOLR-4787-deadlock-fix.patch, SOLR-4787.patch, 
 SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, 
 SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, 
 SOLR-4787.patch


 This contrib provides a place where different join implementations can be 
 contributed to Solr. This contrib currently includes 2 join implementations. 
 The initial patch was generated from the Solr 4.3 tag. Because of changes in 
 the FieldCache API this patch will only build with Solr 4.2 or above.
 *PostFilterJoinQParserPlugin aka pjoin*
 The pjoin provides a join implementation that filters results in one core 
 based on the results of a search in another core. This is similar in 
 functionality to the JoinQParserPlugin but the implementation differs in a 
 couple of important ways.
 The first way is that the pjoin is designed to work with integer join keys 
 only. So, in order to use pjoin, integer join keys must be included in both 
 the to and from core.
 The second difference is that the pjoin builds memory structures that are 
 used to quickly connect the join keys. It also uses a custom SolrCache named 
 join to hold intermediate DocSets which are needed to build the join memory 
 structures. So, the pjoin will need more memory then the JoinQParserPlugin to 
 perform the join.
 The main advantage of the pjoin is that it can scale to join millions of keys 
 between cores.
 Because it's a PostFilter, it only needs to join records that match the main 
 query.
 The syntax of the pjoin is the same as the JoinQParserPlugin except that the 
 plugin is referenced by the string pjoin rather then join.
 fq=\{!pjoin fromCore=collection2 from=id_i to=id_i\}user:customer1
 The example filter query above will search the fromCore (collection2) for 
 user:customer1. This query will generate a list of values from the from 
 field that will be used to filter the main query. Only records from the main 
 query, where the to field is present in the from list will be included in 
 the results.
 The solrconfig.xml in the main query core must contain the reference to the 
 pjoin.
 queryParser name=pjoin 
 class=org.apache.solr.joins.PostFilterJoinQParserPlugin/
 And the join contrib jars must be registed in the solrconfig.xml.
 lib dir=../../../dist/ regex=solr-joins-\d.*\.jar /
 The solrconfig.xml in the fromcore must have the join SolrCache configured.
  cache name=join
   class=solr.LRUCache
   size=4096
   initialSize=1024
   /
 *ValueSourceJoinParserPlugin aka vjoin*
 The second implementation is the ValueSourceJoinParserPlugin aka vjoin. 
 This implements a ValueSource function query that can return a value from a 
 second core based on join keys and limiting query. The limiting query can be 
 used to select a specific subset of data from the join core. This allows 
 customer specific relevance data to be stored in a separate core and then 
 joined in the main query.
 The vjoin is called using the vjoin function query. For example:
 bf=vjoin(fromCore, fromKey, fromVal, toKey, query)
 This example shows vjoin being called by the edismax boost function 
 parameter. This example will return the fromVal from the fromCore. The 
 fromKey and toKey are used to link the records from the main query to the 
 records in the fromCore. The query is used to select a specific set of 
 records to join with in fromCore.
 Currently the fromKey and toKey must be longs but this will change in future 
 versions. Like the pjoin, the join SolrCache is used to hold the join 
 memory structures.
 To configure the vjoin you must register the ValueSource plugin in the 
 solrconfig.xml as follows:
 valueSourceParser name=vjoin

[jira] [Comment Edited] (SOLR-4787) Join Contrib

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

Kranti Parisa edited comment on SOLR-4787 at 7/23/13 12:39 AM:
---

Joel,

I wanted to try implementing pjoin for the following use case.

masterCore = 1M keys (id field, long)
childCore = 5M documents (with parentid field, long, whose values are equal to
the values of id field in the masterCore

And syntax looks like
http://localhost:8180/solr/masterCore/select?q=title:afq=({!pjoin%20fromIndex=childCore%20from=parentid%20to=id%20v=$childQ})childQ=(fieldOne:somevalue
AND fieldTwo:[1 TO 100])

I am getting SyntaxError, but the same syntax works with normal join. any
ideas?

Also it seems currently pjoin supports only int keys, can you please update
pjoin to allow long keys

-
Kranti

was (Author: krantiparisa):
Joel,

I wanted to try implementing pjoin for the following use case.

masterCore = 1M keys (id field, long)
childCore = 5M documents (with parentid field, long, whose values are equal to
the values of id field in the masterCore

And syntax looks like
http://localhost:8180/solr/masterCore/select?q=title:afq=({!pjoin%20fromIndex=childCore%20from=parentid%20to=id%20v=$childQ})childQ=(fieldOne:somevalue
AND fieldTwo:[1 TO 100])

I am getting SyntaxError, but the same syntax works with normal join. any
ideas?

Also it seems currently pjoin supports only int keys, can you please update
pjoin to allow for longs

-
Kranti

Join Contrib

Key: SOLR-4787
URL: https://issues.apache.org/jira/browse/SOLR-4787
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 4.2.1
Reporter: Joel Bernstein
Priority: Minor
Fix For: 4.4

Attachments: SOLR-4787-deadlock-fix.patch, SOLR-4787.patch,
SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch,
SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch,
SOLR-4787.patch

This contrib provides a place where different join implementations can be
contributed to Solr. This contrib currently includes 2 join implementations.
The initial patch was generated from the Solr 4.3 tag. Because of changes in
the FieldCache API this patch will only build with Solr 4.2 or above.
*PostFilterJoinQParserPlugin aka pjoin*
The pjoin provides a join implementation that filters results in one core
based on the results of a search in another core. This is similar in
functionality to the JoinQParserPlugin but the implementation differs in a
couple of important ways.
The first way is that the pjoin is designed to work with integer join keys
only. So, in order to use pjoin, integer join keys must be included in both
the to and from core.
The second difference is that the pjoin builds memory structures that are
used to quickly connect the join keys. It also uses a custom SolrCache named
join to hold intermediate DocSets which are needed to build the join memory
structures. So, the pjoin will need more memory then the JoinQParserPlugin to
perform the join.
The main advantage of the pjoin is that it can scale to join millions of keys
between cores.
Because it's a PostFilter, it only needs to join records that match the main
query.
The syntax of the pjoin is the same as the JoinQParserPlugin except that the
plugin is referenced by the string pjoin rather then join.
fq=\{!pjoin fromCore=collection2 from=id_i to=id_i\}user:customer1
The example filter query above will search the fromCore (collection2) for
user:customer1. This query will generate a list of values from the from
field that will be used to filter the main query. Only records from the main
query, where the to field is present in the from list will be included in
the results.
The solrconfig.xml in the main query core must contain the reference to the
pjoin.
queryParser name=pjoin
class=org.apache.solr.joins.PostFilterJoinQParserPlugin/
And the join contrib jars must be registed in the solrconfig.xml.
lib dir=../../../dist/ regex=solr-joins-\d.*\.jar /
The solrconfig.xml in the fromcore must have the join SolrCache configured.
cache name=join
class=solr.LRUCache
size=4096
initialSize=1024
/
*ValueSourceJoinParserPlugin aka vjoin*
The second implementation is the ValueSourceJoinParserPlugin aka vjoin.
This implements a ValueSource function query that can return a value from a
second core based on join keys and limiting query. The limiting query can be
used to select a specific subset of data from the join core. This allows
customer specific relevance data to be stored in a separate core and then
joined in the main query.
The vjoin is called using the vjoin

[jira] [Comment Edited] (SOLR-4787) Join Contrib


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

Kranti Parisa edited comment on SOLR-4787 at 7/23/13 12:59 AM:
---

I did review the PostFilterJoinQParserPlugin code and found that it was 
expecting fromCore instead of fromIndex (like in normal Join)

after trying fromCore now getting the expected error related to INT keys, as 
my keys are Long.

- 
Kranti

  was (Author: krantiparisa):
I did review the PostFilterJoinQParserPlugin code and found that it was 
expecting fromCore instead of fromIndex (like in normal Join)

after trying fromCore now getting the expected error related to INT keys, as 
my keys are Long.
  
 Join Contrib
 

 Key: SOLR-4787
 URL: https://issues.apache.org/jira/browse/SOLR-4787
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 4.2.1
Reporter: Joel Bernstein
Priority: Minor
 Fix For: 4.4

 Attachments: SOLR-4787-deadlock-fix.patch, SOLR-4787.patch, 
 SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, 
 SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, 
 SOLR-4787.patch


 This contrib provides a place where different join implementations can be 
 contributed to Solr. This contrib currently includes 2 join implementations. 
 The initial patch was generated from the Solr 4.3 tag. Because of changes in 
 the FieldCache API this patch will only build with Solr 4.2 or above.
 *PostFilterJoinQParserPlugin aka pjoin*
 The pjoin provides a join implementation that filters results in one core 
 based on the results of a search in another core. This is similar in 
 functionality to the JoinQParserPlugin but the implementation differs in a 
 couple of important ways.
 The first way is that the pjoin is designed to work with integer join keys 
 only. So, in order to use pjoin, integer join keys must be included in both 
 the to and from core.
 The second difference is that the pjoin builds memory structures that are 
 used to quickly connect the join keys. It also uses a custom SolrCache named 
 join to hold intermediate DocSets which are needed to build the join memory 
 structures. So, the pjoin will need more memory then the JoinQParserPlugin to 
 perform the join.
 The main advantage of the pjoin is that it can scale to join millions of keys 
 between cores.
 Because it's a PostFilter, it only needs to join records that match the main 
 query.
 The syntax of the pjoin is the same as the JoinQParserPlugin except that the 
 plugin is referenced by the string pjoin rather then join.
 fq=\{!pjoin fromCore=collection2 from=id_i to=id_i\}user:customer1
 The example filter query above will search the fromCore (collection2) for 
 user:customer1. This query will generate a list of values from the from 
 field that will be used to filter the main query. Only records from the main 
 query, where the to field is present in the from list will be included in 
 the results.
 The solrconfig.xml in the main query core must contain the reference to the 
 pjoin.
 queryParser name=pjoin 
 class=org.apache.solr.joins.PostFilterJoinQParserPlugin/
 And the join contrib jars must be registed in the solrconfig.xml.
 lib dir=../../../dist/ regex=solr-joins-\d.*\.jar /
 The solrconfig.xml in the fromcore must have the join SolrCache configured.
  cache name=join
   class=solr.LRUCache
   size=4096
   initialSize=1024
   /
 *ValueSourceJoinParserPlugin aka vjoin*
 The second implementation is the ValueSourceJoinParserPlugin aka vjoin. 
 This implements a ValueSource function query that can return a value from a 
 second core based on join keys and limiting query. The limiting query can be 
 used to select a specific subset of data from the join core. This allows 
 customer specific relevance data to be stored in a separate core and then 
 joined in the main query.
 The vjoin is called using the vjoin function query. For example:
 bf=vjoin(fromCore, fromKey, fromVal, toKey, query)
 This example shows vjoin being called by the edismax boost function 
 parameter. This example will return the fromVal from the fromCore. The 
 fromKey and toKey are used to link the records from the main query to the 
 records in the fromCore. The query is used to select a specific set of 
 records to join with in fromCore.
 Currently the fromKey and toKey must be longs but this will change in future 
 versions. Like the pjoin, the join SolrCache is used to hold the join 
 memory structures.
 To configure the vjoin you must register the ValueSource plugin in the 
 solrconfig.xml as follows:
 valueSourceParser name=vjoin 
 class=org.apache.solr.joins.ValueSourceJoinParserPlugin /

--
This

[jira] [Commented] (SOLR-4787) Join Contrib


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

Kranti Parisa commented on SOLR-4787:
-

I did review the PostFilterJoinQParserPlugin code and found that it was 
expecting fromCore instead of fromIndex (like in normal Join)

after trying fromCore now getting the expected error related to INT keys, as 
my keys are Long.

 Join Contrib
 

 Key: SOLR-4787
 URL: https://issues.apache.org/jira/browse/SOLR-4787
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 4.2.1
Reporter: Joel Bernstein
Priority: Minor
 Fix For: 4.4

 Attachments: SOLR-4787-deadlock-fix.patch, SOLR-4787.patch, 
 SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, 
 SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, 
 SOLR-4787.patch


 This contrib provides a place where different join implementations can be 
 contributed to Solr. This contrib currently includes 2 join implementations. 
 The initial patch was generated from the Solr 4.3 tag. Because of changes in 
 the FieldCache API this patch will only build with Solr 4.2 or above.
 *PostFilterJoinQParserPlugin aka pjoin*
 The pjoin provides a join implementation that filters results in one core 
 based on the results of a search in another core. This is similar in 
 functionality to the JoinQParserPlugin but the implementation differs in a 
 couple of important ways.
 The first way is that the pjoin is designed to work with integer join keys 
 only. So, in order to use pjoin, integer join keys must be included in both 
 the to and from core.
 The second difference is that the pjoin builds memory structures that are 
 used to quickly connect the join keys. It also uses a custom SolrCache named 
 join to hold intermediate DocSets which are needed to build the join memory 
 structures. So, the pjoin will need more memory then the JoinQParserPlugin to 
 perform the join.
 The main advantage of the pjoin is that it can scale to join millions of keys 
 between cores.
 Because it's a PostFilter, it only needs to join records that match the main 
 query.
 The syntax of the pjoin is the same as the JoinQParserPlugin except that the 
 plugin is referenced by the string pjoin rather then join.
 fq=\{!pjoin fromCore=collection2 from=id_i to=id_i\}user:customer1
 The example filter query above will search the fromCore (collection2) for 
 user:customer1. This query will generate a list of values from the from 
 field that will be used to filter the main query. Only records from the main 
 query, where the to field is present in the from list will be included in 
 the results.
 The solrconfig.xml in the main query core must contain the reference to the 
 pjoin.
 queryParser name=pjoin 
 class=org.apache.solr.joins.PostFilterJoinQParserPlugin/
 And the join contrib jars must be registed in the solrconfig.xml.
 lib dir=../../../dist/ regex=solr-joins-\d.*\.jar /
 The solrconfig.xml in the fromcore must have the join SolrCache configured.
  cache name=join
   class=solr.LRUCache
   size=4096
   initialSize=1024
   /
 *ValueSourceJoinParserPlugin aka vjoin*
 The second implementation is the ValueSourceJoinParserPlugin aka vjoin. 
 This implements a ValueSource function query that can return a value from a 
 second core based on join keys and limiting query. The limiting query can be 
 used to select a specific subset of data from the join core. This allows 
 customer specific relevance data to be stored in a separate core and then 
 joined in the main query.
 The vjoin is called using the vjoin function query. For example:
 bf=vjoin(fromCore, fromKey, fromVal, toKey, query)
 This example shows vjoin being called by the edismax boost function 
 parameter. This example will return the fromVal from the fromCore. The 
 fromKey and toKey are used to link the records from the main query to the 
 records in the fromCore. The query is used to select a specific set of 
 records to join with in fromCore.
 Currently the fromKey and toKey must be longs but this will change in future 
 versions. Like the pjoin, the join SolrCache is used to hold the join 
 memory structures.
 To configure the vjoin you must register the ValueSource plugin in the 
 solrconfig.xml as follows:
 valueSourceParser name=vjoin 
 class=org.apache.solr.joins.ValueSourceJoinParserPlugin /

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-5043) hostanme lookup in SystemInfoHandler should be refactored to not block core (re)load


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

Hoss Man updated SOLR-5043:
---

Attachment: SOLR-5043.patch

Here's a quick and drity patch that spins up background thread to resolve the 
hostname.

in practice, this works fine -- startup and core reload times are short, and an 
error eventually gets logged by the background thread if/when the JVM gives up 
on resolving the hostname.

the hitch is: if we assume people might have bad DNS when running solr, we 
should probably also assume they might have bad DNS when running solr tests.  
As things stand on trunk today, that just means your tests run dog ass slow -- 
with this patch, the test will finish fast, but then the runner will fail 
because it treats this background DNS thread as a leak.

probably need to figure out a better way of dealing with this.

 hostanme lookup in SystemInfoHandler should be refactored to not block core 
 (re)load
 

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


 SystemInfoHandler currently lookups the hostname of the machine on it's init, 
 and caches for it's lifecycle -- there is a comment to the effect that the 
 reason for this is because on some machines (notably ones with wacky DNS 
 settings) looking up the hostname can take a long ass time in some JVMs...
 {noformat}
   // on some platforms, resolving canonical hostname can cause the thread
   // to block for several seconds if nameservices aren't available
   // so resolve this once per handler instance 
   //(ie: not static, so core reload will refresh)
 {noformat}
 But as we move forward with a lot more multi-core, solr-cloud, dynamically 
 updated instances, even paying this cost per core-reload is expensive.
 we should refactoring this so that SystemInfoHandler instances init 
 immediately, with some kind of lazy loading of the hostname info in a 
 background thread, (especially since hte only real point of having that info 
 here is for UI use so you cna keep track of what machine you are looking at)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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

hello

2013-07-22 Thread Arvind Srini

 http://erego.ro/hcnwz/vmwjtgjgjhogxwsitvwganem






















 Arvind Srini














 7/23/2013 2:24:19 AM

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

[jira] [Commented] (SOLR-5061) 4.4 refguide pages new solr.xml format


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

Erick Erickson commented on SOLR-5061:
--

Ok, first cut done. There are some configuration parameters that I have no real 
clue how to document. If anyone can take a quick look at these (or a long look 
and edit or comment what I should do) I'd appreciate it a lot. These pages:

https://cwiki.apache.org/confluence/display/solr/Solr+Cores+and+solr.xml
https://cwiki.apache.org/confluence/display/solr/Format+of+solr.xml
https://cwiki.apache.org/confluence/pages/editpage.action?pageId=33296227
https://cwiki.apache.org/confluence/display/solr/Moving+to+the+New+solr.xml+Format
https://cwiki.apache.org/confluence/display/solr/CoreAdminHandler+Parameters+and+Usage


 4.4 refguide pages new solr.xml format
 --

 Key: SOLR-5061
 URL: https://issues.apache.org/jira/browse/SOLR-5061
 Project: Solr
  Issue Type: Sub-task
  Components: documentation
Reporter: Hoss Man
Assignee: Erick Erickson
 Fix For: 4.4


 breaking off from parent issue...
 * 
 https://cwiki.apache.org/confluence/display/solr/Core+Admin+and+Configuring+solr.xml
 ** SOLR-4757: Change the example to use the new solr.xml format and core 
 discovery by directory structure. (Mark Miller)
 *** CT: There is a page on solr.xml: 
 https://cwiki.apache.org/confluence/display/solr/Core+Admin+and+Configuring+solr.xml.
  This should be updated to show the new format and still include information 
 on the old format for anyone with the old format who uses this guide for 
 reference.
 ** SOLR-4655: Add option to have Overseer assign generic node names so that 
 new addresses can host shards without naming confusion. (Mark Miller, Anshum 
 Gupta)
 *** CT: I think this only needs to be added to any new content for solr.xml 
 at 
 https://cwiki.apache.org/confluence/display/solr/Core+Admin+and+Configuring+solr.xml
 It should also be noted that cassandra posted some additional deailed 
 suggests in a comment on the existing page in the ref guide...
 https://cwiki.apache.org/confluence/display/solr/Core+Admin+and+Configuring+solr.xml?focusedCommentId=33296160#comment-33296160

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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

Release documentation for new solr.xml formats needs more eyes.

2013-07-22 Thread Erick Erickson

These pages could use some review. In particular I don't have some
definitions for some of the solr.xml options documented, look for ???
particularly in the Format of solr.xml and

https://cwiki.apache.org/confluence/display/solr/Solr+Cores+and+solr.xml
https://cwiki.apache.org/confluence/display/solr/Format+of+solr.xml
https://cwiki.apache.org/confluence/display/solr/Legacy+solr.xml+Configuration
https://cwiki.apache.org/confluence/display/solr/Moving+to+the+New+solr.xml+Format
https://cwiki.apache.org/confluence/display/solr/CoreAdminHandler+Parameters+and+Usage

The Moving to the new Solr.xml Format is particularly weak, but I'm
starting to get past the point where I can concentrate so I'll look at
it again in the morning.

Thanks,
Erick

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

[jira] [Comment Edited] (SOLR-5061) 4.4 refguide pages new solr.xml format


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

Erick Erickson edited comment on SOLR-5061 at 7/23/13 1:35 AM:
---

Ok, first cut done. There are some configuration parameters that I have no real 
clue how to document. If anyone can take a quick look at these (or a long look 
and edit or comment what I should do) I'd appreciate it a lot. These pages:

https://cwiki.apache.org/confluence/display/solr/Solr+Cores+and+solr.xml
https://cwiki.apache.org/confluence/display/solr/Format+of+solr.xml
https://cwiki.apache.org/confluence/display/solr/Legacy+solr.xml+Configuration
https://cwiki.apache.org/confluence/display/solr/Moving+to+the+New+solr.xml+Format
https://cwiki.apache.org/confluence/display/solr/CoreAdminHandler+Parameters+and+Usage

  was (Author: erickerickson):
Ok, first cut done. There are some configuration parameters that I have no 
real clue how to document. If anyone can take a quick look at these (or a long 
look and edit or comment what I should do) I'd appreciate it a lot. These pages:

https://cwiki.apache.org/confluence/display/solr/Solr+Cores+and+solr.xml
https://cwiki.apache.org/confluence/display/solr/Format+of+solr.xml
https://cwiki.apache.org/confluence/pages/editpage.action?pageId=33296227
https://cwiki.apache.org/confluence/display/solr/Moving+to+the+New+solr.xml+Format
https://cwiki.apache.org/confluence/display/solr/CoreAdminHandler+Parameters+and+Usage

  
 4.4 refguide pages new solr.xml format
 --

 Key: SOLR-5061
 URL: https://issues.apache.org/jira/browse/SOLR-5061
 Project: Solr
  Issue Type: Sub-task
  Components: documentation
Reporter: Hoss Man
Assignee: Erick Erickson
 Fix For: 4.4


 breaking off from parent issue...
 * 
 https://cwiki.apache.org/confluence/display/solr/Core+Admin+and+Configuring+solr.xml
 ** SOLR-4757: Change the example to use the new solr.xml format and core 
 discovery by directory structure. (Mark Miller)
 *** CT: There is a page on solr.xml: 
 https://cwiki.apache.org/confluence/display/solr/Core+Admin+and+Configuring+solr.xml.
  This should be updated to show the new format and still include information 
 on the old format for anyone with the old format who uses this guide for 
 reference.
 ** SOLR-4655: Add option to have Overseer assign generic node names so that 
 new addresses can host shards without naming confusion. (Mark Miller, Anshum 
 Gupta)
 *** CT: I think this only needs to be added to any new content for solr.xml 
 at 
 https://cwiki.apache.org/confluence/display/solr/Core+Admin+and+Configuring+solr.xml
 It should also be noted that cassandra posted some additional deailed 
 suggests in a comment on the existing page in the ref guide...
 https://cwiki.apache.org/confluence/display/solr/Core+Admin+and+Configuring+solr.xml?focusedCommentId=33296160#comment-33296160

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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

hey.

2013-07-22 Thread Arvind Srini

 http://frenchpornographer.com/cilj/mgbgagpdugov










 Arvind Srini

















 7/23/2013 3:20:00 AM

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

[jira] [Updated] (SOLR-4787) Join Contrib


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

Kranti Parisa updated SOLR-4787:


Attachment: SOLR-4787-pjoin-long-keys.patch

Update PostFilterJoinQParserPlugin to support LONG keys

 Join Contrib
 

 Key: SOLR-4787
 URL: https://issues.apache.org/jira/browse/SOLR-4787
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 4.2.1
Reporter: Joel Bernstein
Priority: Minor
 Fix For: 4.4

 Attachments: SOLR-4787-deadlock-fix.patch, SOLR-4787.patch, 
 SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, 
 SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, 
 SOLR-4787.patch, SOLR-4787-pjoin-long-keys.patch


 This contrib provides a place where different join implementations can be 
 contributed to Solr. This contrib currently includes 2 join implementations. 
 The initial patch was generated from the Solr 4.3 tag. Because of changes in 
 the FieldCache API this patch will only build with Solr 4.2 or above.
 *PostFilterJoinQParserPlugin aka pjoin*
 The pjoin provides a join implementation that filters results in one core 
 based on the results of a search in another core. This is similar in 
 functionality to the JoinQParserPlugin but the implementation differs in a 
 couple of important ways.
 The first way is that the pjoin is designed to work with integer join keys 
 only. So, in order to use pjoin, integer join keys must be included in both 
 the to and from core.
 The second difference is that the pjoin builds memory structures that are 
 used to quickly connect the join keys. It also uses a custom SolrCache named 
 join to hold intermediate DocSets which are needed to build the join memory 
 structures. So, the pjoin will need more memory then the JoinQParserPlugin to 
 perform the join.
 The main advantage of the pjoin is that it can scale to join millions of keys 
 between cores.
 Because it's a PostFilter, it only needs to join records that match the main 
 query.
 The syntax of the pjoin is the same as the JoinQParserPlugin except that the 
 plugin is referenced by the string pjoin rather then join.
 fq=\{!pjoin fromCore=collection2 from=id_i to=id_i\}user:customer1
 The example filter query above will search the fromCore (collection2) for 
 user:customer1. This query will generate a list of values from the from 
 field that will be used to filter the main query. Only records from the main 
 query, where the to field is present in the from list will be included in 
 the results.
 The solrconfig.xml in the main query core must contain the reference to the 
 pjoin.
 queryParser name=pjoin 
 class=org.apache.solr.joins.PostFilterJoinQParserPlugin/
 And the join contrib jars must be registed in the solrconfig.xml.
 lib dir=../../../dist/ regex=solr-joins-\d.*\.jar /
 The solrconfig.xml in the fromcore must have the join SolrCache configured.
  cache name=join
   class=solr.LRUCache
   size=4096
   initialSize=1024
   /
 *ValueSourceJoinParserPlugin aka vjoin*
 The second implementation is the ValueSourceJoinParserPlugin aka vjoin. 
 This implements a ValueSource function query that can return a value from a 
 second core based on join keys and limiting query. The limiting query can be 
 used to select a specific subset of data from the join core. This allows 
 customer specific relevance data to be stored in a separate core and then 
 joined in the main query.
 The vjoin is called using the vjoin function query. For example:
 bf=vjoin(fromCore, fromKey, fromVal, toKey, query)
 This example shows vjoin being called by the edismax boost function 
 parameter. This example will return the fromVal from the fromCore. The 
 fromKey and toKey are used to link the records from the main query to the 
 records in the fromCore. The query is used to select a specific set of 
 records to join with in fromCore.
 Currently the fromKey and toKey must be longs but this will change in future 
 versions. Like the pjoin, the join SolrCache is used to hold the join 
 memory structures.
 To configure the vjoin you must register the ValueSource plugin in the 
 solrconfig.xml as follows:
 valueSourceParser name=vjoin 
 class=org.apache.solr.joins.ValueSourceJoinParserPlugin /

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Comment Edited] (SOLR-4787) Join Contrib