[jira] [Commented] (SOLR-5163) edismax should throw exception when qf refers to nonexistent field
[ https://issues.apache.org/jira/browse/SOLR-5163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621982#comment-16621982 ] Edward Ribeiro commented on SOLR-5163: -- If [~dsmiley] agreed then it's hands down the solution. Go ahead! > edismax should throw exception when qf refers to nonexistent field > -- > > Key: SOLR-5163 > URL: https://issues.apache.org/jira/browse/SOLR-5163 > Project: Solr > Issue Type: Bug > Components: query parsers, search >Affects Versions: 4.10.4 >Reporter: Steven Bower >Assignee: David Smiley >Priority: Major > Labels: newdev > Attachments: SOLR-5163.patch, SOLR-5163.patch > > > query: > q=foo AND bar > qf=field1 > qf=field2 > defType=edismax > Where field1 exists and field2 doesn't.. > will treat the AND as a term vs and operator -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5163) edismax should throw exception when qf refers to nonexistent field
[
https://issues.apache.org/jira/browse/SOLR-5163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621372#comment-16621372
]
Edward Ribeiro commented on SOLR-5163:
--
Hey, [~Charles Sanders], you could simplify things a bit more. Like [~dsmiley]
pointed out
https://jira.apache.org/jira/browse/SOLR-5163?focusedCommentId=16595133=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16595133
it is more interesting to validate the fields in
*_DismaxQueryParser#parseQueryFields_* like below:
{code:java}
try {
for (String e : queryFields.keySet()){
indexSchema.getField(e);
}
} catch (SolrException ex) {
throw new SyntaxError(ex.getMessage());
}
return queryFields;{code}
Or, even use Java8 style like below:
{code:java}
queryFields.keySet().forEach(indexSchema::getField);
return queryFields;{code}
The advantage is double fold: it gets checked for both DismaxParser and
ExtendedDismaxParser and the logic is in a well defined place (besides being a
tidy bit more simple).
As for the tests, relying too heavily on String comparisons makes the tests
fragile (a unrelated change on the return string and the test can fail). IIRC,
it is even an anti-pattern, but I know it can be difficult not to resort to
this kind of check then why not make it more economic like below?
{code:java}
/** SOLR-5163 */
@Test
public void testValidateQueryFields() throws Exception {
// test existent qf
assertJQ(req("defType", "edismax", "df", "text", "q", "olive AND other",
"qf", "subject^3 title")
, "/response/numFound==0"
);
// test nonexistent qf
try {
assertJQ(req("defType", "edismax", "df", "text", "q", "olive AND other",
"qf", "subject^3 nosuchfield")
, "/response/numFound==0"
);
fail("nosuchfield qf doesn't exists");
} catch (Exception e) {
assertEquals("undefined field: \"nosuchfield\"", e.getMessage());
}{code}
Cheers!
> edismax should throw exception when qf refers to nonexistent field
> --
>
> Key: SOLR-5163
> URL: https://issues.apache.org/jira/browse/SOLR-5163
> Project: Solr
> Issue Type: Bug
> Components: query parsers, search
>Affects Versions: 4.10.4
>Reporter: Steven Bower
>Assignee: David Smiley
>Priority: Major
> Labels: newdev
> Attachments: SOLR-5163.patch, SOLR-5163.patch
>
>
> query:
> q=foo AND bar
> qf=field1
> qf=field2
> defType=edismax
> Where field1 exists and field2 doesn't..
> will treat the AND as a term vs and operator
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5163) edismax should throw exception when qf refers to nonexistent field
[ https://issues.apache.org/jira/browse/SOLR-5163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16615578#comment-16615578 ] Edward Ribeiro commented on SOLR-5163: -- Hi [~Charles Sanders], are you still working on this issue? If not, can I provide another patch to it? > edismax should throw exception when qf refers to nonexistent field > -- > > Key: SOLR-5163 > URL: https://issues.apache.org/jira/browse/SOLR-5163 > Project: Solr > Issue Type: Bug > Components: query parsers, search >Affects Versions: 4.10.4 >Reporter: Steven Bower >Assignee: David Smiley >Priority: Major > Labels: newdev > Attachments: SOLR-5163.patch > > > query: > q=foo AND bar > qf=field1 > qf=field2 > defType=edismax > Where field1 exists and field2 doesn't.. > will treat the AND as a term vs and operator -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12773) Fix typos widely spread around codebase
[ https://issues.apache.org/jira/browse/SOLR-12773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated SOLR-12773: -- Attachment: SOLR-12773.patch > Fix typos widely spread around codebase > --- > > Key: SOLR-12773 > URL: https://issues.apache.org/jira/browse/SOLR-12773 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.4 >Reporter: Edward Ribeiro >Priority: Minor > Attachments: SOLR-12773.patch > > Time Spent: 10m > Remaining Estimate: 0h > > The typos below that are widely spread around the codebase, mostly on > comments plus one occurrence in the documentation and another one in a test > name. > _*'equivilent'*_ instead of '*_equivalent'_* > _*'respones'*_ instead of *_'responses'_* > _*'the the'*_ instead of '_*to the'*_ > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12773) Fix typos widely spread around codebase
Edward Ribeiro created SOLR-12773: - Summary: Fix typos widely spread around codebase Key: SOLR-12773 URL: https://issues.apache.org/jira/browse/SOLR-12773 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 7.4 Reporter: Edward Ribeiro The typos below that are widely spread around the codebase, mostly on comments plus one occurrence in the documentation and another one in a test name. _*'equivilent'*_ instead of '*_equivalent'_* _*'respones'*_ instead of *_'responses'_* _*'the the'*_ instead of '_*to the'*_ -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12699) make LTRScoringModel immutable (to allow hashCode caching)
[
https://issues.apache.org/jira/browse/SOLR-12699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602383#comment-16602383
]
Edward Ribeiro edited comment on SOLR-12699 at 9/3/18 6:26 PM:
---
Hi [~cpoerschke] and [~slivotov],
Just a nitpick: wrapping a collection in a Collections.unmodifiable* doesn't
make the collection strictly immutable. See, we are receiving `features` as a
parameter. Therefore, some code that still has a reference to that object can
change it underneath. Example:
{code:java}
List mutableList = new ArrayList<>();
mutableList.add("Hello");
mutableList.add("World");
List immutableList = Collections.unmodifiableList(mutableList);
System.out.println("immutableList = " + immutableList);
mutableList.add("!");
System.out.println("list2 = " + immutableList);{code}
As collections is a wrapper I could change it by modifying the `mutableList`.
AFAIK, to make it a real immutable collection it would be required to create a
defensive copy of the collection like below:
{code:java}
List immutableList = Collections.unmodifiableList(new
ArrayList<>(mutableList));{code}
Now the elements of mutableList are copied to a new ArrayList that we don't
have reference. Therefore we cannot change its elements even tough as you
pointed out, we could change fields of the objects in the collection. *The
problem with this approach is that if `features` is a large collection this
could impact the performance, so be cautions when using it.*
Finally, this line
{code:java}
this.features = features != null ? Collections.unmodifiableList(features) :
features;{code}
`this.features` receives `null` if `features` is `null`. Is that the intended
behaviour? Wouldn't be better to make it be `Lists.emptyList()` if `features`
is null? Excuse me if I am missing something, but it's usually an anti-pattern
to return null, but I am very well aware that the codebases in the wild usually
don't follow this advice.
Finally, the hashCode can be written as:
{code:java}
result = (prime * result) + Objects.hashCode(features){code}
It will automatically return 0 (zero) if features is null or the hash code of
the collection otherwise.
was (Author: eribeiro):
Hi [~cpoerschke] and [~slivotov],
Just a nitpick: wrapping a collection in a Collections.unmodifiable* doesn't
make the collection strictly immutable. See, we are receiving `features` as a
parameter. Therefore, some code that still has a reference to that object can
change it underneath. Example:
{code:java}
List mutableList = new ArrayList<>();
mutableList.add("Hello");
mutableList.add("World");
List immutableList = Collections.unmodifiableList(mutableList);
System.out.println("immutableList = " + immutableList);
mutableList.add("!");
System.out.println("list2 = " + immutableList);{code}
As collections is a wrapper I could change it by modifying the `mutableList`.
AFAIK, to make it a real immutable collection it would be required to create a
defensive copy of the collection like below:
{code:java}
List immutableList = Collections.unmodifiableList(new
ArrayList<>(mutableList));{code}
Now the elements of mutableList are copied to a new ArrayList that we don't
have reference. Therefore we cannot change its elements even tough as you
pointed out, we could change fields of the objects in the collection. *The
problem with this approach is that if `features` is a large collection this
could impact the performance, so be cautions when using it.*
Finally, this line
{code:java}
this.features = features != null ? Collections.unmodifiableList(features) :
features;{code}
`this.features` receives `null` if `features` is `null`. Is that the intended
behaviour? Wouldn't be better to make it be `Lists.emptyList()` if `features`
is null? Excuse me if I am missing something, but it's usually an anti-pattern
to return null, but I am very well aware that the codebases in the wild usually
don't follow this advice.
> make LTRScoringModel immutable (to allow hashCode caching)
> --
>
> Key: SOLR-12699
> URL: https://issues.apache.org/jira/browse/SOLR-12699
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - LTR
>Reporter: Stanislav Livotov
>Priority: Major
> Attachments: SOLR-12699.patch, SOLR-12699.patch, SOLR-12699.patch
>
>
> [~slivotov] wrote in SOLR-12688:
> bq. ... LTRScoringModel was a mutable object. It was leading to the
> calculation of hashcode on each query, which in turn can consume a lot of
> time ... So I decided to make LTRScoringModel immutable and cache hashCode
> calculation. ...
> (Please see SOLR-12688 description for overall context and analysis results.)
--
This message was sent by
[jira] [Commented] (SOLR-12699) make LTRScoringModel immutable (to allow hashCode caching)
[
https://issues.apache.org/jira/browse/SOLR-12699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602383#comment-16602383
]
Edward Ribeiro commented on SOLR-12699:
---
Hi [~cpoerschke] and [~slivotov],
Just a nitpick: wrapping a collection in a Collections.unmodifiable* doesn't
make the collection strictly immutable. See, we are receiving `features` as a
parameter. Therefore, some code that still has a reference to that object can
change it underneath. Example:
{code:java}
List mutableList = new ArrayList<>();
mutableList.add("Hello");
mutableList.add("World");
List immutableList = Collections.unmodifiableList(mutableList);
System.out.println("immutableList = " + immutableList);
mutableList.add("!");
System.out.println("list2 = " + immutableList);{code}
As collections is a wrapper I could change it by modifying the `mutableList`.
AFAIK, to make it a real immutable collection it would be required to create a
defensive copy of the collection like below:
{code:java}
List immutableList = Collections.unmodifiableList(new
ArrayList<>(mutableList));{code}
Now the elements of mutableList are copied to a new ArrayList that we don't
have reference. Therefore we cannot change its elements even tough as you
pointed out, we could change fields of the objects in the collection. *The
problem with this approach is that if `features` is a large collection this
could impact the performance, so be cautions when using it.*
Finally, this line
{code:java}
this.features = features != null ? Collections.unmodifiableList(features) :
features;{code}
`this.features` receives `null` if `features` is `null`. Is that the intended
behaviour? Wouldn't be better to make it be `Lists.emptyList()` if `features`
is null? Excuse me if I am missing something, but it's usually an anti-pattern
to return null, but I am very well aware that the codebases in the wild usually
don't follow this advice.
> make LTRScoringModel immutable (to allow hashCode caching)
> --
>
> Key: SOLR-12699
> URL: https://issues.apache.org/jira/browse/SOLR-12699
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - LTR
>Reporter: Stanislav Livotov
>Priority: Major
> Attachments: SOLR-12699.patch, SOLR-12699.patch, SOLR-12699.patch
>
>
> [~slivotov] wrote in SOLR-12688:
> bq. ... LTRScoringModel was a mutable object. It was leading to the
> calculation of hashcode on each query, which in turn can consume a lot of
> time ... So I decided to make LTRScoringModel immutable and cache hashCode
> calculation. ...
> (Please see SOLR-12688 description for overall context and analysis results.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5163) edismax should throw exception when qf refers to nonexistent field
[
https://issues.apache.org/jira/browse/SOLR-5163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595370#comment-16595370
]
Edward Ribeiro edited comment on SOLR-5163 at 8/28/18 8:03 PM:
---
Hi [~Charles Sanders], a couple of questions about your patch (congrats for
contributing, btw!):
{code:java}
validateQueryFields(req);{code}
You pass req, but req is only used to get the Schema, so why not pass the
schema, i.e., validateQueryFields(req.getSchema())?
{code:java}
protected void validateQueryFields(SolrQueryRequest req) throws SyntaxError {
if (queryFields == null || queryFields.isEmpty()) {
throw new SyntaxError("No query fields given.");
}{code}
If df is not specified then the parser will resort to use df (or throw an
exception if neither is specified). Therefore, even tough this if clause is a
nice defensive guard I don't think it really is worth now, because if
queryFields is empty the error will be thrown before reaching this method. And
even if is empty then the result is that the for-loop is not traversed.
Finally,
{code:java}
req.getSchema().getFields().keySet(){code}
could be extracted to a variable before entering the loop, instead of being
called for each field.
Best regards!
was (Author: eribeiro):
Hi [~Charles Sanders], a couple of questions about your patch (congrats for
contributing, btw!):
{code:java}
validateQueryFields(req);{code}
You pass req, but req is only used to get the Schema, so why not pass the
schema, i.e., validateQueryFields(req.getSchema())?
{code:java}
protected void validateQueryFields(SolrQueryRequest req) throws SyntaxError {
if (queryFields == null || queryFields.isEmpty()) {
throw new SyntaxError("No query fields given.");
}{code}
If df is not specified then the parser will resort to use df (or throw an
exception if neither is specified). Therefore, even tough this if clause is a
nice defensive guard I don't think it really is worth now, because if
queryFields is empty the error will be thrown before reaching this method. And
even if is empty then the result is that the for-loop is not traversed.
Finally,
{code:java}
req.getSchema().getFields().keySet(){code}
could be extracted to a variable before entering the loop, instead of being
called for each field.
Probably the test to be written should go here:
https://github.com/apache/lucene-solr/blob/master/solr/core/src/test/org/apache/solr/search/TestExtendedDismaxParser.java
Best regards!
> edismax should throw exception when qf refers to nonexistent field
> --
>
> Key: SOLR-5163
> URL: https://issues.apache.org/jira/browse/SOLR-5163
> Project: Solr
> Issue Type: Bug
> Components: query parsers, search
>Affects Versions: 4.10.4
>Reporter: Steven Bower
>Assignee: David Smiley
>Priority: Major
> Labels: newdev
> Attachments: SOLR-5163.patch
>
>
> query:
> q=foo AND bar
> qf=field1
> qf=field2
> defType=edismax
> Where field1 exists and field2 doesn't..
> will treat the AND as a term vs and operator
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5163) edismax should throw exception when qf refers to nonexistent field
[
https://issues.apache.org/jira/browse/SOLR-5163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595370#comment-16595370
]
Edward Ribeiro edited comment on SOLR-5163 at 8/28/18 8:01 PM:
---
Hi [~Charles Sanders], a couple of questions about your patch (congrats for
contributing, btw!):
{code:java}
validateQueryFields(req);{code}
You pass req, but req is only used to get the Schema, so why not pass the
schema, i.e., validateQueryFields(req.getSchema())?
{code:java}
protected void validateQueryFields(SolrQueryRequest req) throws SyntaxError {
if (queryFields == null || queryFields.isEmpty()) {
throw new SyntaxError("No query fields given.");
}{code}
If df is not specified then the parser will resort to use df (or throw an
exception if neither is specified). Therefore, even tough this if clause is a
nice defensive guard I don't think it really is worth now, because if
queryFields is empty the error will be thrown before reaching this method. And
even if is empty then the result is that the for-loop is not traversed.
Finally,
{code:java}
req.getSchema().getFields().keySet(){code}
could be extracted to a variable before entering the loop, instead of being
called for each field.
Probably the test to be written should go here:
https://github.com/apache/lucene-solr/blob/master/solr/core/src/test/org/apache/solr/search/TestExtendedDismaxParser.java
Best regards!
was (Author: eribeiro):
Hi [~Charles Sanders], a couple of questions about your patch (congrats for
contributing, btw!):
{code:java}
validateQueryFields(req);{code}
You pass req, but req is only used to get the Schema, so why not pass the
schema, i.e., validateQueryFields(req.getSchema())?
{code:java}
protected void validateQueryFields(SolrQueryRequest req) throws SyntaxError {
if (queryFields == null || queryFields.isEmpty()) {
throw new SyntaxError("No query fields given.");
}{code}
If df is not specified then the parser will resort to use df (or throw an
exception if neither is specified). Therefore, even tough this if clause is a
nice defensive guard I don't think it really is worth now, because if
queryFields is empty the error will be thrown before reaching this method. And
even if is empty then the result is that the for-loop is not traversed.
Finally,
{code:java}
req.getSchema().getFields().keySet(){code}
could be extracted to a variable before entering the loop, instead of being
called for each field.
Best regards!
> edismax should throw exception when qf refers to nonexistent field
> --
>
> Key: SOLR-5163
> URL: https://issues.apache.org/jira/browse/SOLR-5163
> Project: Solr
> Issue Type: Bug
> Components: query parsers, search
>Affects Versions: 4.10.4
>Reporter: Steven Bower
>Assignee: David Smiley
>Priority: Major
> Labels: newdev
> Attachments: SOLR-5163.patch
>
>
> query:
> q=foo AND bar
> qf=field1
> qf=field2
> defType=edismax
> Where field1 exists and field2 doesn't..
> will treat the AND as a term vs and operator
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5163) edismax should throw exception when qf refers to nonexistent field
[
https://issues.apache.org/jira/browse/SOLR-5163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595370#comment-16595370
]
Edward Ribeiro commented on SOLR-5163:
--
Hi [~Charles Sanders], a couple of questions about your patch (congrats for
contributing, btw!):
{code:java}
validateQueryFields(req);{code}
You pass req, but req is only used to get the Schema, so why not pass the
schema, i.e., validateQueryFields(req.getSchema())?
{code:java}
protected void validateQueryFields(SolrQueryRequest req) throws SyntaxError {
if (queryFields == null || queryFields.isEmpty()) {
throw new SyntaxError("No query fields given.");
}{code}
If df is not specified then the parser will resort to use df (or throw an
exception if neither is specified). Therefore, even tough this if clause is a
nice defensive guard I don't think it really is worth now, because if
queryFields is empty the error will be thrown before reaching this method. And
even if is empty then the result is that the for-loop is not traversed.
Finally,
{code:java}
req.getSchema().getFields().keySet(){code}
could be extracted to a variable before entering the loop, instead of being
called for each field.
Best regards!
> edismax should throw exception when qf refers to nonexistent field
> --
>
> Key: SOLR-5163
> URL: https://issues.apache.org/jira/browse/SOLR-5163
> Project: Solr
> Issue Type: Bug
> Components: query parsers, search
>Affects Versions: 4.10.4
>Reporter: Steven Bower
>Assignee: David Smiley
>Priority: Major
> Labels: newdev
> Attachments: SOLR-5163.patch
>
>
> query:
> q=foo AND bar
> qf=field1
> qf=field2
> defType=edismax
> Where field1 exists and field2 doesn't..
> will treat the AND as a term vs and operator
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9405) ConcurrentModificationException in ZkStateReader.getStateWatchers
[
https://issues.apache.org/jira/browse/SOLR-9405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15418238#comment-15418238
]
Edward Ribeiro commented on SOLR-9405:
--
Hi guys, I *guess* this patch doesn't solve the issue at hand.
TL;DR: the solution is to declare stateWatchers as {{stateWatchers =
ConcurrentHashMap.newKeySet();}} at L#150. That is, no need to modify
{{getStateWatchers}}.
Please, let me explain.
First, the error is happening here:
{code}
/* package-private for testing */
1. Set getStateWatchers(String collection) {
2. CollectionWatch watch = collectionWatches.get(collection);
3. if (watch == null)
4. return null;
5. return new HashSet<>(watch.stateWatchers);
6. }
{code}
That is, {{ZkStateReader.getStateWatchers}} is creating a new {{HashSet}}
instance by providing a new collection: {{CollectionWatch#stateWatchers}}. As
we can see in ZkStateReader, {{watch#stateWatchers}} is also a {{HashSet}}.
Okay, If we look into {{HashSet}}/{{AbstractCollection}} source code, we see
that the constructor seen at line 5 (ABOVE) basically calls the {{addAll}}
method passing the collection provided via the constructor. Then {{addAll}}
basically loops on collection provided including the elements one by one in the
new collection. See in the stack trace provided in this issue:
{code}
at java.util.HashMap$KeyIterator.next(java.base@9-ea/HashMap.java:1513) //
RUNNING THE FOR-EACH LOOP
at
java.util.AbstractCollection.addAll(java.base@9-ea/AbstractCollection.java:351)
// DELEGATES TO ADDALL
at java.util.HashSet.(java.base@9-ea/HashSet.java:119) // THE CONSTRUCTOR
{code}
In a nutshell, what is happening is that while we are populating the new
{{HashSet}} instance at line 5 of ZkStateReader a new Thread changes
{{stateWatchers}} concurrently. This throws the
{{ConcurrentModificationException}}
*The proposed patch doesn't solve the issue because even if
{{collectionWatches.compute}} is atomic, none of the {{Sets}} in use in
ZkStateReader is thread-safe.*
I wrote a test program to demonstrate my speculation:
https://gist.github.com/eribeiro/4141df2d02c62d7370101bc4349cd8c4
Finally, sorry if I misunderstood the problem, and let me know if what I wrote
made any sense. :)
Cheers!
> ConcurrentModificationException in ZkStateReader.getStateWatchers
> -
>
> Key: SOLR-9405
> URL: https://issues.apache.org/jira/browse/SOLR-9405
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 6.1
>Reporter: Shalin Shekhar Mangar
>Assignee: Alan Woodward
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9405.patch
>
>
> Jenkins found this: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1432/
> {code}
> Stack Trace:
> java.util.ConcurrentModificationException
> at
> __randomizedtesting.SeedInfo.seed([FA459DF725097EFF:A77E52876204E1C1]:0)
> at
> java.util.HashMap$HashIterator.nextNode(java.base@9-ea/HashMap.java:1489)
> at
> java.util.HashMap$KeyIterator.next(java.base@9-ea/HashMap.java:1513)
> at
> java.util.AbstractCollection.addAll(java.base@9-ea/AbstractCollection.java:351)
> at java.util.HashSet.(java.base@9-ea/HashSet.java:119)
> at
> org.apache.solr.common.cloud.ZkStateReader.getStateWatchers(ZkStateReader.java:1279)
> at
> org.apache.solr.common.cloud.TestCollectionStateWatchers.testSimpleCollectionWatch(TestCollectionStateWatchers.java:116)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8095) Allow disabling HDFS Locality Metrics
[
https://issues.apache.org/jira/browse/SOLR-8095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14907270#comment-14907270
]
Edward Ribeiro commented on SOLR-8095:
--
[~mdrob] Not want to preach to the choir, but what about changing the constant
name to {{LOCALITY_METRICS_ENABLED}}? Easy to read in imho.
> Allow disabling HDFS Locality Metrics
> -
>
> Key: SOLR-8095
> URL: https://issues.apache.org/jira/browse/SOLR-8095
> Project: Solr
> Issue Type: Bug
> Components: hdfs
>Reporter: Mike Drob
> Labels: metrics
> Fix For: Trunk
>
> Attachments: SOLR-8095.patch
>
>
> We added metrics, but not a way to configure/turn them off.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-8095) Allow disabling HDFS Locality Metrics
[
https://issues.apache.org/jira/browse/SOLR-8095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14907270#comment-14907270
]
Edward Ribeiro edited comment on SOLR-8095 at 9/24/15 11:50 PM:
[~mdrob] Don't want to preach to the choir, but what about changing the
constant name to {{LOCALITY_METRICS_ENABLED}}? Easy to read in imho.
was (Author: eribeiro):
[~mdrob] Not want to preach to the choir, but what about changing the constant
name to {{LOCALITY_METRICS_ENABLED}}? Easy to read in imho.
> Allow disabling HDFS Locality Metrics
> -
>
> Key: SOLR-8095
> URL: https://issues.apache.org/jira/browse/SOLR-8095
> Project: Solr
> Issue Type: Bug
> Components: hdfs
>Reporter: Mike Drob
> Labels: metrics
> Fix For: Trunk
>
> Attachments: SOLR-8095.patch
>
>
> We added metrics, but not a way to configure/turn them off.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7951) LBHttpSolrClient wraps ALL exceptions in "No live SolrServers available to handle this request" exception, even usage errors
[ https://issues.apache.org/jira/browse/SOLR-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14736944#comment-14736944 ] Edward Ribeiro commented on SOLR-7951: -- Hi [~markrmil...@gmail.com], Sorry for bothering you, but does the current patch looks okay? Any idea if we can commit this patch now or it needs further refining/work? /cc [~ecario] Thanks! Eddie > LBHttpSolrClient wraps ALL exceptions in "No live SolrServers available to > handle this request" exception, even usage errors > > > Key: SOLR-7951 > URL: https://issues.apache.org/jira/browse/SOLR-7951 > Project: Solr > Issue Type: Bug > Components: SolrJ >Affects Versions: 5.2.1 >Reporter: Elaine Cario >Assignee: Mark Miller >Priority: Minor > Attachments: SOLR-7951-4.x.patch, SOLR-7951-4.x.patch, SOLR-7951.patch > > > We were experiencing many "No live SolrServers available to handle this > request" exception, even though we saw no outages with any of our servers. > It turned out the actual exceptions were related to the use of wildcards in > span queries (and in some cases other invalid queries or usage-type issues). > Traced it back to LBHttpSolrClient which was wrapping all exceptions, even > plain SolrExceptions, in that outer exception. > Instead, wrapping in the out exception should be reserved for true > communication issues in SolrCloud, and usage exceptions should be thrown as > is. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-7951) LBHttpSolrClient wraps ALL exceptions in No live SolrServers available to handle this request exception, even usage errors
[
https://issues.apache.org/jira/browse/SOLR-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14707205#comment-14707205
]
Edward Ribeiro edited comment on SOLR-7951 at 8/21/15 6:23 PM:
---
Cool, [~ecario]! :) Only thing I've got confused about the new patch is that it
still cast to SolrServerException. *Shouldn't it be casted to SolrException
now?*
{code}
} else if (ex instanceof SolrException) {
throw (SolrServerException) ex;
{code}
Also, it would be nice to document this as [~markrmil...@gmail.com] suggested
above too for future devs.
Mark, let us know if you think this patch is okay, please?
ps: So, the test I included was flawed. I wish we had a test to validate this
fix. Any ideas?
was (Author: eribeiro):
Cool, [~ecario]! :) Only thing I've got confused about the new patch is that it
still cast to SolrServerException. Shouldn't it be casted to SolrException now?
{{quote}}
+} else if (ex instanceof SolrException) {
+ throw (SolrServerException) ex;
{{quote}}
Also, it would be nice to document this as [~markrmil...@gmail.com] suggested
above too for future devs.
Mark, let us know if you think this patch is okay, please?
ps: So, the test I included was flawed. I wish we had a test to validate this
fix. Any ideas?
LBHttpSolrClient wraps ALL exceptions in No live SolrServers available to
handle this request exception, even usage errors
Key: SOLR-7951
URL: https://issues.apache.org/jira/browse/SOLR-7951
Project: Solr
Issue Type: Bug
Components: SolrJ
Affects Versions: 5.2.1
Reporter: Elaine Cario
Priority: Minor
Attachments: SOLR-7951-4.x.patch, SOLR-7951.patch
We were experiencing many No live SolrServers available to handle this
request exception, even though we saw no outages with any of our servers.
It turned out the actual exceptions were related to the use of wildcards in
span queries (and in some cases other invalid queries or usage-type issues).
Traced it back to LBHttpSolrClient which was wrapping all exceptions, even
plain SolrExceptions, in that outer exception.
Instead, wrapping in the out exception should be reserved for true
communication issues in SolrCloud, and usage exceptions should be thrown as
is.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7951) LBHttpSolrClient wraps ALL exceptions in No live SolrServers available to handle this request exception, even usage errors
[
https://issues.apache.org/jira/browse/SOLR-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14707205#comment-14707205
]
Edward Ribeiro commented on SOLR-7951:
--
Cool, [~ecario]! :) Only thing I've got confused about the new patch is that it
still cast to SolrServerException. Shouldn't it be casted to SolrException now?
{{quote}}
+} else if (ex instanceof SolrException) {
+ throw (SolrServerException) ex;
{{quote}}
Also, it would be nice to document this as [~markrmil...@gmail.com] suggested
above too for future devs.
Mark, let us know if you think this patch is okay, please?
ps: So, the test I included was flawed. I wish we had a test to validate this
fix. Any ideas?
LBHttpSolrClient wraps ALL exceptions in No live SolrServers available to
handle this request exception, even usage errors
Key: SOLR-7951
URL: https://issues.apache.org/jira/browse/SOLR-7951
Project: Solr
Issue Type: Bug
Components: SolrJ
Affects Versions: 5.2.1
Reporter: Elaine Cario
Priority: Minor
Attachments: SOLR-7951-4.x.patch, SOLR-7951.patch
We were experiencing many No live SolrServers available to handle this
request exception, even though we saw no outages with any of our servers.
It turned out the actual exceptions were related to the use of wildcards in
span queries (and in some cases other invalid queries or usage-type issues).
Traced it back to LBHttpSolrClient which was wrapping all exceptions, even
plain SolrExceptions, in that outer exception.
Instead, wrapping in the out exception should be reserved for true
communication issues in SolrCloud, and usage exceptions should be thrown as
is.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7951) LBHttpSolrClient wraps ALL exceptions in No live SolrServers available to handle this request exception, even usage errors
[ https://issues.apache.org/jira/browse/SOLR-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14707209#comment-14707209 ] Edward Ribeiro commented on SOLR-7951: -- Yeah, you right. I couldn't think of a better test to include. :( LBHttpSolrClient wraps ALL exceptions in No live SolrServers available to handle this request exception, even usage errors Key: SOLR-7951 URL: https://issues.apache.org/jira/browse/SOLR-7951 Project: Solr Issue Type: Bug Components: SolrJ Affects Versions: 5.2.1 Reporter: Elaine Cario Priority: Minor Attachments: SOLR-7951-4.x.patch, SOLR-7951.patch We were experiencing many No live SolrServers available to handle this request exception, even though we saw no outages with any of our servers. It turned out the actual exceptions were related to the use of wildcards in span queries (and in some cases other invalid queries or usage-type issues). Traced it back to LBHttpSolrClient which was wrapping all exceptions, even plain SolrExceptions, in that outer exception. Instead, wrapping in the out exception should be reserved for true communication issues in SolrCloud, and usage exceptions should be thrown as is. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7951) LBHttpSolrClient wraps ALL exceptions in No live SolrServers available to handle this request exception, even usage errors
[ https://issues.apache.org/jira/browse/SOLR-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14707210#comment-14707210 ] Edward Ribeiro commented on SOLR-7951: -- Yeah, you right. I couldn't think of a better test to include. :( LBHttpSolrClient wraps ALL exceptions in No live SolrServers available to handle this request exception, even usage errors Key: SOLR-7951 URL: https://issues.apache.org/jira/browse/SOLR-7951 Project: Solr Issue Type: Bug Components: SolrJ Affects Versions: 5.2.1 Reporter: Elaine Cario Priority: Minor Attachments: SOLR-7951-4.x.patch, SOLR-7951.patch We were experiencing many No live SolrServers available to handle this request exception, even though we saw no outages with any of our servers. It turned out the actual exceptions were related to the use of wildcards in span queries (and in some cases other invalid queries or usage-type issues). Traced it back to LBHttpSolrClient which was wrapping all exceptions, even plain SolrExceptions, in that outer exception. Instead, wrapping in the out exception should be reserved for true communication issues in SolrCloud, and usage exceptions should be thrown as is. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-7951) LBHttpSolrClient wraps ALL exceptions in No live SolrServers available to handle this request exception, even usage errors
[
https://issues.apache.org/jira/browse/SOLR-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14707205#comment-14707205
]
Edward Ribeiro edited comment on SOLR-7951 at 8/21/15 6:42 PM:
---
Cool, [~ecario]! :) Only thing I've got confused about the new patch is that it
still cast to SolrServerException. --Shouldn't it be casted to SolrException
now?-- I see that the method signature throws SolrServerException, but I didn't
get why it didn't throw ClassCastException...
{code}
} else if (ex instanceof SolrException) {
throw (SolrServerException) ex;
{code}
Also, it would be nice to document this as [~markrmil...@gmail.com] suggested
above too for future devs.
Mark, let us know if you think this patch is okay, please? I mean, if it
addresses your other concerns with my original patch.
ps: So, the test I included was flawed. I wish we had a test to validate this
fix. Any ideas?
was (Author: eribeiro):
Cool, [~ecario]! :) Only thing I've got confused about the new patch is that it
still cast to SolrServerException. *Shouldn't it be casted to SolrException
now?*
{code}
} else if (ex instanceof SolrException) {
throw (SolrServerException) ex;
{code}
Also, it would be nice to document this as [~markrmil...@gmail.com] suggested
above too for future devs.
Mark, let us know if you think this patch is okay, please?
ps: So, the test I included was flawed. I wish we had a test to validate this
fix. Any ideas?
LBHttpSolrClient wraps ALL exceptions in No live SolrServers available to
handle this request exception, even usage errors
Key: SOLR-7951
URL: https://issues.apache.org/jira/browse/SOLR-7951
Project: Solr
Issue Type: Bug
Components: SolrJ
Affects Versions: 5.2.1
Reporter: Elaine Cario
Priority: Minor
Attachments: SOLR-7951-4.x.patch, SOLR-7951.patch
We were experiencing many No live SolrServers available to handle this
request exception, even though we saw no outages with any of our servers.
It turned out the actual exceptions were related to the use of wildcards in
span queries (and in some cases other invalid queries or usage-type issues).
Traced it back to LBHttpSolrClient which was wrapping all exceptions, even
plain SolrExceptions, in that outer exception.
Instead, wrapping in the out exception should be reserved for true
communication issues in SolrCloud, and usage exceptions should be thrown as
is.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-7951) LBHttpSolrClient wraps ALL exceptions in No live SolrServers available to handle this request exception, even usage errors
[ https://issues.apache.org/jira/browse/SOLR-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated SOLR-7951: - Comment: was deleted (was: Yeah, you right. I couldn't think of a better test to include. :() LBHttpSolrClient wraps ALL exceptions in No live SolrServers available to handle this request exception, even usage errors Key: SOLR-7951 URL: https://issues.apache.org/jira/browse/SOLR-7951 Project: Solr Issue Type: Bug Components: SolrJ Affects Versions: 5.2.1 Reporter: Elaine Cario Priority: Minor Attachments: SOLR-7951-4.x.patch, SOLR-7951.patch We were experiencing many No live SolrServers available to handle this request exception, even though we saw no outages with any of our servers. It turned out the actual exceptions were related to the use of wildcards in span queries (and in some cases other invalid queries or usage-type issues). Traced it back to LBHttpSolrClient which was wrapping all exceptions, even plain SolrExceptions, in that outer exception. Instead, wrapping in the out exception should be reserved for true communication issues in SolrCloud, and usage exceptions should be thrown as is. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7951) LBHttpSolrClient wraps ALL exceptions in No live SolrServers available to handle this request exception, even usage errors
[ https://issues.apache.org/jira/browse/SOLR-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated SOLR-7951: - Attachment: SOLR-7951.patch Hi [~markrmil...@gmail.com] and [~ecario], I am attaching a patch for your evaluation. It's just a suggestion so feel free to ignore it or improve on it. :) Mark, while looking at this issue, I have seen that LBHttpSolrClientTest (with only a test method) and TestLBHttpSolrClient. Maybe it would be a nice opportunity to merge them? Furthermore, I have included a simple test into TestLBHttpSolrClient, but I am not quite pleased with it. Wdyt? If you could suggest a better way of testing this issue, it would be really nice, but otherwise we can keep it as-is, or remove it. LBHttpSolrClient wraps ALL exceptions in No live SolrServers available to handle this request exception, even usage errors Key: SOLR-7951 URL: https://issues.apache.org/jira/browse/SOLR-7951 Project: Solr Issue Type: Bug Components: SolrJ Affects Versions: 5.2.1 Reporter: Elaine Cario Priority: Minor Attachments: SOLR-7951.patch We were experiencing many No live SolrServers available to handle this request exception, even though we saw no outages with any of our servers. It turned out the actual exceptions were related to the use of wildcards in span queries (and in some cases other invalid queries or usage-type issues). Traced it back to LBHttpSolrClient which was wrapping all exceptions, even plain SolrExceptions, in that outer exception. Instead, wrapping in the out exception should be reserved for true communication issues in SolrCloud, and usage exceptions should be thrown as is. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7951) LBHttpSolrClient wraps ALL exceptions in No live SolrServers available to handle this request exception, even usage errors
[ https://issues.apache.org/jira/browse/SOLR-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14705835#comment-14705835 ] Edward Ribeiro commented on SOLR-7951: -- Oops, sorry [~ecario], not my intention. :) Please, let me know if this patch solves your issue and how we could improve it, particularly the unit test. Cheers! LBHttpSolrClient wraps ALL exceptions in No live SolrServers available to handle this request exception, even usage errors Key: SOLR-7951 URL: https://issues.apache.org/jira/browse/SOLR-7951 Project: Solr Issue Type: Bug Components: SolrJ Affects Versions: 5.2.1 Reporter: Elaine Cario Priority: Minor Attachments: SOLR-7951.patch We were experiencing many No live SolrServers available to handle this request exception, even though we saw no outages with any of our servers. It turned out the actual exceptions were related to the use of wildcards in span queries (and in some cases other invalid queries or usage-type issues). Traced it back to LBHttpSolrClient which was wrapping all exceptions, even plain SolrExceptions, in that outer exception. Instead, wrapping in the out exception should be reserved for true communication issues in SolrCloud, and usage exceptions should be thrown as is. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6744) equals methods should compare classes directly, not use instanceof
[
https://issues.apache.org/jira/browse/LUCENE-6744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701688#comment-14701688
]
Edward Ribeiro commented on LUCENE-6744:
My two cents: I have always preferred to use {{instanceof}}, but was unaware of
the potential problems and inconsistencies of using it. :( So, for stir up a
little bit of discussion, I would like let you with two SO links that discuss
this issue in depth:
http://stackoverflow.com/questions/596462/any-reason-to-prefer-getclass-over-instanceof-when-generating-equals
http://stackoverflow.com/questions/27581/what-issues-should-be-considered-when-overriding-equals-and-hashcode-in-java/32223#32223
Best,
eddie
equals methods should compare classes directly, not use instanceof
--
Key: LUCENE-6744
URL: https://issues.apache.org/jira/browse/LUCENE-6744
Project: Lucene - Core
Issue Type: Bug
Reporter: Hoss Man
Labels: newdev
from a 2015-07-12 email to the dev list from Fuxiang Chen...
{noformat}
We have found some inconsistencies in the overriding of the equals() method
in some files with respect to the conforming to the contract structure
based on the Java Specification.
Affected files:
1) ConstValueSource.java
2) DoubleConstValueSource.java
3) FixedBitSet.java
4) GeohashFunction.java
5) LongBitSet.java
6) SpanNearQuery.java
7) StringDistanceFunction.java
8) ValueSourceRangeFilter.java
9) VectorDistanceFunction.java
The above files all uses instanceof in the overridden equals() method in
comparing two objects.
According to the Java Specification, the equals() method must be reflexive,
symmetric, transitive and consistent. In the case of symmetric, it is
stated that x.equals(y) should return true if and only if y.equals(x)
returns true. Using instanceof is asymmetric and is not a valid symmetric
contract.
A more preferred way will be to compare the classes instead. i.e. if
(this.getClass() != o.getClass()).
However, if compiling the source code using JDK 7 and above, and if
developers still prefer to use instanceof, you can make use of the static
methods of Objects such as Objects.equals(this.id, that.id). (Making use of
the static methods of Objects is currently absent in the methods.) It will
be easier to override the equals() method and will ensure that the
overridden equals() method will fulfill the contract rules.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-7809) Add support to Collections API in SolrJ
[ https://issues.apache.org/jira/browse/SOLR-7809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14632091#comment-14632091 ] Edward Ribeiro edited comment on SOLR-7809 at 7/17/15 11:22 PM: oops, sorry! I opened this jira due to a brief discussion on #solr channel. At first, I didn't find SOLR-6448 nor the classes, but should have looked for more carefully. :( I am closing it now. Sorry about the noise. :( Thanks for pointing out the right JIRA. was (Author: eribeiro): oops, sorry! I opened this jira due to a brief discussion on #solr channel. At first, I didn't find SOLR-6448 nor the classes, but should have looked for more carefully. Sorry about the noise. :( Please, feel free to close it asap! Thanks Add support to Collections API in SolrJ --- Key: SOLR-7809 URL: https://issues.apache.org/jira/browse/SOLR-7809 Project: Solr Issue Type: Improvement Components: clients - java, SolrCloud, SolrJ Affects Versions: 5.0 Reporter: Edward Ribeiro Add support for Collections API ( https://cwiki.apache.org/confluence/display/solr/Collections+API ) in SolrJ. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-7809) Add support to Collections API in SolrJ
[ https://issues.apache.org/jira/browse/SOLR-7809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro closed SOLR-7809. Resolution: Duplicate Add support to Collections API in SolrJ --- Key: SOLR-7809 URL: https://issues.apache.org/jira/browse/SOLR-7809 Project: Solr Issue Type: Improvement Components: clients - java, SolrCloud, SolrJ Affects Versions: 5.0 Reporter: Edward Ribeiro Add support for Collections API ( https://cwiki.apache.org/confluence/display/solr/Collections+API ) in SolrJ. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7809) Add support to Collections API in SolrJ
[ https://issues.apache.org/jira/browse/SOLR-7809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated SOLR-7809: - Summary: Add support to Collections API in SolrJ (was: Solrj - Add support to Collections API) Add support to Collections API in SolrJ --- Key: SOLR-7809 URL: https://issues.apache.org/jira/browse/SOLR-7809 Project: Solr Issue Type: Improvement Components: clients - java, SolrCloud, SolrJ Affects Versions: 5.0 Reporter: Edward Ribeiro Add support for Collections API ( https://cwiki.apache.org/confluence/display/solr/Collections+API ) in SolrJ. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7809) Solrj - Add support to Collections API
Edward Ribeiro created SOLR-7809: Summary: Solrj - Add support to Collections API Key: SOLR-7809 URL: https://issues.apache.org/jira/browse/SOLR-7809 Project: Solr Issue Type: Improvement Components: clients - java, SolrCloud, SolrJ Affects Versions: 5.0 Reporter: Edward Ribeiro Add support for Collections API ( https://cwiki.apache.org/confluence/display/solr/Collections+API ) in SolrJ. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7809) Add support to Collections API in SolrJ
[ https://issues.apache.org/jira/browse/SOLR-7809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14632091#comment-14632091 ] Edward Ribeiro commented on SOLR-7809: -- oops, sorry! I opened this jira due to a brief discussion on #solr channel. At first, I didn't find SOLR-6448 nor the classes, but should have looked for more carefully. Sorry about the noise. :( Please, feel free to close it asap! Thanks Add support to Collections API in SolrJ --- Key: SOLR-7809 URL: https://issues.apache.org/jira/browse/SOLR-7809 Project: Solr Issue Type: Improvement Components: clients - java, SolrCloud, SolrJ Affects Versions: 5.0 Reporter: Edward Ribeiro Add support for Collections API ( https://cwiki.apache.org/confluence/display/solr/Collections+API ) in SolrJ. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7705) CoreAdminHandler Unload no longer handles null core name.
[ https://issues.apache.org/jira/browse/SOLR-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated SOLR-7705: - Attachment: SOLR-7705.2.patch Attaching new version CoreAdminHandler Unload no longer handles null core name. - Key: SOLR-7705 URL: https://issues.apache.org/jira/browse/SOLR-7705 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 4.10, 5.0, 5.1, 5.2 Environment: Windows 8 and Windows Server 2012 R2 Reporter: John Call Priority: Minor Labels: easyfix Fix For: 4.10, 5.0, 5.1, 5.2, Trunk Attachments: SOLR-7705.2.patch, SOLR-7705.patch Original Estimate: 1h Remaining Estimate: 1h Pre 4.10 If a null core name was passed in it would be handled as a bad request with error message No such core exists [ null ]. From 4.10 onwards an unload call goes to CoreContainer unload where the first action taken is removing the core from coreInitFailures which throws when given null and instead of returning the expected BadRequest Cannot unload non-existent core [null] it returns InternalServerError java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.replaceNode(Unknown Source) at java.util.concurrent.ConcurrentHashMap.remove(Unknown Source) at org.apache.solr.core.CoreContainer.unload(CoreContainer.java:661)... This was found due to mixing up query parameter name used in create vs core in unload. As a result this is easily reproducible with http://localhost:8983/solr/admin/cores?action=UNLOADname=core0 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7666) Umbrella ticket for Angular JS post-5.2.1 issues
[ https://issues.apache.org/jira/browse/SOLR-7666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14622718#comment-14622718 ] Edward Ribeiro commented on SOLR-7666: -- Adding this issue to the todo list of the new UI as the old one is gonna be retired eventually. Umbrella ticket for Angular JS post-5.2.1 issues Key: SOLR-7666 URL: https://issues.apache.org/jira/browse/SOLR-7666 Project: Solr Issue Type: New Feature Components: UI Affects Versions: 5.3, Trunk Reporter: Erick Erickson Assignee: Upayavira As of Solr 5.2.1, there's a new admin UI available that has been written almost entirely by Upayavira (thanks!) over the last several months. It's written in Angular JS with an eye towards enhancement/maintainability. The default UI is still the old version, but you can access the new version by going to http://sever:port/solr/index.html. There are a couple of fixes between 5.2.0 and 5.2.1, so please use either a fresh 5x checkout, trunk, or 5.2.1 The expectation is that in Solr 5.3, the new code will become the default with the old UI deprecated and eventually removed. So it would be a great help if volunteers could give the new UI a spin. It should look much the same as the current one at the start, but evolve into something much more interesting and more cloud-friendly. Of course all the new UI code will always be available on trunk/6.0 too, and the up-to-date code will always be on both the trunk and 5x branches. Please provide feedback on the user's (or dev) lists about anything you find that doesn't work, or enhancements you'd like to see (or, even better, contribute). If you raise a JIRA, please link it to this one so I can keep track of what needs to be committed. If linking JIRAs is a mystery just add a comment to this JIRA referencing the new JIRA and we can take care of it. Please do _not_ attach patches to this JIRA, it'll be much easier to keep track of everything if the patches are attached to sub-JIRAs. And a big thanks to Upayavira for this work! -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7529) NullPointerException in RELOAD-command in CoreAdmin
[
https://issues.apache.org/jira/browse/SOLR-7529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated SOLR-7529:
-
Attachment: SOLR-7529.patch
Hi [~elyograg], I have attached a patch for this issue and a related one:
SOLR-7705. Let me know if they need some tweaking or fix. :)
Cheers.
NullPointerException in RELOAD-command in CoreAdmin
---
Key: SOLR-7529
URL: https://issues.apache.org/jira/browse/SOLR-7529
Project: Solr
Issue Type: Bug
Affects Versions: 5.1
Reporter: Jellyfrog
Priority: Minor
Attachments: SOLR-7529.patch
http://solr.local:8983/solr/admin/cores?action=RELOAD
{code}
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeaderint name=status500/intint
name=QTime1/int/lstlst name=errorstr
name=tracejava.lang.NullPointerException
at java.util.TreeMap.getEntry(TreeMap.java:347)
at java.util.TreeMap.containsKey(TreeMap.java:232)
at java.util.TreeSet.contains(TreeSet.java:234)
at
org.apache.solr.handler.admin.CoreAdminHandler.handleReloadAction(CoreAdminHandler.java:713)
at
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestInternal(CoreAdminHandler.java:223)
at
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:186)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:144)
at
org.apache.solr.servlet.SolrDispatchFilter.handleAdminRequest(SolrDispatchFilter.java:736)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:261)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:204)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
at
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:745)
/strint name=code500/int/lst
/response
{code}
http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/admin/CoreAdminHandler.java?view=markup#l768
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7767) Zookeeper Ensamble Admin UI
[ https://issues.apache.org/jira/browse/SOLR-7767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14622772#comment-14622772 ] Edward Ribeiro commented on SOLR-7767: -- Oops, sorry [~upayavira], got it. Thanks for explaining. :) Zookeeper Ensamble Admin UI --- Key: SOLR-7767 URL: https://issues.apache.org/jira/browse/SOLR-7767 Project: Solr Issue Type: New Feature Components: SolrCloud, UI, web gui Reporter: Aniket Khare For SolrCloud mode can we have the functionality to display the live nodes from the zookeeper ensemble. So that user can easily get to know if any of zookeeper instance is down or having any other issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7705) CoreAdminHandler Unload no longer handles null core name.
[ https://issues.apache.org/jira/browse/SOLR-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated SOLR-7705: - Attachment: SOLR-7705.patch Hi, I am have attached a patch. It's against lucene_solr_5_0 since lucene_solr_4_10 involves some more changes, but I can backport it to 4.9 too if you feel like doing it. Please, see if the patch fits. CoreAdminHandler Unload no longer handles null core name. - Key: SOLR-7705 URL: https://issues.apache.org/jira/browse/SOLR-7705 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 4.10, 5.0, 5.1, 5.2 Environment: Windows 8 and Windows Server 2012 R2 Reporter: John Call Priority: Minor Labels: easyfix Fix For: 4.10, 5.0, 5.1, 5.2, Trunk Attachments: SOLR-7705.patch Original Estimate: 1h Remaining Estimate: 1h Pre 4.10 If a null core name was passed in it would be handled as a bad request with error message No such core exists [ null ]. From 4.10 onwards an unload call goes to CoreContainer unload where the first action taken is removing the core from coreInitFailures which throws when given null and instead of returning the expected BadRequest Cannot unload non-existent core [null] it returns InternalServerError java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.replaceNode(Unknown Source) at java.util.concurrent.ConcurrentHashMap.remove(Unknown Source) at org.apache.solr.core.CoreContainer.unload(CoreContainer.java:661)... This was found due to mixing up query parameter name used in create vs core in unload. As a result this is easily reproducible with http://localhost:8983/solr/admin/cores?action=UNLOADname=core0 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-7705) CoreAdminHandler Unload no longer handles null core name.
[ https://issues.apache.org/jira/browse/SOLR-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14621471#comment-14621471 ] Edward Ribeiro edited comment on SOLR-7705 at 7/10/15 12:11 AM: Hi, I have attached a patch. Please, let me know what you think. ps: the patch is against lucene_solr_5_0 since lucene_solr_4_10 involves some more changes, but I can backport it to 4.9 too if you feel like doing it. Cheers, Eddie was (Author: eribeiro): Hi, I am have attached a patch. It's against lucene_solr_5_0 since lucene_solr_4_10 involves some more changes, but I can backport it to 4.9 too if you feel like doing it. Please, see if the patch fits. CoreAdminHandler Unload no longer handles null core name. - Key: SOLR-7705 URL: https://issues.apache.org/jira/browse/SOLR-7705 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 4.10, 5.0, 5.1, 5.2 Environment: Windows 8 and Windows Server 2012 R2 Reporter: John Call Priority: Minor Labels: easyfix Fix For: 4.10, 5.0, 5.1, 5.2, Trunk Attachments: SOLR-7705.patch Original Estimate: 1h Remaining Estimate: 1h Pre 4.10 If a null core name was passed in it would be handled as a bad request with error message No such core exists [ null ]. From 4.10 onwards an unload call goes to CoreContainer unload where the first action taken is removing the core from coreInitFailures which throws when given null and instead of returning the expected BadRequest Cannot unload non-existent core [null] it returns InternalServerError java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.replaceNode(Unknown Source) at java.util.concurrent.ConcurrentHashMap.remove(Unknown Source) at org.apache.solr.core.CoreContainer.unload(CoreContainer.java:661)... This was found due to mixing up query parameter name used in create vs core in unload. As a result this is easily reproducible with http://localhost:8983/solr/admin/cores?action=UNLOADname=core0 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
