date:20140324


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

Shalin Shekhar Mangar updated SOLR-5466:


Attachment: SOLR-5466.patch

Patch updated to trunk with some changes:
# Removed incorrect use of Arrays.binarySearch in OCP.getCollectionStatus
# Renamed 'status' to 'clusterstatus'. This is necessary because SOLR-5466 
added a 'status' API for request status. Renamed all variables, enum fields too 
appropriately.

 Add List Collections functionality to Collections API
 -

 Key: SOLR-5466
 URL: https://issues.apache.org/jira/browse/SOLR-5466
 Project: Solr
  Issue Type: Sub-task
  Components: scripts and tools, SolrCloud
 Environment: All
Reporter: Dave Seltzer
Assignee: Shalin Shekhar Mangar
Priority: Minor
  Labels: api, collections, rest
 Attachments: SOLR-5466.patch, SOLR-5466.patch, SOLR-5466.patch, 
 SOLR-5466.patch, SOLR-5466.patch


 The collections API lets you add, delete and modify existing collections. At 
 the moment the API does not let you get a list of current collections or view 
 information about a specific collection.
 The workaround is the use the Zookeeper API to get the list. This makes the 
 Collections API harder to work with. 
 Adding an action=LIST would significantly improve the function of this API.



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

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

[JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.8.0) - Build # 3810 - Failure!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/3810/
Java: 32bit/jdk1.8.0 -client -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 31569 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.7
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.7
[forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.1
[forbidden-apis] Reading API signatures: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\tools\forbiddenApis\base.txt
[forbidden-apis] Reading API signatures: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\tools\forbiddenApis\servlet-api.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning for API signatures and dependencies...
[forbidden-apis] Forbidden method invocation: 
java.util.concurrent.Executors#newFixedThreadPool(int) [Spawns threads with 
vague names; use a custom thread factory (Lucene's NamedThreadFactory, Solr's 
DefaultSolrThreadFactory) and name threads so that you can tell (by its name) 
which executor it is associated with]
[forbidden-apis]   in org.apache.solr.client.solrj.impl.HttpSolrServer 
(HttpSolrServer.java:237)
[forbidden-apis] Scanned 361 (and 462 related) class file(s) for forbidden API 
invocations (in 0.29s), 1 error(s).

BUILD FAILED
C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:467: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:70: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\solr\build.xml:271: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\solr\common-build.xml:473:
 Check for forbidden API calls failed, see log.

Total time: 92 minutes 41 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 32bit/jdk1.8.0 -client -XX:+UseParallelGC
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure



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

[jira] [Commented] (SOLR-2649) MM ignored in edismax queries with operators

2014-03-24 Thread ASF subversion and git services (JIRA)


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

Jan Høydahl commented on SOLR-2649:
---

Any comments on the current patch? All tests pass. If there are certain boolean 
queries that you fear this patch will make worse than it is today then please 
add a unit test for it.

 MM ignored in edismax queries with operators
 

 Key: SOLR-2649
 URL: https://issues.apache.org/jira/browse/SOLR-2649
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Reporter: Magnus Bergmark
Priority: Minor
 Fix For: 4.8, 5.0

 Attachments: SOLR-2649.diff, SOLR-2649.patch


 Hypothetical scenario:
   1. User searches for stocks oil gold with MM set to 50%
   2. User adds -stockings to the query: stocks oil gold -stockings
   3. User gets no hits since MM was ignored and all terms where AND-ed 
 together
 The behavior seems to be intentional, although the reason why is never 
 explained:
   // For correct lucene queries, turn off mm processing if there
   // were explicit operators (except for AND).
   boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0; 
 (lines 232-234 taken from 
 tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java)
 This makes edismax unsuitable as an replacement to dismax; mm is one of the 
 primary features of dismax.



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

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

[jira] [Commented] (LUCENE-5356) more generic lucene-morfologik integration

2014-03-24 Thread Michal Hlavac (JIRA)


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

Michal Hlavac commented on LUCENE-5356:
---

Hi Ahmet,
I think this is not good way how to ask quetions like this. Please use lucene's 
user mailing list. Thanks

 more generic lucene-morfologik integration
 --

 Key: LUCENE-5356
 URL: https://issues.apache.org/jira/browse/LUCENE-5356
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/analysis
Affects Versions: 4.6
Reporter: Michal Hlavac
Assignee: Dawid Weiss
Priority: Minor
  Labels: newbie, patch
 Fix For: 4.8, 5.0

 Attachments:  LUCENE-5356.patch, LUCENE-5356.patch, LUCENE-5356.patch


 I have little proposal for morfologik lucene module. Current module is 
 tightly coupled with polish DICTIONARY enumeration.
 But other people (like me) can build own dictionaries to FSA and use it with 
 lucene. 
 You can find proposal in attachment and also example usage in analyzer 
 (SlovakLemmaAnalyzer).
 It uses dictionary property as String resource from classpath, not 
 enumeration.
 One change is, that dictionary variable must be set in MofologikFilterFactory 
 (no default value).



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

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

[jira] [Comment Edited] (LUCENE-5356) more generic lucene-morfologik integration

2014-03-24 Thread Michal Hlavac (JIRA)

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

Michal Hlavac edited comment on LUCENE-5356 at 3/24/14 10:17 AM:
-

Hi Ahmet,
I think this is not right way how to ask quetions like this. Please use
lucene's user mailing list. Thanks

was (Author: hlavki):
Hi Ahmet,
I think this is not good way how to ask quetions like this. Please use lucene's
user mailing list. Thanks

more generic lucene-morfologik integration
--

Key: LUCENE-5356
URL: https://issues.apache.org/jira/browse/LUCENE-5356
Project: Lucene - Core
Issue Type: Improvement
Components: modules/analysis
Affects Versions: 4.6
Reporter: Michal Hlavac
Assignee: Dawid Weiss
Priority: Minor
Labels: newbie, patch
Fix For: 4.8, 5.0

Attachments: LUCENE-5356.patch, LUCENE-5356.patch, LUCENE-5356.patch

I have little proposal for morfologik lucene module. Current module is
tightly coupled with polish DICTIONARY enumeration.
But other people (like me) can build own dictionaries to FSA and use it with
lucene.
You can find proposal in attachment and also example usage in analyzer
(SlovakLemmaAnalyzer).
It uses dictionary property as String resource from classpath, not
enumeration.
One change is, that dictionary variable must be set in MofologikFilterFactory
(no default value).

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

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

[jira] [Commented] (LUCENE-5370) Sorting Facets on CategoryPath (Label)

2014-03-24 Thread Massimo Ferrario (JIRA)


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

Massimo Ferrario commented on LUCENE-5370:
--

Yes, I did exaclty what you suggested: I created a simple comparator for 
FacetResultNode so I can re-order list using string label, after computed the 
top-n facet.

Yes, I have d unique value per document, but my facet are strings (for example 
Company Name) not number.
Thanks for suggestions.


 Sorting Facets on CategoryPath (Label)
 --

 Key: LUCENE-5370
 URL: https://issues.apache.org/jira/browse/LUCENE-5370
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/facet
Affects Versions: 4.6
Reporter: Rob Audenaerde
  Labels: features

 Facet support sorting through {{FacetRequest.SortOrder}}. This is used in the 
 {{ResultSortUtils}}. For my application it would be very nice if the facets 
 can also be sorted on their label. 
 I think this could be accomplished by altering {{FacetRequest}} with an extra 
 enum {{SortType}}, and two extra {{Heap}}  in {{ResultSortUtils}} which 
 instead of comparing the double value, compare the CategoryPath.
 What do you think of this idea? Or could the same behaviour be accomplished 
 in a different way already?
 (btw: I tried building this patch on the trunk of lucene5.0; but I couldn't 
 get the maven build to build correctly. I will try again lateron on the 4.6 
 branch.



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

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

[jira] [Commented] (SOLR-5893) On restarting overseer designate , move itself to front of the queue


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

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

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

SOLR-5893 eliminating unnecessary NoNodeException logging

 On restarting overseer designate , move itself to front of the queue 
 -

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


 When an overseer designate is killed and restarted move to the front of the 
 queue 



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

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

[jira] [Commented] (SOLR-4470) Support for basic http auth in internal solr requests

2014-03-24 Thread ASF subversion and git services (JIRA)

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

Jan Høydahl commented on SOLR-4470:
---

bq. Why do we need our own custom AuthCredentials interface? Could we use
something from JAAS?
Public and private credential classes are not part of the core JAAS class
library. Any class can represent a credential.
([link|http://docs.oracle.com/javase/7/docs/technotes/guides/security/jaas/JAASRefGuide.html#Credentials])

bq. Do we really need to pass credentials around everywhere? What David Webster
described sounds like a much cleaner approach?
To support pure allow-all internal requests we could do without passing auth
on as many methods. But this patch also supports propagating creds from outer
requests so that the app-server can be setup to e.g. allow queries from user A,
updates from user B and collection creation from user C based on their
username/password. See https://wiki.apache.org/solr/SolrSecurity for more.

The patch submitter had this requirement for a concrete customer currently in
production with this patch, and in my opinion that's an excellent background
for a patch. If there are ways to support the same functionality but reducing
the patch footprint that would also be nice of course.

Support for basic http auth in internal solr requests
-

Key: SOLR-4470
URL: https://issues.apache.org/jira/browse/SOLR-4470
Project: Solr
Issue Type: New Feature
Components: clients - java, multicore, replication (java), SolrCloud
Affects Versions: 4.0
Reporter: Per Steffensen
Assignee: Jan Høydahl
Labels: authentication, https, solrclient, solrcloud, ssl
Fix For: 5.0

Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch,
SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch,
SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch,
SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch,
SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch,
SOLR-4470_trunk_r1568857.patch

We want to protect any HTTP-resource (url). We want to require credentials no
matter what kind of HTTP-request you make to a Solr-node.
It can faily easy be acheived as described on
http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes
also make internal request to other Solr-nodes, and for it to work
credentials need to be provided here also.
Ideally we would like to forward credentials from a particular request to
all the internal sub-requests it triggers. E.g. for search and update
request.
But there are also internal requests
* that only indirectly/asynchronously triggered from outside requests (e.g.
shard creation/deletion/etc based on calls to the Collection API)
* that do not in any way have relation to an outside super-request (e.g.
replica synching stuff)
We would like to aim at a solution where original credentials are
forwarded when a request directly/synchronously trigger a subrequest, and
fallback to a configured internal credentials for the
asynchronous/non-rooted requests.
In our solution we would aim at only supporting basic http auth, but we would
like to make a framework around it, so that not to much refactoring is
needed if you later want to make support for other kinds of auth (e.g. digest)
We will work at a solution but create this JIRA issue early in order to get
input/comments from the community as early as possible.

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

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

[jira] [Commented] (SOLR-5893) On restarting overseer designate , move itself to front of the queue


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

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

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

SOLR-5893 On restarting overseer designate , move itself to front of the queue

 On restarting overseer designate , move itself to front of the queue 
 -

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


 When an overseer designate is killed and restarted move to the front of the 
 queue 



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

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

[jira] [Commented] (SOLR-4478) Allow cores to specify a named config set in non-SolrCloud mode

2014-03-24 Thread ASF subversion and git services (JIRA)

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

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

Commit 1580814 from [~romseygeek] in branch 'dev/trunk'
[ https://svn.apache.org/r1580814 ]

SOLR-4478: Allow cores to use configurations specified outside their instance
directory

Allow cores to specify a named config set in non-SolrCloud mode
---

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: Alan Woodward
Attachments: SOLR-4478-take2.patch, SOLR-4478-take2.patch,
SOLR-4478-take2.patch, SOLR-4478-take2.patch, 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?

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

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

[jira] [Commented] (SOLR-5228) Deprecate fields and types tags in schema.xml

2014-03-24 Thread Benson Margulies (JIRA)


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

Benson Margulies commented on SOLR-5228:


Allow the person extending the schema to provide a, well, extended schema.



 Deprecate fields and types tags in schema.xml
 -

 Key: SOLR-5228
 URL: https://issues.apache.org/jira/browse/SOLR-5228
 Project: Solr
  Issue Type: Improvement
  Components: Schema and Analysis
Reporter: Hoss Man
Assignee: Erick Erickson
 Fix For: 4.8, 5.0

 Attachments: SOLR-5228.patch, SOLR-5228.patch


 On the solr-user mailing list, Nutan recently mentioned spending days trying 
 to track down a problem that turned out to be because he had attempted to add 
 a {{dynamicField .. /}} that was outside of the {{fields}} block in his 
 schema.xml -- Solr was just silently ignoring it.
 We have made improvements in other areas of config validation by generating 
 statup errors when tags/attributes are found that are not expected -- but in 
 this case i think we should just stop expecting/requiring that the 
 {{fields}} and {{types}} tags will be used to group these sorts of 
 things.  I think schema.xml parsing should just start ignoring them and only 
 care about finding the {{field}}, {{dynamicField}}, and {{fieldType}} 
 tags wherever they may be.
 If people want to keep using them, fine.  If people want to mix fieldTypes 
 and fields side by side (perhaps specify a fieldType, then list all the 
 fields using it) fine.  I don't see any value in forcing people to use them, 
 but we definitely shouldn't leave things the way they are with otherwise 
 perfectly valid field/type declarations being silently ignored.
 ---
 I'll take this on unless i see any objections.



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

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

[jira] [Commented] (SOLR-4478) Allow cores to specify a named config set in non-SolrCloud mode

2014-03-24 Thread ASF subversion and git services (JIRA)

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

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

Commit 1580817 from [~romseygeek] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1580817 ]

SOLR-4478: Allow cores to use configurations specified outside their instance
directory

Allow cores to specify a named config set in non-SolrCloud mode
---

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

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

[jira] [Commented] (SOLR-4478) Allow cores to specify a named config set in non-SolrCloud mode

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

Alan Woodward commented on SOLR-4478:
-

OK, so tomorrow turned into next week, but there we go. I'll hold the JIRA
open until I've written something for the reference guide.

Allow cores to specify a named config set in non-SolrCloud mode
---

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: Alan Woodward
Fix For: 4.8, 5.0

Attachments: SOLR-4478-take2.patch, SOLR-4478-take2.patch,
SOLR-4478-take2.patch, SOLR-4478-take2.patch, SOLR-4478.patch, SOLR-4478.patch

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

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

[jira] [Updated] (SOLR-4478) Allow cores to specify a named config set in non-SolrCloud mode

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

Alan Woodward updated SOLR-4478:

Fix Version/s: 5.0
4.8

Allow cores to specify a named config set in non-SolrCloud mode
---

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: Alan Woodward
Fix For: 4.8, 5.0

Attachments: SOLR-4478-take2.patch, SOLR-4478-take2.patch,
SOLR-4478-take2.patch, SOLR-4478-take2.patch, SOLR-4478.patch, SOLR-4478.patch

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

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

[jira] [Commented] (SOLR-4478) Allow cores to specify a named config set in non-SolrCloud mode

2014-03-24 Thread Erick Erickson (JIRA)

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

Erick Erickson commented on SOLR-4478:
--

Thanks! I think this'll be cool.

I can hardly complain, I didn't get around to this for a year :)..

Probably should have an entry in the new CWiki form of the documentation too?
I'm finding it _extremely_ helpful to be able to download all that in PDF, have
a single place to search the current docs (rather than Google and get something
from Solr 1.4) etc many kudos to Cassandra Co.

Allow cores to specify a named config set in non-SolrCloud mode
---

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: Alan Woodward
Fix For: 4.8, 5.0

Attachments: SOLR-4478-take2.patch, SOLR-4478-take2.patch,
SOLR-4478-take2.patch, SOLR-4478-take2.patch, SOLR-4478.patch, SOLR-4478.patch

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

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

[jira] [Commented] (SOLR-5228) Deprecate fields and types tags in schema.xml

2014-03-24 Thread Erick Erickson (JIRA)

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

Erick Erickson commented on SOLR-5228:
--

bq: Allow the person extending the schema to provide a, well, extended schema.

Now, in order to run, we either have to
1 incorporate each and every extension anyone in the world wants to write into
our releases
or
2 require everyone who doesn't want to/can't give their extension back to
Apache to maintain their own DTD forevermore, updating it at each release of
Solr they want to upgrade.

Don't get me wrong, I have complete and total sympathy with the end goal here.
If we can solve this in a way that extends we could save users countless hours,
your point about multivalued .vs. multiValued is well taken indeed. I suppose
trading that off against the added pain caused by invalidating current tools is
a judgement call.

And I don't know that much about extending DTDs. Is there a way to do something
similar to xinclude? Or shutting off validation. Hmmm, I rather like that one
at first glance, although I'm not sure where to specify it. Perhaps a default
of on, expert users could turn validation off if they added custom stuff or
decide to keep their own copy of the DTD up to date.

How much you want to bet the first time we tried to run tests we'd find some of
our test schemas have errors?

Deprecate fields and types tags in schema.xml
-

Key: SOLR-5228
URL: https://issues.apache.org/jira/browse/SOLR-5228
Project: Solr
Issue Type: Improvement
Components: Schema and Analysis
Reporter: Hoss Man
Assignee: Erick Erickson
Fix For: 4.8, 5.0

Attachments: SOLR-5228.patch, SOLR-5228.patch

On the solr-user mailing list, Nutan recently mentioned spending days trying
to track down a problem that turned out to be because he had attempted to add
a {{dynamicField .. /}} that was outside of the {{fields}} block in his
schema.xml -- Solr was just silently ignoring it.
We have made improvements in other areas of config validation by generating
statup errors when tags/attributes are found that are not expected -- but in
this case i think we should just stop expecting/requiring that the
{{fields}} and {{types}} tags will be used to group these sorts of
things. I think schema.xml parsing should just start ignoring them and only
care about finding the {{field}}, {{dynamicField}}, and {{fieldType}}
tags wherever they may be.
If people want to keep using them, fine. If people want to mix fieldTypes
and fields side by side (perhaps specify a fieldType, then list all the
fields using it) fine. I don't see any value in forcing people to use them,
but we definitely shouldn't leave things the way they are with otherwise
perfectly valid field/type declarations being silently ignored.
---
I'll take this on unless i see any objections.

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

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

[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0) - Build # 3889 - Failure!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/3889/
Java: 32bit/jdk1.8.0 -client -XX:+UseConcMarkSweepGC

4 tests failed.
FAILED:  org.apache.solr.core.TestConfigSets.testConfigSetServiceFindsConfigSets

Error Message:
 Expected: is 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\.\findsConfigSets\/core1/data/
  got: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\.\findsConfigSets\/core1\data\
 

Stack Trace:
java.lang.AssertionError: 
Expected: is 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\.\findsConfigSets\/core1/data/
 got: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\.\findsConfigSets\/core1\data\

at 
__randomizedtesting.SeedInfo.seed([E78F82B20CCDB30A:3A81DF7A98469578]:0)
at org.junit.Assert.assertThat(Assert.java:780)
at org.junit.Assert.assertThat(Assert.java:738)
at 
org.apache.solr.core.TestConfigSets.testConfigSetServiceFindsConfigSets(TestConfigSets.java:66)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1617)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:826)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:862)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:876)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
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:359)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:783)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:443)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:835)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:771)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:782)
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 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)

[jira] [Commented] (SOLR-5890) Delete silently fails if not sent to shard where document was added

2014-03-24 Thread Peter Inglesby (JIRA)


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

Peter Inglesby commented on SOLR-5890:
--

Mark, can you point us to where the SolrCloud router configuration is 
documented?

 Delete silently fails if not sent to shard where document was added
 ---

 Key: SOLR-5890
 URL: https://issues.apache.org/jira/browse/SOLR-5890
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.7
 Environment: Debian 7.4.
Reporter: Peter Inglesby
 Fix For: 4.8, 5.0, 4.7.1


 We have SolrCloud set up with two shards, each with a leader and a replica.  
 We use haproxy to distribute requests between the four nodes.
 Regardless of which node we send an add request to, following a commit, the 
 newly-added document is returned in a search, as expected.
 However, we can only delete a document if the delete request is sent to a 
 node in the shard where the document was added.  If we send the delete 
 request to a node in the other shard (and then send a commit) the document is 
 not deleted.  Such a delete request will get a 200 response, with the 
 following body:
   {'responseHeader'={'status'=0,'QTime'=7}}
 Apart from the the very low QTime, this is indistinguishable from a 
 successful delete.



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

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

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_60-ea-b10) - Build # 9891 - Failure!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9891/
Java: 32bit/jdk1.7.0_60-ea-b10 -client -XX:+UseSerialGC

1 tests failed.
REGRESSION:  
org.apache.solr.client.solrj.impl.CloudSolrServerTest.testDistribSearch

Error Message:
java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 
127.0.0.1:42847 within 45000 ms

Stack Trace:
org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: 
Could not connect to ZooKeeper 127.0.0.1:42847 within 45000 ms
at 
__randomizedtesting.SeedInfo.seed([675104015BF2F8CD:E6B78A192CAD98F1]:0)
at 
org.apache.solr.common.cloud.SolrZkClient.init(SolrZkClient.java:150)
at 
org.apache.solr.common.cloud.SolrZkClient.init(SolrZkClient.java:101)
at 
org.apache.solr.common.cloud.SolrZkClient.init(SolrZkClient.java:91)
at 
org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:91)
at 
org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:85)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.setUp(AbstractDistribZkTestBase.java:77)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.setUp(AbstractFullDistribZkTestBase.java:201)
at 
org.apache.solr.client.solrj.impl.CloudSolrServerTest.setUp(CloudSolrServerTest.java:95)
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:1617)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:860)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:876)
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:359)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:783)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:443)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:835)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:771)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:782)
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 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)

[no subject]

2014-03-24 Thread Qiang Zhou

http://zarabiaj-internetowo.pl/wp-includes/js/tinymce/plugins/inlinepopups/skins/clearlooks2/img/pinit.php?svhrws1721ezrx

Qiang Zhou
yczhouqi...@yahoo.com

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

[jira] [Commented] (SOLR-5228) Deprecate fields and types tags in schema.xml

2014-03-24 Thread Benson Margulies (JIRA)

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

Benson Margulies commented on SOLR-5228:

DTD's are useless. We need to pick one of W3C XML Schema or RNG. RNG is a lot
easier to work with. Schematron is another possibility, but I have no
experience. See
http://docs.oracle.com/javase/7/docs/api/javax/xml/validation/package-summary.html.

Choices are:

* validation is easy to disable; people who customize disable it
* customizers take the entire schema, add to it, and provide their added one.
Not so good for multiples.
* customizers are constrained to use _namespaces_ -- you customize, you add an
XML namespace, and you provide a schema for your namespace.

Of course the first time we try this we'll find problems in the test schemas.

Has anyone done anything in this area that I could start from if I was inclined
to try to work on this?

Deprecate fields and types tags in schema.xml
-

Key: SOLR-5228
URL: https://issues.apache.org/jira/browse/SOLR-5228
Project: Solr
Issue Type: Improvement
Components: Schema and Analysis
Reporter: Hoss Man
Assignee: Erick Erickson
Fix For: 4.8, 5.0

Attachments: SOLR-5228.patch, SOLR-5228.patch

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

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

[jira] [Updated] (SOLR-4903) Solr sends all doc ids to all shards in the query counting facets

2014-03-24 Thread Dmitry Kan (JIRA)


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

Dmitry Kan updated SOLR-4903:
-

Labels: patch  (was: )

 Solr sends all doc ids to all shards in the query counting facets
 -

 Key: SOLR-4903
 URL: https://issues.apache.org/jira/browse/SOLR-4903
 Project: Solr
  Issue Type: Improvement
  Components: search
Affects Versions: 3.4, 4.3, 4.3.1
Reporter: Dmitry Kan

 Setup: front end solr and shards.
 Summary: solr frontend sends all doc ids received from QueryComponent to all 
 shards which causes POST request buffer size overflow.
 Symptoms:
 The query is: http://pastebin.com/0DndK1Cs
 I have omitted the shards parameter.
 The router log: http://pastebin.com/FTVH1WF3
 Notice the port of a shard, that is affected. That port changes all the time, 
 even for the same request
 The log entry is prepended with lines:
 SEVERE: org.apache.solr.common.SolrException: Internal Server Error
 Internal Server Error
 (they are not in the pastebin link)
 The shard log: http://pastebin.com/exwCx3LX
 Suggestion: change the data structure in FacetComponent to send only doc ids 
 that belong to a shard and not a concatenation of all doc ids.
 Why is this important: for scaling. Adding more shards will result in 
 overflowing the POST request buffer at some point anyway.



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

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

[jira] [Updated] (SOLR-4903) Solr sends all doc ids to all shards in the query counting facets

2014-03-24 Thread Dmitry Kan (JIRA)


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

Dmitry Kan updated SOLR-4903:
-

Labels:   (was: patch)

 Solr sends all doc ids to all shards in the query counting facets
 -

 Key: SOLR-4903
 URL: https://issues.apache.org/jira/browse/SOLR-4903
 Project: Solr
  Issue Type: Improvement
  Components: search
Affects Versions: 3.4, 4.3, 4.3.1
Reporter: Dmitry Kan

 Setup: front end solr and shards.
 Summary: solr frontend sends all doc ids received from QueryComponent to all 
 shards which causes POST request buffer size overflow.
 Symptoms:
 The query is: http://pastebin.com/0DndK1Cs
 I have omitted the shards parameter.
 The router log: http://pastebin.com/FTVH1WF3
 Notice the port of a shard, that is affected. That port changes all the time, 
 even for the same request
 The log entry is prepended with lines:
 SEVERE: org.apache.solr.common.SolrException: Internal Server Error
 Internal Server Error
 (they are not in the pastebin link)
 The shard log: http://pastebin.com/exwCx3LX
 Suggestion: change the data structure in FacetComponent to send only doc ids 
 that belong to a shard and not a concatenation of all doc ids.
 Why is this important: for scaling. Adding more shards will result in 
 overflowing the POST request buffer at some point anyway.



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

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

[jira] [Created] (SOLR-5902) Corecontainer level mbeans are not exposed

Noble Paul created SOLR-5902:


 Summary: Corecontainer level mbeans are not exposed 
 Key: SOLR-5902
 URL: https://issues.apache.org/jira/browse/SOLR-5902
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.8
Reporter: Noble Paul
 Fix For: 4.8, 5.0


The MBeans loadedby the CoreContainer resourceloader are not exposed via the 
MBeans API. eg:CoreAdminHandler,CollectionAdminHandler



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

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

[jira] [Assigned] (SOLR-5902) Corecontainer level mbeans are not exposed


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

Noble Paul reassigned SOLR-5902:


Assignee: Noble Paul

 Corecontainer level mbeans are not exposed 
 ---

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

 Attachments: SOLR-5902.patch


 The MBeans loadedby the CoreContainer resourceloader are not exposed via the 
 MBeans API. eg:CoreAdminHandler,CollectionAdminHandler



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

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

[jira] [Updated] (SOLR-5902) Corecontainer level mbeans are not exposed


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

Noble Paul updated SOLR-5902:
-

Attachment: SOLR-5902.patch

quick patch

 Corecontainer level mbeans are not exposed 
 ---

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

 Attachments: SOLR-5902.patch


 The MBeans loadedby the CoreContainer resourceloader are not exposed via the 
 MBeans API. eg:CoreAdminHandler,CollectionAdminHandler



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

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

[jira] [Commented] (SOLR-4351) JSON QParser integration


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

Jan Høydahl commented on SOLR-4351:
---

Any plans on continuing this work?

 JSON QParser integration
 

 Key: SOLR-4351
 URL: https://issues.apache.org/jira/browse/SOLR-4351
 Project: Solr
  Issue Type: New Feature
Reporter: Yonik Seeley
 Attachments: SOLR-4351.patch


 Our QParser framework currently gets parameters from localParams.  JSON 
 integration would allow specifying parameters to the parsers in JSON.



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

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

[jira] [Commented] (SOLR-5900) Improve ZkController#checkOverseerDesignate


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

Shalin Shekhar Mangar commented on SOLR-5900:
-

Noble fixed this with SOLR-5893 earlier today. I guess he didn't see this issue.

 Improve ZkController#checkOverseerDesignate
 ---

 Key: SOLR-5900
 URL: https://issues.apache.org/jira/browse/SOLR-5900
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Priority: Minor

 I see the following in the logs because the roles nodes does not exist - 
 seems that we should ensure this node exists or treat it's non existence as 
 being empty with no warning:
 {noformat}
 3955 T11 oasc.ZkController.checkOverseerDesignate WARN could not readd the 
 overseer designate  org.apache.zookeeper.KeeperException$NoNodeException: 
 KeeperErrorCode = NoNode for /roles.json
   at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
   at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
   at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1155)
   at 
 org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:276)
   at 
 org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:1)
   at 
 org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:73)
   at 
 org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:273)
   at 
 org.apache.solr.cloud.ZkController.checkOverseerDesignate(ZkController.java:1672)
   at org.apache.solr.core.CoreContainer.load(CoreContainer.java:350)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:200)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:147)
   at org.eclipse.jetty.servlet.FilterHolder.doStart(FilterHolder.java:119)
 {noformat}



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

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

[jira] [Commented] (SOLR-839) XML Query Parser support

2014-03-24 Thread ASF subversion and git services (JIRA)


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

Jan Høydahl commented on SOLR-839:
--

Any plans on continuing on this or should effort go into the JSON parser in 
SOLR-4351 instead?

 XML Query Parser support
 

 Key: SOLR-839
 URL: https://issues.apache.org/jira/browse/SOLR-839
 Project: Solr
  Issue Type: New Feature
  Components: query parsers
Affects Versions: 1.3
Reporter: Erik Hatcher
Assignee: Erik Hatcher
 Fix For: 5.0

 Attachments: SOLR-839-object-parser.patch, SOLR-839.patch, 
 lucene-xml-query-parser-2.4-dev.jar


 Lucene contrib includes a query parser that is able to create the 
 full-spectrum of Lucene queries, using an XML data structure.
 This patch adds xml query parser support to Solr.



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

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

[jira] [Commented] (LUCENE-5547) TestICUNormalizer2CharFilter test failure


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

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

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

LUCENE-5547: fix bug in offset correction

 TestICUNormalizer2CharFilter test failure
 -

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


 http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9864/
 ant test  -Dtestcase=TestICUNormalizer2CharFilter 
 -Dtests.method=testRandomStrings -Dtests.seed=B1B3ACAEE3F9218F 
 -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=ko_KR 
 -Dtests.timezone=Jamaica -Dtests.file.encoding=UTF-8



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

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

[jira] [Commented] (LUCENE-5547) TestICUNormalizer2CharFilter test failure

2014-03-24 Thread ASF subversion and git services (JIRA)


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

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

Commit 1580831 from [~rcmuir] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1580831 ]

LUCENE-5547: fix bug in offset correction

 TestICUNormalizer2CharFilter test failure
 -

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


 http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9864/
 ant test  -Dtestcase=TestICUNormalizer2CharFilter 
 -Dtests.method=testRandomStrings -Dtests.seed=B1B3ACAEE3F9218F 
 -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=ko_KR 
 -Dtests.timezone=Jamaica -Dtests.file.encoding=UTF-8



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

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

[jira] [Resolved] (LUCENE-5547) TestICUNormalizer2CharFilter test failure

2014-03-24 Thread Robert Muir (JIRA)


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

Robert Muir resolved LUCENE-5547.
-

Resolution: Fixed

I committed a fix for this. It also resolves the other test failure against 4.x 
branch that jenkins found.

 TestICUNormalizer2CharFilter test failure
 -

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


 http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9864/
 ant test  -Dtestcase=TestICUNormalizer2CharFilter 
 -Dtests.method=testRandomStrings -Dtests.seed=B1B3ACAEE3F9218F 
 -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=ko_KR 
 -Dtests.timezone=Jamaica -Dtests.file.encoding=UTF-8



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

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

Wiki edit permission

2014-03-24 Thread Terry Smith

Could I be allowed edit permissions on the wiki? I've signed up on the
Lucene and Solr wiki with the same name (TerrySmith) but am just emailing
lucene-dev to start.

--Terry

[jira] [Commented] (SOLR-4478) Allow cores to specify a named config set in non-SolrCloud mode

2014-03-24 Thread ASF subversion and git services (JIRA)

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

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

Commit 1580839 from [~romseygeek] in branch 'dev/trunk'
[ https://svn.apache.org/r1580839 ]

SOLR-4478: Test fix for Windows filepaths

Allow cores to specify a named config set in non-SolrCloud mode
---

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: Alan Woodward
Fix For: 4.8, 5.0

Attachments: SOLR-4478-take2.patch, SOLR-4478-take2.patch,
SOLR-4478-take2.patch, SOLR-4478-take2.patch, SOLR-4478.patch, SOLR-4478.patch

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

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

[jira] [Commented] (SOLR-4478) Allow cores to specify a named config set in non-SolrCloud mode

2014-03-24 Thread ASF subversion and git services (JIRA)

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

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

Commit 1580841 from [~romseygeek] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1580841 ]

SOLR-4478: Test fix for Windows filepaths

Allow cores to specify a named config set in non-SolrCloud mode
---

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: Alan Woodward
Fix For: 4.8, 5.0

Attachments: SOLR-4478-take2.patch, SOLR-4478-take2.patch,
SOLR-4478-take2.patch, SOLR-4478-take2.patch, SOLR-4478.patch, SOLR-4478.patch

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

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

[jira] [Commented] (SOLR-839) XML Query Parser support

2014-03-24 Thread Karl Wettin (JIRA)


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

Karl Wettin commented on SOLR-839:
--

Personally I didn't use this in anything new since my 2009 patch and comments . 
Actually I didn't use Solr at all since then. 
If my vote counts for anything then it would be for the JSON parser.

 XML Query Parser support
 

 Key: SOLR-839
 URL: https://issues.apache.org/jira/browse/SOLR-839
 Project: Solr
  Issue Type: New Feature
  Components: query parsers
Affects Versions: 1.3
Reporter: Erik Hatcher
Assignee: Erik Hatcher
 Fix For: 5.0

 Attachments: SOLR-839-object-parser.patch, SOLR-839.patch, 
 lucene-xml-query-parser-2.4-dev.jar


 Lucene contrib includes a query parser that is able to create the 
 full-spectrum of Lucene queries, using an XML data structure.
 This patch adds xml query parser support to Solr.



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

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

Re: Wiki edit permission

2014-03-24 Thread Steve Rowe

Hi Terry,

I’ve added your account name to the ContributorsGroup page on both the Solr and 
Lucene wikis, so you should be able to edit both now.

Steve

On Mar 24, 2014, at 9:21 AM, Terry Smith sheb...@gmail.com wrote:

 Could I be allowed edit permissions on the wiki? I've signed up on the Lucene 
 and Solr wiki with the same name (TerrySmith) but am just emailing lucene-dev 
 to start.
 
 --Terry
 


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

[jira] [Commented] (SOLR-5228) Deprecate fields and types tags in schema.xml

2014-03-24 Thread David Smiley (JIRA)


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

David Smiley commented on SOLR-5228:


+1 to namespaces.  External code could add the namespace to the custom stuff, 
and that part could be non-validating and excluded from the core schema.  It 
also makes it clear where there's custom stuff.

 Deprecate fields and types tags in schema.xml
 -

 Key: SOLR-5228
 URL: https://issues.apache.org/jira/browse/SOLR-5228
 Project: Solr
  Issue Type: Improvement
  Components: Schema and Analysis
Reporter: Hoss Man
Assignee: Erick Erickson
 Fix For: 4.8, 5.0

 Attachments: SOLR-5228.patch, SOLR-5228.patch


 On the solr-user mailing list, Nutan recently mentioned spending days trying 
 to track down a problem that turned out to be because he had attempted to add 
 a {{dynamicField .. /}} that was outside of the {{fields}} block in his 
 schema.xml -- Solr was just silently ignoring it.
 We have made improvements in other areas of config validation by generating 
 statup errors when tags/attributes are found that are not expected -- but in 
 this case i think we should just stop expecting/requiring that the 
 {{fields}} and {{types}} tags will be used to group these sorts of 
 things.  I think schema.xml parsing should just start ignoring them and only 
 care about finding the {{field}}, {{dynamicField}}, and {{fieldType}} 
 tags wherever they may be.
 If people want to keep using them, fine.  If people want to mix fieldTypes 
 and fields side by side (perhaps specify a fieldType, then list all the 
 fields using it) fine.  I don't see any value in forcing people to use them, 
 but we definitely shouldn't leave things the way they are with otherwise 
 perfectly valid field/type declarations being silently ignored.
 ---
 I'll take this on unless i see any objections.



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

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

[jira] [Updated] (LUCENE-5356) Morfologik filter can accept custom dictionary resources

2014-03-24 Thread Dawid Weiss (JIRA)


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

Dawid Weiss updated LUCENE-5356:


Summary: Morfologik filter can accept custom dictionary resources  (was: 
more generic lucene-morfologik integration)

 Morfologik filter can accept custom dictionary resources
 

 Key: LUCENE-5356
 URL: https://issues.apache.org/jira/browse/LUCENE-5356
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/analysis
Affects Versions: 4.6
Reporter: Michal Hlavac
Assignee: Dawid Weiss
Priority: Minor
  Labels: newbie, patch
 Fix For: 4.8, 5.0

 Attachments:  LUCENE-5356.patch, LUCENE-5356.patch, LUCENE-5356.patch


 I have little proposal for morfologik lucene module. Current module is 
 tightly coupled with polish DICTIONARY enumeration.
 But other people (like me) can build own dictionaries to FSA and use it with 
 lucene. 
 You can find proposal in attachment and also example usage in analyzer 
 (SlovakLemmaAnalyzer).
 It uses dictionary property as String resource from classpath, not 
 enumeration.
 One change is, that dictionary variable must be set in MofologikFilterFactory 
 (no default value).



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

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

[jira] [Commented] (LUCENE-5356) Morfologik filter can accept custom dictionary resources

2014-03-24 Thread ASF subversion and git services (JIRA)


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

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

Commit 1580853 from [~dawidweiss] in branch 'dev/trunk'
[ https://svn.apache.org/r1580853 ]

LUCENE-5356: Morfologik filter can accept custom dictionary resources.

 Morfologik filter can accept custom dictionary resources
 

 Key: LUCENE-5356
 URL: https://issues.apache.org/jira/browse/LUCENE-5356
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/analysis
Affects Versions: 4.6
Reporter: Michal Hlavac
Assignee: Dawid Weiss
Priority: Minor
  Labels: newbie, patch
 Fix For: 4.8, 5.0

 Attachments:  LUCENE-5356.patch, LUCENE-5356.patch, 
 LUCENE-5356.patch, LUCENE-5356.patch


 I have little proposal for morfologik lucene module. Current module is 
 tightly coupled with polish DICTIONARY enumeration.
 But other people (like me) can build own dictionaries to FSA and use it with 
 lucene. 
 You can find proposal in attachment and also example usage in analyzer 
 (SlovakLemmaAnalyzer).
 It uses dictionary property as String resource from classpath, not 
 enumeration.
 One change is, that dictionary variable must be set in MofologikFilterFactory 
 (no default value).



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

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

[jira] [Updated] (LUCENE-5356) Morfologik filter can accept custom dictionary resources

2014-03-24 Thread Dawid Weiss (JIRA)


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

Dawid Weiss updated LUCENE-5356:


Attachment: LUCENE-5356.patch

Polished a few minor things wrt the documentation, added CHANGES entry.

 Morfologik filter can accept custom dictionary resources
 

 Key: LUCENE-5356
 URL: https://issues.apache.org/jira/browse/LUCENE-5356
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/analysis
Affects Versions: 4.6
Reporter: Michal Hlavac
Assignee: Dawid Weiss
Priority: Minor
  Labels: newbie, patch
 Fix For: 4.8, 5.0

 Attachments:  LUCENE-5356.patch, LUCENE-5356.patch, 
 LUCENE-5356.patch, LUCENE-5356.patch


 I have little proposal for morfologik lucene module. Current module is 
 tightly coupled with polish DICTIONARY enumeration.
 But other people (like me) can build own dictionaries to FSA and use it with 
 lucene. 
 You can find proposal in attachment and also example usage in analyzer 
 (SlovakLemmaAnalyzer).
 It uses dictionary property as String resource from classpath, not 
 enumeration.
 One change is, that dictionary variable must be set in MofologikFilterFactory 
 (no default value).



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

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

Need help for solr use with JAVA and mysql

2014-03-24 Thread PRATIK SOLANKI

Hello Sir / Madam

I was searching apache solr on internet.

but i couldn't found how to config my own database with solr for searching
using JAVA.

Please can you provide any help for it.

Please provide reply for this.

Thanking you


W. Pratik Solanki

[jira] [Commented] (LUCENE-5356) Morfologik filter can accept custom dictionary resources

2014-03-24 Thread ASF subversion and git services (JIRA)


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

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

Commit 1580858 from [~dawidweiss] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1580858 ]

LUCENE-5356: Morfologik filter can accept custom dictionary resources.

 Morfologik filter can accept custom dictionary resources
 

 Key: LUCENE-5356
 URL: https://issues.apache.org/jira/browse/LUCENE-5356
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/analysis
Affects Versions: 4.6
Reporter: Michal Hlavac
Assignee: Dawid Weiss
Priority: Minor
  Labels: newbie, patch
 Fix For: 4.8, 5.0

 Attachments:  LUCENE-5356.patch, LUCENE-5356.patch, 
 LUCENE-5356.patch, LUCENE-5356.patch


 I have little proposal for morfologik lucene module. Current module is 
 tightly coupled with polish DICTIONARY enumeration.
 But other people (like me) can build own dictionaries to FSA and use it with 
 lucene. 
 You can find proposal in attachment and also example usage in analyzer 
 (SlovakLemmaAnalyzer).
 It uses dictionary property as String resource from classpath, not 
 enumeration.
 One change is, that dictionary variable must be set in MofologikFilterFactory 
 (no default value).



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

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

Re: Wiki edit permission

2014-03-24 Thread Terry Smith

Steve,

Boy that was quick! Thanks.

--Terry



On Mon, Mar 24, 2014 at 9:28 AM, Steve Rowe sar...@gmail.com wrote:

 Hi Terry,

 I've added your account name to the ContributorsGroup page on both the
 Solr and Lucene wikis, so you should be able to edit both now.

 Steve

 On Mar 24, 2014, at 9:21 AM, Terry Smith sheb...@gmail.com wrote:

  Could I be allowed edit permissions on the wiki? I've signed up on the
 Lucene and Solr wiki with the same name (TerrySmith) but am just emailing
 lucene-dev to start.
 
  --Terry
 


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

[jira] [Resolved] (LUCENE-5356) Morfologik filter can accept custom dictionary resources

2014-03-24 Thread Dawid Weiss (JIRA)


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

Dawid Weiss resolved LUCENE-5356.
-

Resolution: Fixed

Thanks Michal.

 Morfologik filter can accept custom dictionary resources
 

 Key: LUCENE-5356
 URL: https://issues.apache.org/jira/browse/LUCENE-5356
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/analysis
Affects Versions: 4.6
Reporter: Michal Hlavac
Assignee: Dawid Weiss
Priority: Minor
  Labels: newbie, patch
 Fix For: 4.8, 5.0

 Attachments:  LUCENE-5356.patch, LUCENE-5356.patch, 
 LUCENE-5356.patch, LUCENE-5356.patch


 I have little proposal for morfologik lucene module. Current module is 
 tightly coupled with polish DICTIONARY enumeration.
 But other people (like me) can build own dictionaries to FSA and use it with 
 lucene. 
 You can find proposal in attachment and also example usage in analyzer 
 (SlovakLemmaAnalyzer).
 It uses dictionary property as String resource from classpath, not 
 enumeration.
 One change is, that dictionary variable must be set in MofologikFilterFactory 
 (no default value).



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

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

Re: Need help for solr use with JAVA and mysql

2014-03-24 Thread Varun Thacker

You need to use SolrJ to index documents from your database using. You will
need to fetch the documents from your database using custom Java code and
then use SolrJ to index them.

Link - . https://cwiki.apache.org/confluence/display/solr/Using+SolrJ

You should also look at DataImportHandler. You might find it easier.

https://cwiki.apache.org/confluence/display/solr/Uploading+Structured+Data+Store+Data+with+the+Data+Import+Handler

Also from next time please ask doubts regarding solr on the solr-user
mailing list instead.

You can subscribe it from here -
https://lucene.apache.org/solr/discussion.html#solr-user-list-solr-userlucene




On Mon, Mar 24, 2014 at 7:24 PM, PRATIK SOLANKI
pratiksolank...@gmail.comwrote:

 Hello Sir / Madam

 I was searching apache solr on internet.

 but i couldn't found how to config my own database with solr for searching
 using JAVA.

 Please can you provide any help for it.

 Please provide reply for this.

 Thanking you


 W. Pratik Solanki




-- 


Regards,
Varun Thacker
http://www.vthacker.in/

[jira] [Commented] (SOLR-4618) Integrate LucidWorks' Solr Reference Guide with Solr documentation

2014-03-24 Thread Cassandra Targett (JIRA)


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

Cassandra Targett commented on SOLR-4618:
-

bq. Now that the Reference Guide is a success story - is there any more 
thinking on what should happen with a MoinMoin WIKI?

The plan has been to go through the wiki and mark pages where duplicated 
documentation exists in the Solr Ref Guide and point users to a definitive 
source. Since the MoinMoin wiki has more flexible permissions for editing 
(i.e., you don't have to be a committer to make changes), it can transform into 
a community space where users can share the cool things they're doing or 
problems they overcame.

A framework has already been proposed for that here:
https://cwiki.apache.org/confluence/display/solr/Internal+-+Maintaining+Documentation#Internal-MaintainingDocumentation-Migrating%22Official%22DocumentationfromMoinMoin

The first step of that is to remove the duplicated content - the obstacle is 
really just volunteers who have the time to help out.

As for this issue, there are a couple sub-tasks from the original setup that I 
think we still would like to get resolved somehow.

 Integrate LucidWorks' Solr Reference Guide with Solr documentation
 --

 Key: SOLR-4618
 URL: https://issues.apache.org/jira/browse/SOLR-4618
 Project: Solr
  Issue Type: Improvement
  Components: documentation
Affects Versions: 4.1
Reporter: Cassandra Targett
Assignee: Hoss Man
 Attachments: NewSolrStyle.css, SolrRefGuide.4.3.zip, 
 SolrRefGuide4.1-ASF.zip


 LucidWorks would like to donate the Apache Solr Reference Guide, maintained 
 by LucidWorks tech writers, to the Solr community. It was first produced in 
 2009 as a download-only PDF for Solr 1.4, but since 2011 it has been online 
 at http://docs.lucidworks.com/display/solr/ and updated for Solr 3.x releases 
 and for Solr 4.0 and 4.1.
 *REVISED:* Since the process took a little while, Cassandra kept maintaining 
 hte lucid copy of the doc upto and including Solr 4.3.  it has now been 
 loaded into the ASF CWIKI instance, but there are still other aspects of 
 getting this doc into a maintainable state being tracked in sub-tasks...
 https://cwiki.apache.org/confluence/display/solr/



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

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

[jira] [Created] (SOLR-5903) SolrCore should implement Closeable

Alan Woodward created SOLR-5903:
---

 Summary: SolrCore should implement Closeable
 Key: SOLR-5903
 URL: https://issues.apache.org/jira/browse/SOLR-5903
 Project: Solr
  Issue Type: Improvement
Reporter: Alan Woodward
Assignee: Alan Woodward


Now that we're on Java 7, we can use try-with-resources everywhere we 
open/close SolrCores.



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

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

[jira] [Commented] (SOLR-5890) Delete silently fails if not sent to shard where document was added

2014-03-24 Thread Brett Hoerner (JIRA)


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

Brett Hoerner commented on SOLR-5890:
-

See Document Routing here: 
https://cwiki.apache.org/confluence/display/solr/Shards+and+Indexing+Data+in+SolrCloud

 Delete silently fails if not sent to shard where document was added
 ---

 Key: SOLR-5890
 URL: https://issues.apache.org/jira/browse/SOLR-5890
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.7
 Environment: Debian 7.4.
Reporter: Peter Inglesby
 Fix For: 4.8, 5.0, 4.7.1


 We have SolrCloud set up with two shards, each with a leader and a replica.  
 We use haproxy to distribute requests between the four nodes.
 Regardless of which node we send an add request to, following a commit, the 
 newly-added document is returned in a search, as expected.
 However, we can only delete a document if the delete request is sent to a 
 node in the shard where the document was added.  If we send the delete 
 request to a node in the other shard (and then send a commit) the document is 
 not deleted.  Such a delete request will get a 200 response, with the 
 following body:
   {'responseHeader'={'status'=0,'QTime'=7}}
 Apart from the the very low QTime, this is indistinguishable from a 
 successful delete.



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

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

[jira] [Updated] (SOLR-5903) SolrCore should implement Closeable


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

Alan Woodward updated SOLR-5903:


Attachment: SOLR-5903.patch

Patch cutting over most uses of SolrCore.close() to try-with-resources.  There 
are still a few instances I've left alone, mainly in the CoreContainer 
create-and-register-and-get methods, and in some test classes where changing it 
would change the logic of the test itself.

 SolrCore should implement Closeable
 ---

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


 Now that we're on Java 7, we can use try-with-resources everywhere we 
 open/close SolrCores.



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

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

[jira] [Commented] (SOLR-2649) MM ignored in edismax queries with operators

2014-03-24 Thread Andrew Buchanan (JIRA)


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

Andrew Buchanan commented on SOLR-2649:
---

Looks good to me

 MM ignored in edismax queries with operators
 

 Key: SOLR-2649
 URL: https://issues.apache.org/jira/browse/SOLR-2649
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Reporter: Magnus Bergmark
Priority: Minor
 Fix For: 4.8, 5.0

 Attachments: SOLR-2649.diff, SOLR-2649.patch


 Hypothetical scenario:
   1. User searches for stocks oil gold with MM set to 50%
   2. User adds -stockings to the query: stocks oil gold -stockings
   3. User gets no hits since MM was ignored and all terms where AND-ed 
 together
 The behavior seems to be intentional, although the reason why is never 
 explained:
   // For correct lucene queries, turn off mm processing if there
   // were explicit operators (except for AND).
   boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0; 
 (lines 232-234 taken from 
 tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java)
 This makes edismax unsuitable as an replacement to dismax; mm is one of the 
 primary features of dismax.



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

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

[jira] [Commented] (SOLR-4478) Allow cores to specify a named config set in non-SolrCloud mode

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

Alan Woodward commented on SOLR-4478:
-

There's a few follow up things I'd like to do as well, like managing configsets
via a RestManager.

I'm not sure if I've got the right permissions to edit the CWiki yet though?
(have just created a login under 'romseygeek').

Allow cores to specify a named config set in non-SolrCloud mode
---

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: Alan Woodward
Fix For: 4.8, 5.0

Attachments: SOLR-4478-take2.patch, SOLR-4478-take2.patch,
SOLR-4478-take2.patch, SOLR-4478-take2.patch, SOLR-4478.patch, SOLR-4478.patch

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

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

RE: Need help for solr use with JAVA and mysql

2014-03-24 Thread Wright Karl (HERE/Cambridge)

You may also want to consider ManifoldCF for this.

http://manifoldcf.apache.org

Karl

From: ext Varun Thacker [mailto:varunthacker1...@gmail.com]
Sent: Monday, March 24, 2014 10:06 AM
To: dev@lucene.apache.org
Subject: Re: Need help for solr use with JAVA and mysql

You need to use SolrJ to index documents from your database using. You will 
need to fetch the documents from your database using custom Java code and then 
use SolrJ to index them.

Link - . https://cwiki.apache.org/confluence/display/solr/Using+SolrJ

You should also look at DataImportHandler. You might find it easier.

https://cwiki.apache.org/confluence/display/solr/Uploading+Structured+Data+Store+Data+with+the+Data+Import+Handler

Also from next time please ask doubts regarding solr on the solr-user mailing 
list instead.

You can subscribe it from here - 
https://lucene.apache.org/solr/discussion.html#solr-user-list-solr-userlucene

On Mon, Mar 24, 2014 at 7:24 PM, PRATIK SOLANKI 
pratiksolank...@gmail.commailto:pratiksolank...@gmail.com wrote:
Hello Sir / Madam

I was searching apache solr on internet.

but i couldn't found how to config my own database with solr for searching 
using JAVA.

Please can you provide any help for it.
Please provide reply for this.

Thanking you

W. Pratik Solanki

--

Regards,
Varun Thacker
http://www.vthacker.in/

[jira] [Commented] (LUCENE-5356) Morfologik filter can accept custom dictionary resources

2014-03-24 Thread Michal Hlavac (JIRA)


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

Michal Hlavac commented on LUCENE-5356:
---

One thing I forget. Is it possible to change scope of morfologik-polish 
dependency to test?

 Morfologik filter can accept custom dictionary resources
 

 Key: LUCENE-5356
 URL: https://issues.apache.org/jira/browse/LUCENE-5356
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/analysis
Affects Versions: 4.6
Reporter: Michal Hlavac
Assignee: Dawid Weiss
Priority: Minor
  Labels: newbie, patch
 Fix For: 4.8, 5.0

 Attachments:  LUCENE-5356.patch, LUCENE-5356.patch, 
 LUCENE-5356.patch, LUCENE-5356.patch


 I have little proposal for morfologik lucene module. Current module is 
 tightly coupled with polish DICTIONARY enumeration.
 But other people (like me) can build own dictionaries to FSA and use it with 
 lucene. 
 You can find proposal in attachment and also example usage in analyzer 
 (SlovakLemmaAnalyzer).
 It uses dictionary property as String resource from classpath, not 
 enumeration.
 One change is, that dictionary variable must be set in MofologikFilterFactory 
 (no default value).



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

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

[jira] [Resolved] (SOLR-5900) Improve ZkController#checkOverseerDesignate


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

Noble Paul resolved SOLR-5900.
--

Resolution: Fixed

 Improve ZkController#checkOverseerDesignate
 ---

 Key: SOLR-5900
 URL: https://issues.apache.org/jira/browse/SOLR-5900
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Priority: Minor

 I see the following in the logs because the roles nodes does not exist - 
 seems that we should ensure this node exists or treat it's non existence as 
 being empty with no warning:
 {noformat}
 3955 T11 oasc.ZkController.checkOverseerDesignate WARN could not readd the 
 overseer designate  org.apache.zookeeper.KeeperException$NoNodeException: 
 KeeperErrorCode = NoNode for /roles.json
   at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
   at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
   at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1155)
   at 
 org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:276)
   at 
 org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:1)
   at 
 org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:73)
   at 
 org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:273)
   at 
 org.apache.solr.cloud.ZkController.checkOverseerDesignate(ZkController.java:1672)
   at org.apache.solr.core.CoreContainer.load(CoreContainer.java:350)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:200)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:147)
   at org.eclipse.jetty.servlet.FilterHolder.doStart(FilterHolder.java:119)
 {noformat}



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

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

[jira] [Assigned] (SOLR-5900) Improve ZkController#checkOverseerDesignate


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

Noble Paul reassigned SOLR-5900:


Assignee: Noble Paul

 Improve ZkController#checkOverseerDesignate
 ---

 Key: SOLR-5900
 URL: https://issues.apache.org/jira/browse/SOLR-5900
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Noble Paul
Priority: Minor

 I see the following in the logs because the roles nodes does not exist - 
 seems that we should ensure this node exists or treat it's non existence as 
 being empty with no warning:
 {noformat}
 3955 T11 oasc.ZkController.checkOverseerDesignate WARN could not readd the 
 overseer designate  org.apache.zookeeper.KeeperException$NoNodeException: 
 KeeperErrorCode = NoNode for /roles.json
   at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
   at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
   at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1155)
   at 
 org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:276)
   at 
 org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:1)
   at 
 org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:73)
   at 
 org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:273)
   at 
 org.apache.solr.cloud.ZkController.checkOverseerDesignate(ZkController.java:1672)
   at org.apache.solr.core.CoreContainer.load(CoreContainer.java:350)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:200)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:147)
   at org.eclipse.jetty.servlet.FilterHolder.doStart(FilterHolder.java:119)
 {noformat}



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

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

[jira] [Commented] (LUCENE-4335) Builds should regenerate all generated sources


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

Steve Rowe commented on LUCENE-4335:


As of the JFlex 1.5.1 upgrade (LUCENE-5552), the only changes I see after 
running {{ant regenerate}} at the top level are in the queryparser module:

{noformat}
M   
lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/CharStream.java
M   
lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/ParseException.java
M   
lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/QueryParser.java
M   
lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/Token.java
M   
lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/TokenMgrError.java
M   
lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/standard/parser/CharStream.java
M   
lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/standard/parser/ParseException.java
M   
lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/standard/parser/StandardSyntaxParser.java
M   
lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/standard/parser/Token.java
M   
lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/standard/parser/TokenMgrError.java
M   
lucene/queryparser/src/java/org/apache/lucene/queryparser/surround/parser/CharStream.java
M   
lucene/queryparser/src/java/org/apache/lucene/queryparser/surround/parser/ParseException.java
M   
lucene/queryparser/src/java/org/apache/lucene/queryparser/surround/parser/QueryParser.java
M   
lucene/queryparser/src/java/org/apache/lucene/queryparser/surround/parser/Token.java
M   
lucene/queryparser/src/java/org/apache/lucene/queryparser/surround/parser/TokenMgrError.java
{noformat}

Most of these are diamond operator issues: the generated source was manually 
converted to use the diamond operator, but the corresponding {{.jj}} files were 
not.  I removed the appropriate explicit types in the {{.jj}} files and ran 
{{ant regenerate}}, but JavaCC 5.0 doesn't like it:

{noformat}
javacc-QueryParser:
   [javacc] Java Compiler Compiler Version 5.0 (Parser Generator)
   [javacc] (type javacc with no arguments for help)
   [javacc] Reading from file 
/Users/sarowe/svn/lucene/dev/trunk7/lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/QueryParser.jj
 . . .
   [javacc] org.javacc.parser.ParseException: Encountered at line 
225, column 47.
   [javacc] Was expecting one of:
   [javacc] boolean ...
   [javacc] byte ...
   [javacc] char ...
   [javacc] double ...
   [javacc] float ...
   [javacc] int ...
   [javacc] long ...
   [javacc] short ...
   [javacc] ? ...
   [javacc] IDENTIFIER ...
   [javacc] 
   [javacc] Detected 1 errors and 0 warnings.
{noformat}

I see JavaCC 6.0 was recently released - maybe it can handle the diamond 
operator?

One other problem with some JavaCC-generated sources: the checksum seems to 
have somehow changed, even though nothing else has? - e.g. for the classic 
queryparser's {{CharStream.java}}:

{noformat}
Index: 
lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/CharStream.java
===
--- 
lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/CharStream.java
   (revision 1580832)
+++ 
lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/CharStream.java
   (working copy)
@@ -112,4 +112,4 @@
   void Done();
 
 }
-/* JavaCC - OriginalChecksum=c847dd1920bf7901125a7244125682ad (do not edit 
this line) */
+/* JavaCC - OriginalChecksum=30b94cad7b10d0d81e3a59a1083939d0 (do not edit 
this line) */
{noformat}

One last thing: I accidentally ran {{ant regenerate}} using Java8, and the 
supplementary character jflex macro files output by the icu module changed, and 
this caused the JFlex-generated scanner classes to change too.  On cursory 
inspection, some lines are reordered, but I wouldn't think that would trigger 
scanner class changes.  At a minimum, the output should be changed to have a 
fixed ordering. 

 Builds should regenerate all generated sources
 --

 Key: LUCENE-4335
 URL: https://issues.apache.org/jira/browse/LUCENE-4335
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
 Attachments: LUCENE-4335.patch, LUCENE-4335.patch, LUCENE-4335.patch


 We have more and more sources that are generated programmatically (query 
 parsers, fuzzy levN tables from Moman, packed ints specialized decoders, 
 etc.), and it's dangerous because developers may directly edit the generated 
 sources and forget to edit the meta-source.  It's

[jira] [Commented] (SOLR-5903) SolrCore should implement Closeable


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

Mark Miller commented on SOLR-5903:
---

Great idea - first thing I noticed on a glance was this part where the success 
boolean is still defined but not used ... is this right? Seems we will cancel 
every time?

{noformat}
 boolean success = false;
 try {
@@ -299,8 +292,8 @@ final class ShardLeaderElectionContext extends 
ShardLeaderElectionContextBase {
 } catch (Exception e) {
   SolrException.log(log, There was a problem trying to register as the 
leader, e);
   
-  try {
-core = cc.getCore(coreName);
+  try (SolrCore core = cc.getCore(coreName)) {
+
 if (core == null) {
   throw new SolrException(ErrorCode.SERVER_ERROR,
   Fatal Error, SolrCore not found: + coreName +  in 
@@ -312,16 +305,7 @@ final class ShardLeaderElectionContext extends 
ShardLeaderElectionContextBase {
 // we could not publish ourselves as leader - rejoin election
 rejoinLeaderElection(leaderSeqPath, core);
   } finally {
-try {
-  if (!success) {
-cancelElection();
-  }
-} finally {
-  if (core != null) {
-core.close();
-  }
-}
-
+cancelElection();
   }
 }
{noformat}

 SolrCore should implement Closeable
 ---

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


 Now that we're on Java 7, we can use try-with-resources everywhere we 
 open/close SolrCores.



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

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

[jira] [Commented] (LUCENE-4335) Builds should regenerate all generated sources

2014-03-24 Thread Uwe Schindler (JIRA)

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

Uwe Schindler commented on LUCENE-4335:
---

bq. One other problem with some JavaCC-generated sources: the checksum seems to
have somehow changed, even though nothing else has? - e.g. for the classic
queryparser's CharStream.java:

This is because the checksum is generated on the binary input file. As *I*
regenerated the files the last time and I have Windows CR-LF as line separator,
the checksum was different. If you run JavaCC on Linux afterwards, the file
checksum changes, unfortunately. I know about this problem, but I have no idea
how to fix. I would remove the checkum from the files completely after
regenerating (using a regex). We already have many regex replaces, this is just
one more.

bq. I see JavaCC 6.0 was recently released - maybe it can handle the diamond
operator?

I would simply let JavaCC use old-style generics. We have no must to use
diamonds. If generated code uses conventional declarations, it is no problem at
all.

If we want to upgrade to JavaCC 6.0, we should carefully compare its output. If
its identical, I have no problem with upgrading (if its available in Maven
Central).

Builds should regenerate all generated sources
--

Key: LUCENE-4335
URL: https://issues.apache.org/jira/browse/LUCENE-4335
Project: Lucene - Core
Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
Attachments: LUCENE-4335.patch, LUCENE-4335.patch, LUCENE-4335.patch

We have more and more sources that are generated programmatically (query
parsers, fuzzy levN tables from Moman, packed ints specialized decoders,
etc.), and it's dangerous because developers may directly edit the generated
sources and forget to edit the meta-source. It's happened to me several
times ... most recently just after landing the BlockPostingsFormat branch.
I think we should re-gen all of these in our builds and fail the build if
this creates a difference. I know some generators (eg JavaCC) embed
timestamps and so always create mods ... we can leave them out of this for
starters (or maybe post-process the sources to remove the timestamps) ...

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

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

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_60-ea-b10) - Build # 9892 - Still Failing!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9892/
Java: 32bit/jdk1.7.0_60-ea-b10 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.client.solrj.impl.CloudSolrServerTest.testDistribSearch

Error Message:
java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 
127.0.0.1:60935 within 45000 ms

Stack Trace:
org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: 
Could not connect to ZooKeeper 127.0.0.1:60935 within 45000 ms
at 
__randomizedtesting.SeedInfo.seed([50D74C7ADB464E52:D131C262AC192E6E]:0)
at 
org.apache.solr.common.cloud.SolrZkClient.init(SolrZkClient.java:150)
at 
org.apache.solr.common.cloud.SolrZkClient.init(SolrZkClient.java:101)
at 
org.apache.solr.common.cloud.SolrZkClient.init(SolrZkClient.java:91)
at 
org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:91)
at 
org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:85)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.setUp(AbstractDistribZkTestBase.java:77)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.setUp(AbstractFullDistribZkTestBase.java:201)
at 
org.apache.solr.client.solrj.impl.CloudSolrServerTest.setUp(CloudSolrServerTest.java:95)
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:1617)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:860)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:876)
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:359)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:783)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:443)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:835)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:771)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:782)
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 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at

[jira] [Commented] (LUCENE-4335) Builds should regenerate all generated sources

2014-03-24 Thread Uwe Schindler (JIRA)

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

Uwe Schindler commented on LUCENE-4335:
---

bq. One last thing: I accidentally ran ant regenerate using Java8, and the
supplementary character jflex macro files output by the icu module changed, and
this caused the JFlex-generated scanner classes to change too. On cursory
inspection, some lines are reordered, but I wouldn't think that would trigger
scanner class changes. At a minimum, the output should be changed to have a
fixed ordering.

Java 8 has a different hashing algorithm for string keys... The usual problem.

Builds should regenerate all generated sources
--

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

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

[jira] [Commented] (LUCENE-4978) Spatial search with point query won't find identical indexed point


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

Steve Rowe commented on LUCENE-4978:


[~dsmiley], any reason not to backport this to 4.7.1?

 Spatial search with point query won't find identical indexed point
 --

 Key: LUCENE-4978
 URL: https://issues.apache.org/jira/browse/LUCENE-4978
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Affects Versions: 4.1
Reporter: David Smiley
Assignee: David Smiley
Priority: Minor
 Fix For: 4.8

 Attachments: LUCENE-4978_fix_small_grid_false_negatives.patch


 Given a document with indexed POINT (10 20), when a search for INTERSECTS( 
 POINT (10 20)) is issued, no results are returned.
 The work-around is to not search with a point shape, use a very small-radius 
 circle or rectangle.  (I'm marking this issue as minor because it's easy to 
 do this).
 An unstated objective of the PrefixTree/grid approximation is that no matter 
 what precision you use, an intersects query will find all true-positives.  
 Due to approximations, it may also find some close false-positives.  But in 
 the case above, that unstated promise is violated.  But it can also happen 
 for query shapes other than points which do in fact barely enclose the point 
 given at index time yet the indexed point is in-effect shifted to the center 
 point of a cell which could be outside the query shape, and ultimately 
 leading to a false-negative.



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

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

[jira] [Commented] (SOLR-5550) shards.info is not returned in case of short circuited distributed query


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

Steve Rowe commented on SOLR-5550:
--

[~shalinmangar], [~tim.potter], any reason not to backport this to 4.7.1?

 shards.info is not returned in case of short circuited distributed query
 

 Key: SOLR-5550
 URL: https://issues.apache.org/jira/browse/SOLR-5550
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.6
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
Priority: Minor
 Fix For: 4.8, 5.0

 Attachments: SOLR-5550.patch, SOLR-5550.patch


 Distributed queries which are short circuited and executed locally do not 
 return a shards.info section even when requested.
 Steps to reproduce:
 # cd solr; ant example; cp -r example example2
 # cd example; java -Dbootstrap_confdir=./solr/collection1/conf 
 -Dcollection.configName=conf1 -DzkRun -DnumShards=2 -jar start.jar
 # cd example2; java -Djetty.port=7574 -DzkHost=localhost:9983 -jar start.jar
 # curl 
 http://localhost:8983/solr/admin/collections?action=CREATEcollection=test1name=test1numShards=2collection.configName=conf1maxShardsPerNode=3
 # Add two docs:
 {code}
 add
   doc
 field name=ida!1/field
 field name=namexyz/field
 field name=price2.00/field
   /doc
   doc
 field name=idb!1/field
 field name=nameabc/field
 field name=price5.00/field
   /doc
 /add
 {code}
 # curl 
 http://localhost:8983/admin/cores?name=test1_shard2_replica2collection=test1shard=shard2
 # curl 
 http://localhost:8983/solr/test1_shard2_replica1/select?_route_=b!fl=*start=0q=*:*shards.info=truecollection=test1rows=10
 # The above will not return shards.info
 # curl 
 http://localhost:7574/solr/test1/select?_route_=b!fl=*start=0q=*:*shards.info=truecollection=test1rows=10
 # The above will return shards.info



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

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

[jira] [Updated] (SOLR-5897) JQuery file listed as version 1.7.2 but actually contains 1.4.3 code

2014-03-24 Thread Stefan Matheis (steffkes) (JIRA)


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

Stefan Matheis (steffkes) updated SOLR-5897:


Attachment: SOLR-5897.patch

That's actually right - looks like the file only got renamed. Patch attached

 JQuery file listed as version 1.7.2 but actually contains 1.4.3 code
 

 Key: SOLR-5897
 URL: https://issues.apache.org/jira/browse/SOLR-5897
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1, 4.2, 4.2.1, 4.3, 4.3.1, 4.4, 4.5, 4.5.1, 4.6, 
 4.6.1, 4.7
 Environment: All
Reporter: Jonathan Lampe
Priority: Minor
  Labels: jquery, war
 Attachments: SOLR-5897.patch


 The example\webapps\solr.war file contains a jquery-1.7.2.min.js file 
 whose name suggests that it is version 1.7.2.  However, the file actually 
 contains version 1.4.3 code.  (This code may be subject to CVE-2011-4969.) 
 (I think I read something about a functional roll-back from JQuery 1.5.1 to 
 1.4.3 in other issues - if so, could possibly be related?)   



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

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

[jira] [Comment Edited] (SOLR-5897) JQuery file listed as version 1.7.2 but actually contains 1.4.3 code

2014-03-24 Thread Stefan Matheis (steffkes) (JIRA)


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

Stefan Matheis (steffkes) edited comment on SOLR-5897 at 3/24/14 3:44 PM:
--

That's actually right - looks like the file only got renamed in 
[r1311442|http://svn.apache.org/r1311442]. Patch attached


was (Author: steffkes):
That's actually right - looks like the file only got renamed. Patch attached

 JQuery file listed as version 1.7.2 but actually contains 1.4.3 code
 

 Key: SOLR-5897
 URL: https://issues.apache.org/jira/browse/SOLR-5897
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1, 4.2, 4.2.1, 4.3, 4.3.1, 4.4, 4.5, 4.5.1, 4.6, 
 4.6.1, 4.7
 Environment: All
Reporter: Jonathan Lampe
Priority: Minor
  Labels: jquery, war
 Attachments: SOLR-5897.patch


 The example\webapps\solr.war file contains a jquery-1.7.2.min.js file 
 whose name suggests that it is version 1.7.2.  However, the file actually 
 contains version 1.4.3 code.  (This code may be subject to CVE-2011-4969.) 
 (I think I read something about a functional roll-back from JQuery 1.5.1 to 
 1.4.3 in other issues - if so, could possibly be related?)   



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

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

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


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

Steve Rowe commented on SOLR-5734:
--

[~markrmil...@gmail.com], should this be backported to 4.7.1?  (It's marked as 
a bug here but you called it an improvement over on SOLR-5721.)

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

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

 Attachments: SOLR-5734.patch


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



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

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

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


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

Mark Miller commented on SOLR-5734:
---

It could go back - it's a bug really, but nothing that hasn't always existed 
for the most part. Though I suppose it wouldn't have existed in the  SOLR-5721 
code yet.

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

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

 Attachments: SOLR-5734.patch


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



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

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

[jira] [Commented] (SOLR-5760) ConcurrentUpdateSolrServer has a blockUntilFinished call when streamDeletes is true that should be tucked into the if statement below it.


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

Steve Rowe commented on SOLR-5760:
--

[~markrmil...@gmail.com], any reason not to backport this to 4.7.1?

 ConcurrentUpdateSolrServer has a blockUntilFinished call when streamDeletes 
 is true that should be tucked into the if statement below it.
 -

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


 Pointed out to me by [~gchanan].



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

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

[jira] [Commented] (SOLR-5761) HttpSolrServer has a few fields that can be set via setters but are not volatile.


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

Steve Rowe commented on SOLR-5761:
--

[~markrmil...@gmail.com], any reason not to backport this to 4.7.1?

 HttpSolrServer has a few fields that can be set via setters but are not 
 volatile.
 -

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


 Pointed out to me by [~gchanan].



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

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

[jira] [Updated] (SOLR-5423) CSV output doesn't include function field


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

Steve Rowe updated SOLR-5423:
-

Fix Version/s: 4.7.1

 CSV output doesn't include function field
 -

 Key: SOLR-5423
 URL: https://issues.apache.org/jira/browse/SOLR-5423
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.4
Reporter: James Wilson
Assignee: Steve Rowe
 Fix For: 4.8, 5.0, 4.7.1

 Attachments: SOLR-5423.patch, SOLR-5423.patch


 Given a schema with 
field name=price  type=float indexed=true stored=true/
field name='numpages' type='int' indexed='true' stored='true'/
   
 the following query returns no rows:
 http://localhost:8983/solr/collection1/select?q=*%3A*rows=30fl=div(price%2Cnumpages)wt=csvindent=true
 However, setting wt=json or wt=xml, it works.



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

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

[jira] [Commented] (SOLR-5777) JsonLoader: field values get out of order when fieldname key is repeated


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

Steve Rowe commented on SOLR-5777:
--

I'll backport this to 4.7.1

 JsonLoader: field values get out of order when fieldname key is repeated
 

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

 Attachments: SOLR-5777.patch, SOLR-5777.patch


 while working on a test for SOLR-5183 i discovered a bug in the way field 
 values are ordered when the fieldname key is repeated.
 ie, these two docs should wind up having identical values for the field f, 
 but currently the order of the values gets swapped in doc #2...
 {noformat}
 {add:[
{id:1, 
 f:[45,67]
},
{id:2, 
 f:45,
 f:67
}
 ]}
 {noformat}



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

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

[jira] [Commented] (SOLR-5423) CSV output doesn't include function field


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

Steve Rowe commented on SOLR-5423:
--

I'll backport this to 4.7.1

 CSV output doesn't include function field
 -

 Key: SOLR-5423
 URL: https://issues.apache.org/jira/browse/SOLR-5423
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.4
Reporter: James Wilson
Assignee: Steve Rowe
 Fix For: 4.8, 5.0, 4.7.1

 Attachments: SOLR-5423.patch, SOLR-5423.patch


 Given a schema with 
field name=price  type=float indexed=true stored=true/
field name='numpages' type='int' indexed='true' stored='true'/
   
 the following query returns no rows:
 http://localhost:8983/solr/collection1/select?q=*%3A*rows=30fl=div(price%2Cnumpages)wt=csvindent=true
 However, setting wt=json or wt=xml, it works.



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

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

[jira] [Updated] (SOLR-5777) JsonLoader: field values get out of order when fieldname key is repeated


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

Steve Rowe updated SOLR-5777:
-

Fix Version/s: 4.7.1

 JsonLoader: field values get out of order when fieldname key is repeated
 

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

 Attachments: SOLR-5777.patch, SOLR-5777.patch


 while working on a test for SOLR-5183 i discovered a bug in the way field 
 values are ordered when the fieldname key is repeated.
 ie, these two docs should wind up having identical values for the field f, 
 but currently the order of the values gets swapped in doc #2...
 {noformat}
 {add:[
{id:1, 
 f:[45,67]
},
{id:2, 
 f:45,
 f:67
}
 ]}
 {noformat}



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

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

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


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

Steve Rowe commented on SOLR-5811:
--

[~markrmil...@gmail.com], any reason not to backport this to 4.7.1?

 The Overseer will retry work items until success.
 -

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

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


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



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

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

[jira] [Commented] (SOLR-5796) With many collections, leader re-election takes too long when a node dies or is rebooted, leading to some shards getting into a conflicting state about who is the lead

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

Steve Rowe commented on SOLR-5796:
--

[~markrmil...@gmail.com], [~tim.potter], any reason not to backport this to
4.7.1?

With many collections, leader re-election takes too long when a node dies or
is rebooted, leading to some shards getting into a conflicting state about
who is the leader.

Key: SOLR-5796
URL: https://issues.apache.org/jira/browse/SOLR-5796
Project: Solr
Issue Type: Bug
Components: SolrCloud
Environment: Found on branch_4x
Reporter: Timothy Potter
Assignee: Mark Miller
Fix For: 4.8, 5.0

Attachments: SOLR-5796.patch

I'm doing some testing with a 4-node SolrCloud cluster against the latest rev
in branch_4x having many collections, 150 to be exact, each having 4 shards
with rf=3, so 450 cores per node. Nodes are decent in terms of resources:
-Xmx6g with 4 CPU - m3.xlarge's in EC2.
The problem occurs when rebooting one of the nodes, say as part of a rolling
restart of the cluster. If I kill one node and then wait for an extended
period of time, such as 3 minutes, then all of the leaders on the downed node
(roughly 150) have time to failover to another node in the cluster. When I
restart the downed node, since leaders have all failed over successfully, the
new node starts up and all cores assume the replica role in their respective
shards. This is goodness and expected.
However, if I don't wait long enough for the leader failover process to
complete on the other nodes before restarting the downed node,
then some bad things happen. Specifically, when the dust settles, many of the
previous leaders on the node I restarted get stuck in the conflicting state
seen in the ZkController, starting around line 852 in branch_4x:
{quote}
852 while (!leaderUrl.equals(clusterStateLeaderUrl)) {
853 if (tries == 60) {
854 throw new SolrException(ErrorCode.SERVER_ERROR,
855 There is conflicting information about the leader of
shard:
856 + cloudDesc.getShardId() + our state says:
857 + clusterStateLeaderUrl + but zookeeper says: +
leaderUrl);
858 }
859 Thread.sleep(1000);
860 tries++;
861 clusterStateLeaderUrl = zkStateReader.getLeaderUrl(collection,
shardId,
862 timeoutms);
863 leaderUrl = getLeaderProps(collection, cloudDesc.getShardId(),
timeoutms)
864 .getCoreUrl();
865 }
{quote}
As you can see, the code is trying to give a little time for this problem to
work itself out, 1 minute to be exact. Unfortunately, that doesn't seem to be
long enough for a busy cluster that has many collections. Now, one might
argue that 450 cores per node is asking too much of Solr, however I think
this points to a bigger issue of the fact that a node coming up isn't aware
that it went down and leader election is running on other nodes and is just
being slow. Moreover, once this problem occurs, it's not clear how to fix it
besides shutting the node down again and waiting for leader failover to
complete.
It's also interesting to me that /clusterstate.json was updated by the
healthy node taking over the leader role but the
/collections/collleaders/shard# was not updated? I added some debugging and
it seems like the overseer queue is extremely backed up with work.
Maybe the solution here is to just wait longer but I also want to get some
feedback from the community on other options? I know there are some plans to
help scale the Overseer (i.e. SOLR-5476) so maybe that helps and I'm trying
to add more debug to see if this is really due to overseer backlog (which I
suspect it is).
In general, I'm a little confused by the keeping of leader state in multiple
places in ZK. Is there any background information on why we have leader state
in /clusterstate.json and in the leader path znode?
Also, here are some interesting side observations:
a. If I use rf=2, then this problem doesn't occur as leader failover happens
more quickly and there's less overseer work?
May be a red herring here, but I can consistently reproduce it with RF=3, but
not with RF=2 ... suppose that is because there are only 300 cores per node
versus 450 and that's just enough less work to make this issue work itself
out.
b. To support that many cores, I had to set -Xss256k to reduce the stack size
as Solr uses a lot of threads during startup (high point was 800'ish)

Might be something we should recommend on

[jira] [Commented] (LUCENE-4978) Spatial search with point query won't find identical indexed point

2014-03-24 Thread David Smiley (JIRA)

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

David Smiley commented on LUCENE-4978:
--

Oh I didn't know there was going to be a 4.7.1. I'll backport. Thanks for
alerting me.

Spatial search with point query won't find identical indexed point
--

Key: LUCENE-4978
URL: https://issues.apache.org/jira/browse/LUCENE-4978
Project: Lucene - Core
Issue Type: Bug
Components: modules/spatial
Affects Versions: 4.1
Reporter: David Smiley
Assignee: David Smiley
Priority: Minor
Fix For: 4.8

Attachments: LUCENE-4978_fix_small_grid_false_negatives.patch

Given a document with indexed POINT (10 20), when a search for INTERSECTS(
POINT (10 20)) is issued, no results are returned.
The work-around is to not search with a point shape, use a very small-radius
circle or rectangle. (I'm marking this issue as minor because it's easy to
do this).
An unstated objective of the PrefixTree/grid approximation is that no matter
what precision you use, an intersects query will find all true-positives.
Due to approximations, it may also find some close false-positives. But in
the case above, that unstated promise is violated. But it can also happen
for query shapes other than points which do in fact barely enclose the point
given at index time yet the indexed point is in-effect shifted to the center
point of a cell which could be outside the query shape, and ultimately
leading to a false-negative.

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

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

[jira] [Commented] (SOLR-5818) distrib search with custom comparator does not quite work correctly


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

Steve Rowe commented on SOLR-5818:
--

[~rjernst], any reason not to backport this to 4.7.1?

 distrib search with custom comparator does not quite work correctly
 ---

 Key: SOLR-5818
 URL: https://issues.apache.org/jira/browse/SOLR-5818
 Project: Solr
  Issue Type: Bug
Reporter: Ryan Ernst
Assignee: Ryan Ernst
 Fix For: 4.8, 5.0

 Attachments: SOLR-5818.patch


 In QueryComponent.doFieldSortValues, a scorer is never set on a custom 
 comparator.  We just need to add a fake scorer that can pass through the 
 score from the DocList.



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

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

[jira] [Commented] (SOLR-5834) Overseer threads are only being interrupted and not closed.


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

Steve Rowe commented on SOLR-5834:
--

[~markrmil...@gmail.com], any reason not to backport this to 4.7.1?

 Overseer threads are only being interrupted and not closed.
 ---

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


 As noticed by Hossman in SOLR-5823, the Overseer is not actually calling 
 close on the runnables that are used to create threads - the treads are only 
 being interrupted in Overseer#close, but not closed.



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

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

[jira] [Commented] (SOLR-5839) ZookeeperInfoServlet Does Not Trim Path Properly


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

Steve Rowe commented on SOLR-5839:
--

[~markrmil...@gmail.com], any reason not to backport this to 4.7.1?

 ZookeeperInfoServlet Does Not Trim Path Properly
 

 Key: SOLR-5839
 URL: https://issues.apache.org/jira/browse/SOLR-5839
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.6.1, 4.7
Reporter: Furkan KAMACI
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.8, 5.0

 Attachments: SOLR-5839.patch


 This part has a bug:
 {code}
 // normalize path
   if (path == null) {
 path = /;
   } else {
 path.trim();
 if (path.length() == 0) {
   path = /;
 }
   }
 {code}



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

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

[jira] [Updated] (SOLR-5466) Add List Collections functionality to Collections API


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

Shalin Shekhar Mangar updated SOLR-5466:


Attachment: SOLR-5466.patch

# Added \_route\_ parameter which can be used in place of _shard_. The given 
route key will be used to determine the shard info to be returned. This will be 
useful to know which shard a given route key resolves to.
# Fixed TestCollectionAPI which was incorrectly expecting collections to be 
returned in a certain order.

I'm going to add shard address in the response. Most clients would like to know 
the base url of the shard. It is not easy to know that info from the node_name, 
core_name etc returned by the cluster state. I'll also add cluster properties, 
aliases and roles.

 Add List Collections functionality to Collections API
 -

 Key: SOLR-5466
 URL: https://issues.apache.org/jira/browse/SOLR-5466
 Project: Solr
  Issue Type: Sub-task
  Components: scripts and tools, SolrCloud
 Environment: All
Reporter: Dave Seltzer
Assignee: Shalin Shekhar Mangar
Priority: Minor
  Labels: api, collections, rest
 Attachments: SOLR-5466.patch, SOLR-5466.patch, SOLR-5466.patch, 
 SOLR-5466.patch, SOLR-5466.patch, SOLR-5466.patch


 The collections API lets you add, delete and modify existing collections. At 
 the moment the API does not let you get a list of current collections or view 
 information about a specific collection.
 The workaround is the use the Zookeeper API to get the list. This makes the 
 Collections API harder to work with. 
 Adding an action=LIST would significantly improve the function of this API.



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

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

[jira] [Commented] (SOLR-5874) Unsafe cast in RouteException


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

Steve Rowe commented on SOLR-5874:
--

[~markrmil...@gmail.com], any reason not to backport this to 4.7.1?

 Unsafe cast in RouteException
 -

 Key: SOLR-5874
 URL: https://issues.apache.org/jira/browse/SOLR-5874
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 4.6.1
Reporter: David Arthur
Assignee: Mark Miller

 When a non-Exception is thrown somewhere in the CloudSolrServer, I get a XXX 
 cannot be cast to java.lang.Exception
 {code}
 java.lang.ClassCastException: java.lang.NoClassDefFoundError cannot be cast 
 to java.lang.Exception
   at 
 org.apache.solr.client.solrj.impl.CloudSolrServer$RouteException.init(CloudSolrServer.java:484)
   at 
 org.apache.solr.client.solrj.impl.CloudSolrServer.directUpdate(CloudSolrServer.java:351)
   at 
 org.apache.solr.client.solrj.impl.CloudSolrServer.request(CloudSolrServer.java:510)
   at 
 org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:117)
 {code}
 Should probably cast to Throwable, or do a check and wrap non-Exceptions in 
 an Exception first



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

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

[jira] [Commented] (SOLR-5861) Recovery should not set onlyIfLeaderActive=true for slice in 'recovery' state


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

Steve Rowe commented on SOLR-5861:
--

[~shalinmangar], any reason not to backport this to 4.7.1?

 Recovery should not set onlyIfLeaderActive=true for slice in 'recovery' state
 -

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

 Attachments: SOLR-5861.patch


 RecoveryStrategy.sendPrepRecoveryCmd should exclude slices in 'recovery' 
 state in addition to 'construction' state when setting the onlyIfLeaderActive 
 parameter.



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

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

[JENKINS] Lucene-Solr-4.x-Linux (64bit/jdk1.7.0_60-ea-b10) - Build # 9786 - Failure!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/9786/
Java: 64bit/jdk1.7.0_60-ea-b10 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
REGRESSION:  
org.apache.solr.client.solrj.impl.CloudSolrServerTest.testDistribSearch

Error Message:
java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 
127.0.0.1:53990 within 45000 ms

Stack Trace:
org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: 
Could not connect to ZooKeeper 127.0.0.1:53990 within 45000 ms
at 
__randomizedtesting.SeedInfo.seed([E7564D880925D0D5:66B0C3907E7AB0E9]:0)
at 
org.apache.solr.common.cloud.SolrZkClient.init(SolrZkClient.java:150)
at 
org.apache.solr.common.cloud.SolrZkClient.init(SolrZkClient.java:101)
at 
org.apache.solr.common.cloud.SolrZkClient.init(SolrZkClient.java:91)
at 
org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:91)
at 
org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:85)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.setUp(AbstractDistribZkTestBase.java:77)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.setUp(AbstractFullDistribZkTestBase.java:201)
at 
org.apache.solr.client.solrj.impl.CloudSolrServerTest.setUp(CloudSolrServerTest.java:95)
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:1617)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:860)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:876)
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:359)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:783)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:443)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:835)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:771)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:782)
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

[jira] [Commented] (SOLR-5893) On restarting overseer designate , move itself to front of the queue


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

Steve Rowe commented on SOLR-5893:
--

[~noble.paul], should this be backported this to 4.7.1?  (It's categorized as 
an Improvement here, but is listed under Bug Fixes in CHANGES.txt)

 On restarting overseer designate , move itself to front of the queue 
 -

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


 When an overseer designate is killed and restarted move to the front of the 
 queue 



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

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

[jira] [Commented] (SOLR-5893) On restarting overseer designate , move itself to front of the queue


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

Noble Paul commented on SOLR-5893:
--

I don't think it's critical enough to go in 4.7.1

 On restarting overseer designate , move itself to front of the queue 
 -

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


 When an overseer designate is killed and restarted move to the front of the 
 queue 



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

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

[jira] [Reopened] (SOLR-5861) Recovery should not set onlyIfLeaderActive=true for slice in 'recovery' state


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

Shalin Shekhar Mangar reopened SOLR-5861:
-


Thanks for the reminder Steve. I'll backport it to 4.7.1

 Recovery should not set onlyIfLeaderActive=true for slice in 'recovery' state
 -

 Key: SOLR-5861
 URL: https://issues.apache.org/jira/browse/SOLR-5861
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.6.1, 4.7
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
Priority: Minor
 Fix For: 4.8, 5.0, 4.7.1

 Attachments: SOLR-5861.patch


 RecoveryStrategy.sendPrepRecoveryCmd should exclude slices in 'recovery' 
 state in addition to 'construction' state when setting the onlyIfLeaderActive 
 parameter.



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

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

[jira] [Updated] (SOLR-5861) Recovery should not set onlyIfLeaderActive=true for slice in 'recovery' state


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

Shalin Shekhar Mangar updated SOLR-5861:


Fix Version/s: 4.7.1

 Recovery should not set onlyIfLeaderActive=true for slice in 'recovery' state
 -

 Key: SOLR-5861
 URL: https://issues.apache.org/jira/browse/SOLR-5861
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.6.1, 4.7
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
Priority: Minor
 Fix For: 4.8, 5.0, 4.7.1

 Attachments: SOLR-5861.patch


 RecoveryStrategy.sendPrepRecoveryCmd should exclude slices in 'recovery' 
 state in addition to 'construction' state when setting the onlyIfLeaderActive 
 parameter.



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

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

[jira] [Commented] (SOLR-5903) SolrCore should implement Closeable


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

Alan Woodward commented on SOLR-5903:
-

That threw me the first time I saw it as well - it's because this particular 
try-finally is nested within a catch block, so success is always false.  

Maybe instead success should be set to true after the call to 
rejoinLeaderElection()?  I'm not familiar with how the leader election 
semantics work.

 SolrCore should implement Closeable
 ---

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


 Now that we're on Java 7, we can use try-with-resources everywhere we 
 open/close SolrCores.



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

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

[jira] [Updated] (SOLR-5550) shards.info is not returned in case of short circuited distributed query


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

Shalin Shekhar Mangar updated SOLR-5550:


Fix Version/s: 4.7.1

 shards.info is not returned in case of short circuited distributed query
 

 Key: SOLR-5550
 URL: https://issues.apache.org/jira/browse/SOLR-5550
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.6
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
Priority: Minor
 Fix For: 4.8, 5.0, 4.7.1

 Attachments: SOLR-5550.patch, SOLR-5550.patch


 Distributed queries which are short circuited and executed locally do not 
 return a shards.info section even when requested.
 Steps to reproduce:
 # cd solr; ant example; cp -r example example2
 # cd example; java -Dbootstrap_confdir=./solr/collection1/conf 
 -Dcollection.configName=conf1 -DzkRun -DnumShards=2 -jar start.jar
 # cd example2; java -Djetty.port=7574 -DzkHost=localhost:9983 -jar start.jar
 # curl 
 http://localhost:8983/solr/admin/collections?action=CREATEcollection=test1name=test1numShards=2collection.configName=conf1maxShardsPerNode=3
 # Add two docs:
 {code}
 add
   doc
 field name=ida!1/field
 field name=namexyz/field
 field name=price2.00/field
   /doc
   doc
 field name=idb!1/field
 field name=nameabc/field
 field name=price5.00/field
   /doc
 /add
 {code}
 # curl 
 http://localhost:8983/admin/cores?name=test1_shard2_replica2collection=test1shard=shard2
 # curl 
 http://localhost:8983/solr/test1_shard2_replica1/select?_route_=b!fl=*start=0q=*:*shards.info=truecollection=test1rows=10
 # The above will not return shards.info
 # curl 
 http://localhost:7574/solr/test1/select?_route_=b!fl=*start=0q=*:*shards.info=truecollection=test1rows=10
 # The above will return shards.info



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

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

[jira] [Reopened] (SOLR-5550) shards.info is not returned in case of short circuited distributed query


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

Shalin Shekhar Mangar reopened SOLR-5550:
-


Thanks Steve. I'll backport it.

 shards.info is not returned in case of short circuited distributed query
 

 Key: SOLR-5550
 URL: https://issues.apache.org/jira/browse/SOLR-5550
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.6
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
Priority: Minor
 Fix For: 4.8, 5.0, 4.7.1

 Attachments: SOLR-5550.patch, SOLR-5550.patch


 Distributed queries which are short circuited and executed locally do not 
 return a shards.info section even when requested.
 Steps to reproduce:
 # cd solr; ant example; cp -r example example2
 # cd example; java -Dbootstrap_confdir=./solr/collection1/conf 
 -Dcollection.configName=conf1 -DzkRun -DnumShards=2 -jar start.jar
 # cd example2; java -Djetty.port=7574 -DzkHost=localhost:9983 -jar start.jar
 # curl 
 http://localhost:8983/solr/admin/collections?action=CREATEcollection=test1name=test1numShards=2collection.configName=conf1maxShardsPerNode=3
 # Add two docs:
 {code}
 add
   doc
 field name=ida!1/field
 field name=namexyz/field
 field name=price2.00/field
   /doc
   doc
 field name=idb!1/field
 field name=nameabc/field
 field name=price5.00/field
   /doc
 /add
 {code}
 # curl 
 http://localhost:8983/admin/cores?name=test1_shard2_replica2collection=test1shard=shard2
 # curl 
 http://localhost:8983/solr/test1_shard2_replica1/select?_route_=b!fl=*start=0q=*:*shards.info=truecollection=test1rows=10
 # The above will not return shards.info
 # curl 
 http://localhost:7574/solr/test1/select?_route_=b!fl=*start=0q=*:*shards.info=truecollection=test1rows=10
 # The above will return shards.info



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

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

[jira] [Commented] (SOLR-5903) SolrCore should implement Closeable


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

Mark Miller commented on SOLR-5903:
---

Yeah, I see - that's already a little jacked up. I'll fix it.

 SolrCore should implement Closeable
 ---

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


 Now that we're on Java 7, we can use try-with-resources everywhere we 
 open/close SolrCores.



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

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

[jira] [Created] (SOLR-5904) ElectionContext can cancel an election when it should not if there was an exception while trying to register as the leader.

Mark Miller created SOLR-5904:
-

 Summary: ElectionContext can cancel an election when it should not 
if there was an exception while trying to register as the leader.
 Key: SOLR-5904
 URL: https://issues.apache.org/jira/browse/SOLR-5904
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.8, 5.0, 4.7.1






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

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

[jira] [Commented] (SOLR-2894) Implement distributed pivot faceting

2014-03-24 Thread AJ Lemke (JIRA)


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

AJ Lemke commented on SOLR-2894:


Brett,

When looking at the the output of the pivot, the data type has changed from a 
struct to an array. 
Is this the expected behavior or is the data type for each of the pivot facets 
to remain as a struct and I am experiencing a bug? 

Examples:
4.7 pre patch:
{
  field: cat,
  value: electronics,
  count: 12,
  pivot: [
{
  field: popularity,
  value: 7,
  count: 4
},
{
  field: popularity,
  value: 6,
  count: 3
},
{
  field: popularity,
  value: 1,
  count: 2
},
{
  field: popularity,
  value: 0,
  count: 1
},
{
  field: popularity,
  value: 5,
  count: 1
},
{
  field: popularity,
  value: 10,
  count: 1
}
  ]
},

Post Patch:
[
  field,
  cat,
  value,
  electronics,
  count,
  12,
  pivot,
  [
[
  field,
  popularity,
  value,
  7,
  count,
  4
],
[
  field,
  popularity,
  value,
  6,
  count,
  3
],
[
  field,
  popularity,
  value,
  1,
  count,
  2
],
[
  field,
  popularity,
  value,
  0,
  count,
  1
],
[
  field,
  popularity,
  value,
  5,
  count,
  1
],
[
  field,
  popularity,
  value,
  10,
  count,
  1
]
  ]
],

 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.8

 Attachments: SOLR-2894-reworked.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.patch, SOLR-2894.patch, 
 SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
 SOLR-2894.patch, dateToObject.patch


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



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

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

[jira] [Comment Edited] (SOLR-2894) Implement distributed pivot faceting

2014-03-24 Thread AJ Lemke (JIRA)


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

AJ Lemke edited comment on SOLR-2894 at 3/24/14 4:54 PM:
-

Brett,

When looking at the the output of the pivot, the data type has changed from a 
struct to an array. 
Is this the expected behavior or is the data type for each of the pivot facets 
to remain as a struct and I am experiencing a bug? 

Examples:
4.7 pre patch:
{
  field: cat,
  value: electronics,
  count: 12,
  pivot: [
{field: popularity,value: 7,count: 4},
{field: popularity,value: 6,count: 3},
{field: popularity,value: 1,count: 2},
{field: popularity,value: 0,count: 1},
{field: popularity,value: 5,count: 1},
{field: popularity,value: 10,count: 1}
  ]
},

Post Patch:
[
  field,
  cat,
  value,
  electronics,
  count,
  12,
  pivot,
  [
[field,popularity,value,7,count,4],
[field,popularity,value,6,count,3],
[field,popularity,value,1,count,2],
[field,popularity,value,0,count,1],
[field,popularity,value,5,count,1],
[field,popularity,value,10,count,1]
  ]
],


Edit: formatting.


was (Author: ajlemke):
Brett,

When looking at the the output of the pivot, the data type has changed from a 
struct to an array. 
Is this the expected behavior or is the data type for each of the pivot facets 
to remain as a struct and I am experiencing a bug? 

Examples:
4.7 pre patch:
{
  field: cat,
  value: electronics,
  count: 12,
  pivot: [
{
  field: popularity,
  value: 7,
  count: 4
},
{
  field: popularity,
  value: 6,
  count: 3
},
{
  field: popularity,
  value: 1,
  count: 2
},
{
  field: popularity,
  value: 0,
  count: 1
},
{
  field: popularity,
  value: 5,
  count: 1
},
{
  field: popularity,
  value: 10,
  count: 1
}
  ]
},

Post Patch:
[
  field,
  cat,
  value,
  electronics,
  count,
  12,
  pivot,
  [
[
  field,
  popularity,
  value,
  7,
  count,
  4
],
[
  field,
  popularity,
  value,
  6,
  count,
  3
],
[
  field,
  popularity,
  value,
  1,
  count,
  2
],
[
  field,
  popularity,
  value,
  0,
  count,
  1
],
[
  field,
  popularity,
  value,
  5,
  count,
  1
],
[
  field,
  popularity,
  value,
  10,
  count,
  1
]
  ]
],

 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.8

 Attachments: SOLR-2894-reworked.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.patch, SOLR-2894.patch, 
 SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
 SOLR-2894.patch, dateToObject.patch


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



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

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

[jira] [Updated] (SOLR-5904) ElectionContext can cancel an election when it should not if there was an exception while trying to register as the leader.


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

Mark Miller updated SOLR-5904:
--

Priority: Minor  (was: Major)

 ElectionContext can cancel an election when it should not if there was an 
 exception while trying to register as the leader.
 ---

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






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

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

[jira] [Commented] (SOLR-5890) Delete silently fails if not sent to shard where document was added

2014-03-24 Thread Shawn Grant (JIRA)

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

Shawn Grant commented on SOLR-5890:
---

I'm seeing the same problem on 4.6.1 using compositeId and a custom routing
field.

router:{
field:docHash,
name:compositeId},

fyi, I'm wanting to use the docHash field for routing so that duplicate docs
are on the same shard allowing for queries using grouping... or did I misread
the Document Routing wiki page and configure that incorrectly?

Delete silently fails if not sent to shard where document was added
---

Key: SOLR-5890
URL: https://issues.apache.org/jira/browse/SOLR-5890
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.7
Environment: Debian 7.4.
Reporter: Peter Inglesby
Fix For: 4.8, 5.0, 4.7.1

We have SolrCloud set up with two shards, each with a leader and a replica.
We use haproxy to distribute requests between the four nodes.
Regardless of which node we send an add request to, following a commit, the
newly-added document is returned in a search, as expected.
However, we can only delete a document if the delete request is sent to a
node in the shard where the document was added. If we send the delete
request to a node in the other shard (and then send a commit) the document is
not deleted. Such a delete request will get a 200 response, with the
following body:
{'responseHeader'={'status'=0,'QTime'=7}}
Apart from the the very low QTime, this is indistinguishable from a
successful delete.

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

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

[jira] [Commented] (SOLR-5899) CloudSolrServer's RouteResponse and RouteException should be publicly accessible.


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

Steve Rowe commented on SOLR-5899:
--

[~markrmil...@gmail.com], should this (and SOLR-5874, since they were committed 
together) be backported to 4.7.1?

 CloudSolrServer's RouteResponse and RouteException should be publicly 
 accessible.
 -

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






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

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

[jira] [Commented] (SOLR-5890) Delete silently fails if not sent to shard where document was added