[jira] [Commented] (SOLR-3178) Versioning - optimistic locking
[ https://issues.apache.org/jira/browse/SOLR-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258226#comment-13258226 ] Yonik Seeley commented on SOLR-3178: bq. I will change my strategy and deliver a rough patch as soon as the merge has finished That's great, I'm sure you'll find more success with breaking it up into many smaller issues - different committers will be able to help on different things as their interest time allow. I'd really like to try and get the bare essentials of optimistic locking in soon, so the sooner you can show us a draft patch for just that piece so we can decide what approach to go with, the better! There's no need to wait to merge up to trunk to show us how your approach differs. Versioning - optimistic locking --- Key: SOLR-3178 URL: https://issues.apache.org/jira/browse/SOLR-3178 Project: Solr Issue Type: New Feature Components: update Affects Versions: 3.5 Environment: All Reporter: Per Steffensen Assignee: Per Steffensen Labels: RDBMS, insert, locking, nosql, optimistic, uniqueKey, update, versioning Fix For: 4.0 Attachments: SOLR-3178.patch Original Estimate: 168h Remaining Estimate: 168h In order increase the ability of Solr to be used as a NoSql database (lots of concurrent inserts, updates, deletes and queries in the entire lifetime of the index) instead of just a search index (first: everything indexed (in one thread), after: only queries), I would like Solr to support versioning to be used for optimistic locking. When my intent (see SOLR-3173) is to update an existing document, I will need to provide a version-number equal to the version number I got when I fetched the existing document for update plus one. If this provided version-number does not correspond to the newest version-number of that document at the time of update plus one, I will get a VersionConflict error. If it does correspond the document will be updated with the new one, so that the newest version-number of that document is NOW one higher than before the update. Correct but efficient concurrency handling. When my intent (see SOLR-3173) is to insert a new document, the version number provided will not be used - instead a version-number 0 will be used. According to SOLR-3173 insert will only succeed if a document with the same value on uniqueKey-field does not already exist. In general when talking about different versions of the same document, of course we need to be able to identify when a document is the same - that, per definition, is when the values of the uniqueKey-fields are equal. The functionality provided by this issue is only really meaningfull when you run with updateLog activated. This issue might be solved more or less at the same time as SOLR-3173, and only one single SVN patch might be given to cover both issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3387) UpdateRequestHandler should support XML,CSV,JSON, and javabin
[ https://issues.apache.org/jira/browse/SOLR-3387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258376#comment-13258376 ] Yonik Seeley commented on SOLR-3387: And default wt based on that? (i.e. xml, JSON or javabin) UpdateRequestHandler should support XML,CSV,JSON, and javabin - Key: SOLR-3387 URL: https://issues.apache.org/jira/browse/SOLR-3387 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Fix For: 4.0 Rather then have 4 handlers to support 4 content types, we should use a single endpoint and pick the ContentStreamLoader based on the ContentType This will simplify configuration problems for clients that want to swtich format (see SOLR-3038) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3387) UpdateRequestHandler should support XML,CSV,JSON, and javabin
[
https://issues.apache.org/jira/browse/SOLR-3387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258415#comment-13258415
]
Yonik Seeley commented on SOLR-3387:
bq. Any red flags?
What about stream.body? And how does this play with multi-part uploads?
It would also be nice to be able to leave off the -H
'Content-type:application/json' stuff when we do curl examples... but curl
defaults to form encoded. I wonder if we could do some sort of auto-detect in
the case of form-encoded... starting with would be XML,
starting with [or{ would be JSON.
UpdateRequestHandler should support XML,CSV,JSON, and javabin
-
Key: SOLR-3387
URL: https://issues.apache.org/jira/browse/SOLR-3387
Project: Solr
Issue Type: Improvement
Reporter: Ryan McKinley
Fix For: 4.0
Rather then have 4 handlers to support 4 content types, we should use a
single endpoint and pick the ContentStreamLoader based on the ContentType
This will simplify configuration problems for clients that want to swtich
format (see SOLR-3038)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3387) UpdateRequestHandler should support XML,CSV,JSON, and javabin
[ https://issues.apache.org/jira/browse/SOLR-3387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258436#comment-13258436 ] Yonik Seeley commented on SOLR-3387: bq. I'll poke – getStream().mark()/reset() can probably work for XML/JSON but it may break things for javabin Yeah, support doesn't need to be universal or anything... I think this would really be only for easier curl from the command line (i.e. not important for javabin) UpdateRequestHandler should support XML,CSV,JSON, and javabin - Key: SOLR-3387 URL: https://issues.apache.org/jira/browse/SOLR-3387 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Fix For: 4.0 Rather then have 4 handlers to support 4 content types, we should use a single endpoint and pick the ContentStreamLoader based on the ContentType This will simplify configuration problems for clients that want to swtich format (see SOLR-3038) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3178) Versioning - optimistic locking
[ https://issues.apache.org/jira/browse/SOLR-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257630#comment-13257630 ] Yonik Seeley commented on SOLR-3178: I think the best way to do this is really incrementally. What's done so far should really be a strict sub-set of everything you were thinking of (since changed to use 409 as the error code), and is useful on it's own. Don't worry... you'll get credit! Versioning - optimistic locking --- Key: SOLR-3178 URL: https://issues.apache.org/jira/browse/SOLR-3178 Project: Solr Issue Type: New Feature Components: update Affects Versions: 3.5 Environment: All Reporter: Per Steffensen Assignee: Per Steffensen Labels: RDBMS, insert, locking, nosql, optimistic, uniqueKey, update, versioning Fix For: 4.0 Attachments: SOLR-3178.patch Original Estimate: 168h Remaining Estimate: 168h In order increase the ability of Solr to be used as a NoSql database (lots of concurrent inserts, updates, deletes and queries in the entire lifetime of the index) instead of just a search index (first: everything indexed (in one thread), after: only queries), I would like Solr to support versioning to be used for optimistic locking. When my intent (see SOLR-3173) is to update an existing document, I will need to provide a version-number equal to the version number I got when I fetched the existing document for update plus one. If this provided version-number does not correspond to the newest version-number of that document at the time of update plus one, I will get a VersionConflict error. If it does correspond the document will be updated with the new one, so that the newest version-number of that document is NOW one higher than before the update. Correct but efficient concurrency handling. When my intent (see SOLR-3173) is to insert a new document, the version number provided will not be used - instead a version-number 0 will be used. According to SOLR-3173 insert will only succeed if a document with the same value on uniqueKey-field does not already exist. In general when talking about different versions of the same document, of course we need to be able to identify when a document is the same - that, per definition, is when the values of the uniqueKey-fields are equal. The functionality provided by this issue is only really meaningfull when you run with updateLog activated. This issue might be solved more or less at the same time as SOLR-3173, and only one single SVN patch might be given to cover both issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3178) Versioning - optimistic locking
[
https://issues.apache.org/jira/browse/SOLR-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257682#comment-13257682
]
Yonik Seeley commented on SOLR-3178:
bq. it is hard to push too many small partly-done features.
As committers it's the opposite - it's sometimes hard to consume patches that
do a lot of different things.
bq. It works with multi-document update request, providing fully detailed
feedback to the client about which document-updates failed (and why) and which
succeeded.
That's great! But it's also a separate feature that we've needed for a while
(and I think there has been a JIRA issue open for it for a while).
bq. Looking shortly at you patch, I belive, that if two threads in the server
JVM overlaps in a way that is unfortunate enough, then it is possible that data
will not be stored or will be overwritten without an exception being thrown to
indicate that to the client.
I'm confident in the synchronization/concurrency part - it's just reusing what
was put in place for SolrCloud to handle reordering of updates to replicas and
is very well tested (see TestRealTimeGet). But please let us know if you see a
problem with it, as that would mean a problem with SolrCloud today (even
without this patch).
Some other additions that can be handled later that I see:
- SolrJ support for easier passing of _version_ on a delete, constants for
_version_, etc
- Use of 1 as a generic exists version (i.e. update document only if it
already exists)
- If one document in a batch fails, don't automatically abort, and provide info
back about which docs succeeded and which failed (your first point).
That last one in particular needs some good discussion and design work and
really deserves it's own issue.
Down to the specifics of this patch... it's very non-invasive to core,
consisting of the following code block (once for add, once for delete):
{code}
if (versionOnUpdate != 0) {
Long lastVersion = vinfo.lookupVersion(cmd.getIndexedId());
long foundVersion = lastVersion == null ? -1 : lastVersion;
if ( versionOnUpdate == foundVersion || (versionOnUpdate 0
foundVersion 0) ) {
// we're ok if versions match, or if both are negative (all
missing docs are equal)
} else {
throw new SolrException(ErrorCode.CONFLICT, version conflict
for + cmd.getPrintableId() + expected= + versionOnUpdate + actual= +
foundVersion);
}
}
{code}
Having this current improvement committed in no way blocks any future
improvements you may come up with (including deleting the code quoted above and
using whatever method you have come up with for checking the versions), and it
even uses the same API (or a subset of it) via _version_ and 409. Progress,
not perfection!
Versioning - optimistic locking
---
Key: SOLR-3178
URL: https://issues.apache.org/jira/browse/SOLR-3178
Project: Solr
Issue Type: New Feature
Components: update
Affects Versions: 3.5
Environment: All
Reporter: Per Steffensen
Assignee: Per Steffensen
Labels: RDBMS, insert, locking, nosql, optimistic, uniqueKey,
update, versioning
Fix For: 4.0
Attachments: SOLR-3178.patch
Original Estimate: 168h
Remaining Estimate: 168h
In order increase the ability of Solr to be used as a NoSql database (lots of
concurrent inserts, updates, deletes and queries in the entire lifetime of
the index) instead of just a search index (first: everything indexed (in one
thread), after: only queries), I would like Solr to support versioning to be
used for optimistic locking.
When my intent (see SOLR-3173) is to update an existing document, I will need
to provide a version-number equal to the version number I got when I fetched
the existing document for update plus one. If this provided version-number
does not correspond to the newest version-number of that document at the
time of update plus one, I will get a VersionConflict error. If it does
correspond the document will be updated with the new one, so that the newest
version-number of that document is NOW one higher than before the update.
Correct but efficient concurrency handling.
When my intent (see SOLR-3173) is to insert a new document, the version
number provided will not be used - instead a version-number 0 will be used.
According to SOLR-3173 insert will only succeed if a document with the same
value on uniqueKey-field does not already exist.
In general when talking about different versions of the same document, of
course we need to be able to identify when a document is the same - that,
per definition, is when the values of the uniqueKey-fields are equal.
The
[jira] [Commented] (SOLR-3178) Versioning - optimistic locking
[ https://issues.apache.org/jira/browse/SOLR-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257703#comment-13257703 ] Yonik Seeley commented on SOLR-3178: Are there any technical objections to this patch? It really piggybacks on all of the SolrCloud work done to pass around and check versions, so it's really small. The API is as follows: - If you provide a _version_ 0 with an add or a delete, the update will fail with a 409 unless the provided _version_ matches exactly the latest in the index for the ID. - If you provide a _version_ 0 with an add or delete, the update will fail with a 409 if the ID exists in the index. That's the whole scope of this patch, and I believe is compatible with the larger scope of what Per will provide in the future. Versioning - optimistic locking --- Key: SOLR-3178 URL: https://issues.apache.org/jira/browse/SOLR-3178 Project: Solr Issue Type: New Feature Components: update Affects Versions: 3.5 Environment: All Reporter: Per Steffensen Assignee: Per Steffensen Labels: RDBMS, insert, locking, nosql, optimistic, uniqueKey, update, versioning Fix For: 4.0 Attachments: SOLR-3178.patch Original Estimate: 168h Remaining Estimate: 168h In order increase the ability of Solr to be used as a NoSql database (lots of concurrent inserts, updates, deletes and queries in the entire lifetime of the index) instead of just a search index (first: everything indexed (in one thread), after: only queries), I would like Solr to support versioning to be used for optimistic locking. When my intent (see SOLR-3173) is to update an existing document, I will need to provide a version-number equal to the version number I got when I fetched the existing document for update plus one. If this provided version-number does not correspond to the newest version-number of that document at the time of update plus one, I will get a VersionConflict error. If it does correspond the document will be updated with the new one, so that the newest version-number of that document is NOW one higher than before the update. Correct but efficient concurrency handling. When my intent (see SOLR-3173) is to insert a new document, the version number provided will not be used - instead a version-number 0 will be used. According to SOLR-3173 insert will only succeed if a document with the same value on uniqueKey-field does not already exist. In general when talking about different versions of the same document, of course we need to be able to identify when a document is the same - that, per definition, is when the values of the uniqueKey-fields are equal. The functionality provided by this issue is only really meaningfull when you run with updateLog activated. This issue might be solved more or less at the same time as SOLR-3173, and only one single SVN patch might be given to cover both issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3362) FacetComponent throws NPE when doing distributed query
[ https://issues.apache.org/jira/browse/SOLR-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256505#comment-13256505 ] Yonik Seeley commented on SOLR-3362: I assume you're not using the jetty bundled with Solr? If not, let's check that first by running exampledocs/test_utf8.sh FacetComponent throws NPE when doing distributed query -- Key: SOLR-3362 URL: https://issues.apache.org/jira/browse/SOLR-3362 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0 Environment: RHEL lucene svn revision 1308309 Reporter: Jamie Johnson When executing a query against a field in my index I am getting the following exception The query I am executing is as follows: http://host:port/solr/collection1/select?q=bobfacet=truefacet.field=organization debugging the FacetComponent line 489 sfc is null SEVERE: java.lang.NullPointerException at org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:489) at org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:278) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:307) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1550) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:442) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:263) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) at org.eclipse.jetty.server.Server.handle(Server.java:351) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3362) FacetComponent throws NPE when doing distributed query
[
https://issues.apache.org/jira/browse/SOLR-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256565#comment-13256565
]
Yonik Seeley commented on SOLR-3362:
OK, then the next most likely possibility would seem to be the client sending
the sub-request.
I just managed to reproduce this problem with this URL:
http://localhost:8983/solr/select?wt=pythonindent=trueq=*:*facet=truefacet.query={!term%20f=id}wx%C2%A0yzshards=localhost:8983/solr
FacetComponent throws NPE when doing distributed query
--
Key: SOLR-3362
URL: https://issues.apache.org/jira/browse/SOLR-3362
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.0
Environment: RHEL
lucene svn revision 1308309
Reporter: Jamie Johnson
When executing a query against a field in my index I am getting the following
exception
The query I am executing is as follows:
http://host:port/solr/collection1/select?q=bobfacet=truefacet.field=organization
debugging the FacetComponent line 489 sfc is null
SEVERE: java.lang.NullPointerException
at
org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:489)
at
org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:278)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:307)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1550)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:442)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:263)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111)
at org.eclipse.jetty.server.Server.handle(Server.java:351)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634)
at
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230)
at
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66)
at
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534)
at java.lang.Thread.run(Thread.java:662)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3362) FacetComponent throws NPE when doing distributed query
[
https://issues.apache.org/jira/browse/SOLR-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256570#comment-13256570
]
Yonik Seeley commented on SOLR-3362:
Oh yuck... I just used netcat to listen on port 8985 and changed the shards
parameter to that to see just what was being sent.
What a waste of space! And that is where the charset is getting hacked...
{code}
/opt/code/lusolr/solr/example/exampledocs$ nc -l 8985
POST /solr/select HTTP/1.1
User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
Content-Charset: UTF-8
Accept-Charset: UTF-8
Content-Length: 1217
Content-Type: multipart/form-data; boundary=eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Host: localhost:8985
Connection: Keep-Alive
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=rows
10
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=facet
true
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=facet.query
{!term f=id}wx?yz
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=q
*:*
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=start
0
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=fsv
true
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=fl
id,score
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=distrib
false
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=isShard
true
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=shard.url
localhost:8985/solr
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=NOW
1334757315277
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=wt
javabin
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=version
2
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3--
{code}
FacetComponent throws NPE when doing distributed query
--
Key: SOLR-3362
URL: https://issues.apache.org/jira/browse/SOLR-3362
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.0
Environment: RHEL
lucene svn revision 1308309
Reporter: Jamie Johnson
When executing a query against a field in my index I am getting the following
exception
The query I am executing is as follows:
http://host:port/solr/collection1/select?q=bobfacet=truefacet.field=organization
debugging the FacetComponent line 489 sfc is null
SEVERE: java.lang.NullPointerException
at
org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:489)
at
org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:278)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:307)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1550)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:442)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:263)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111)
at org.eclipse.jetty.server.Server.handle(Server.java:351)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890)
at
[jira] [Commented] (SOLR-3362) FacetComponent throws NPE when doing distributed query
[
https://issues.apache.org/jira/browse/SOLR-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256571#comment-13256571
]
Yonik Seeley commented on SOLR-3362:
Oh yuck... I just used netcat to listen on port 8985 and changed the shards
parameter to that to see just what was being sent.
What a waste of space! And that is where the charset is getting hacked...
{code}
/opt/code/lusolr/solr/example/exampledocs$ nc -l 8985
POST /solr/select HTTP/1.1
User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
Content-Charset: UTF-8
Accept-Charset: UTF-8
Content-Length: 1217
Content-Type: multipart/form-data; boundary=eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Host: localhost:8985
Connection: Keep-Alive
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=rows
10
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=facet
true
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=facet.query
{!term f=id}wx?yz
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=q
*:*
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=start
0
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=fsv
true
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=fl
id,score
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=distrib
false
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=isShard
true
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=shard.url
localhost:8985/solr
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=NOW
1334757315277
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=wt
javabin
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=version
2
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3--
{code}
FacetComponent throws NPE when doing distributed query
--
Key: SOLR-3362
URL: https://issues.apache.org/jira/browse/SOLR-3362
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.0
Environment: RHEL
lucene svn revision 1308309
Reporter: Jamie Johnson
When executing a query against a field in my index I am getting the following
exception
The query I am executing is as follows:
http://host:port/solr/collection1/select?q=bobfacet=truefacet.field=organization
debugging the FacetComponent line 489 sfc is null
SEVERE: java.lang.NullPointerException
at
org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:489)
at
org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:278)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:307)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1550)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:442)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:263)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111)
at org.eclipse.jetty.server.Server.handle(Server.java:351)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890)
at
[jira] [Commented] (SOLR-3362) FacetComponent throws NPE when doing distributed query
[ https://issues.apache.org/jira/browse/SOLR-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256592#comment-13256592 ] Yonik Seeley commented on SOLR-3362: OK, I just verified that this is not a problem with older trunk builds, so this was an issue introduced by the new http client 4 (upgraded on 3/29). Before that, we get a normal looking single-part post with correct encoding. FacetComponent throws NPE when doing distributed query -- Key: SOLR-3362 URL: https://issues.apache.org/jira/browse/SOLR-3362 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0 Environment: RHEL lucene svn revision 1308309 Reporter: Jamie Johnson When executing a query against a field in my index I am getting the following exception The query I am executing is as follows: http://host:port/solr/collection1/select?q=bobfacet=truefacet.field=organization debugging the FacetComponent line 489 sfc is null SEVERE: java.lang.NullPointerException at org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:489) at org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:278) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:307) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1550) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:442) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:263) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) at org.eclipse.jetty.server.Server.handle(Server.java:351) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module
[ https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256765#comment-13256765 ] Yonik Seeley commented on LUCENE-3997: -- I think that if you try to make no modules depend on other modules, you'll end up just pulling pretty much everything into core. Also, the function query stuff is supposed to be marked as experimental - the notice only got added to FunctionQuery (I think?), so it should be applied to FunctionValues and ValueSource if they are moved to core. join module should not depend on grouping module Key: LUCENE-3997 URL: https://issues.apache.org/jira/browse/LUCENE-3997 Project: Lucene - Java Issue Type: Task Affects Versions: 4.0 Reporter: Robert Muir Fix For: 4.0 Attachments: LUCENE-3997.patch, LUCENE-3997.patch I think TopGroups/GroupDocs should simply be in core? Both grouping and join modules use these trivial classes, but join depends on grouping just for them. I think its better that we try to minimize these inter-module dependencies. Of course, another option is to combine grouping and join into one module, but last time i brought that up nobody could agree on a name. Anyway I think the change is pretty clean: its similar to having basic stuff like Analyzer.java in core, so other things can work with Analyzer without depending on any specific implementing modules. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256867#comment-13256867 ] Yonik Seeley commented on SOLR-3358: Trying to support different servlet containers, different logging frameworks, etc, is a mess... IMO, we should be considering Solr more as a server (and the fact that it uses Jetty and Java logging an implementation detail). I don't think making everything pluggable buys us much but a lot of headaches. Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3178) Versioning - optimistic locking
[ https://issues.apache.org/jira/browse/SOLR-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257004#comment-13257004 ] Yonik Seeley commented on SOLR-3178: FYI, I've got a patch that seems to work fine... I'm just still finishing up some of the tests. Versioning - optimistic locking --- Key: SOLR-3178 URL: https://issues.apache.org/jira/browse/SOLR-3178 Project: Solr Issue Type: New Feature Components: update Affects Versions: 3.5 Environment: All Reporter: Per Steffensen Assignee: Per Steffensen Labels: RDBMS, insert, locking, nosql, optimistic, uniqueKey, update, versioning Fix For: 4.0 Original Estimate: 168h Remaining Estimate: 168h In order increase the ability of Solr to be used as a NoSql database (lots of concurrent inserts, updates, deletes and queries in the entire lifetime of the index) instead of just a search index (first: everything indexed (in one thread), after: only queries), I would like Solr to support versioning to be used for optimistic locking. When my intent (see SOLR-3173) is to update an existing document, I will need to provide a version-number equal to the version number I got when I fetched the existing document for update plus one. If this provided version-number does not correspond to the newest version-number of that document at the time of update plus one, I will get a VersionConflict error. If it does correspond the document will be updated with the new one, so that the newest version-number of that document is NOW one higher than before the update. Correct but efficient concurrency handling. When my intent (see SOLR-3173) is to insert a new document, the version number provided will not be used - instead a version-number 0 will be used. According to SOLR-3173 insert will only succeed if a document with the same value on uniqueKey-field does not already exist. In general when talking about different versions of the same document, of course we need to be able to identify when a document is the same - that, per definition, is when the values of the uniqueKey-fields are equal. The functionality provided by this issue is only really meaningfull when you run with updateLog activated. This issue might be solved more or less at the same time as SOLR-3173, and only one single SVN patch might be given to cover both issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2020) HttpComponentsSolrServer
[ https://issues.apache.org/jira/browse/SOLR-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257091#comment-13257091 ] Yonik Seeley commented on SOLR-2020: Thanks Sami, your last commit today seems to have fixed the issue. I also just added a simple test to TestDistributedSearch and also manually verified that the resulting POST is not multi-part. HttpComponentsSolrServer Key: SOLR-2020 URL: https://issues.apache.org/jira/browse/SOLR-2020 Project: Solr Issue Type: New Feature Components: clients - java Affects Versions: 1.4.1 Environment: Any Reporter: Chantal Ackermann Assignee: Sami Siren Priority: Minor Fix For: 3.6, 4.0 Attachments: HttpComponentsSolrServer.java, HttpComponentsSolrServerTest.java, SOLR-2020-3x.patch, SOLR-2020-HttpSolrServer.patch, SOLR-2020.patch, SOLR-2020.patch, SOLR-2020.patch, SOLR-2020.patch Implementation of SolrServer that uses the Apache Http Components framework. Http Components (http://hc.apache.org/) is the successor of Commons HttpClient and thus HttpComponentsSolrServer would be a successor of CommonsHttpSolrServer, in the future. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3362) FacetComponent throws NPE when doing distributed query
[ https://issues.apache.org/jira/browse/SOLR-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13255639#comment-13255639 ] Yonik Seeley commented on SOLR-3362: So it seems like we're getting back a term we didn't ask for. One way this could happen is if the encoding is messed up - StrUtils.join and splitSmart are used for this, and I don't see an obvious error there. At this point perhaps we should add a check at line 489 and log terms that come back that we don't ask for. FacetComponent throws NPE when doing distributed query -- Key: SOLR-3362 URL: https://issues.apache.org/jira/browse/SOLR-3362 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0 Environment: RHEL lucene svn revision 1308309 Reporter: Jamie Johnson When executing a query against a field in my index I am getting the following exception The query I am executing is as follows: http://host:port/solr/collection1/select?q=bobfacet=truefacet.field=organization debugging the FacetComponent line 489 sfc is null SEVERE: java.lang.NullPointerException at org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:489) at org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:278) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:307) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1550) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:442) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:263) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) at org.eclipse.jetty.server.Server.handle(Server.java:351) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3362) FacetComponent throws NPE when doing distributed query
[ https://issues.apache.org/jira/browse/SOLR-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13255746#comment-13255746 ] Yonik Seeley commented on SOLR-3362: Right. I just checked something in for FacetComponent to log the term and other info. FacetComponent throws NPE when doing distributed query -- Key: SOLR-3362 URL: https://issues.apache.org/jira/browse/SOLR-3362 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0 Environment: RHEL lucene svn revision 1308309 Reporter: Jamie Johnson When executing a query against a field in my index I am getting the following exception The query I am executing is as follows: http://host:port/solr/collection1/select?q=bobfacet=truefacet.field=organization debugging the FacetComponent line 489 sfc is null SEVERE: java.lang.NullPointerException at org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:489) at org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:278) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:307) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1550) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:442) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:263) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) at org.eclipse.jetty.server.Server.handle(Server.java:351) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3362) FacetComponent throws NPE when doing distributed query
[ https://issues.apache.org/jira/browse/SOLR-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13255915#comment-13255915 ] Yonik Seeley commented on SOLR-3362: bq. This certainly made the error I was having go away, should I be worried about a lower level issue that this change masks? Yes, I'd be worried. Do you see any Unexpected term returned errors in the logs? FacetComponent throws NPE when doing distributed query -- Key: SOLR-3362 URL: https://issues.apache.org/jira/browse/SOLR-3362 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0 Environment: RHEL lucene svn revision 1308309 Reporter: Jamie Johnson When executing a query against a field in my index I am getting the following exception The query I am executing is as follows: http://host:port/solr/collection1/select?q=bobfacet=truefacet.field=organization debugging the FacetComponent line 489 sfc is null SEVERE: java.lang.NullPointerException at org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:489) at org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:278) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:307) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1550) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:442) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:263) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) at org.eclipse.jetty.server.Server.handle(Server.java:351) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3178) Versioning - optimistic locking
[ https://issues.apache.org/jira/browse/SOLR-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13254186#comment-13254186 ] Yonik Seeley commented on SOLR-3178: One API issue is how to give error codes... looking at the HTTP list (http://en.wikipedia.org/wiki/List_of_HTTP_status_codes) there seem to be 2 that fit the bill: 409 Conflict Indicates that the request could not be processed because of conflict in the request, such as an edit conflict.[2] 412 Precondition Failed The server does not meet one of the preconditions that the requester put on the request.[2] Looks like 409 is closer though. Versioning - optimistic locking --- Key: SOLR-3178 URL: https://issues.apache.org/jira/browse/SOLR-3178 Project: Solr Issue Type: New Feature Components: update Affects Versions: 3.5 Environment: All Reporter: Per Steffensen Assignee: Per Steffensen Labels: RDBMS, insert, locking, nosql, optimistic, uniqueKey, update, versioning Fix For: 4.0 Original Estimate: 168h Remaining Estimate: 168h In order increase the ability of Solr to be used as a NoSql database (lots of concurrent inserts, updates, deletes and queries in the entire lifetime of the index) instead of just a search index (first: everything indexed (in one thread), after: only queries), I would like Solr to support versioning to be used for optimistic locking. When my intent (see SOLR-3173) is to update an existing document, I will need to provide a version-number equal to the version number I got when I fetched the existing document for update plus one. If this provided version-number does not correspond to the newest version-number of that document at the time of update plus one, I will get a VersionConflict error. If it does correspond the document will be updated with the new one, so that the newest version-number of that document is NOW one higher than before the update. Correct but efficient concurrency handling. When my intent (see SOLR-3173) is to insert a new document, the version number provided will not be used - instead a version-number 0 will be used. According to SOLR-3173 insert will only succeed if a document with the same value on uniqueKey-field does not already exist. In general when talking about different versions of the same document, of course we need to be able to identify when a document is the same - that, per definition, is when the values of the uniqueKey-fields are equal. The functionality provided by this issue is only really meaningfull when you run with updateLog activated. This issue might be solved more or less at the same time as SOLR-3173, and only one single SVN patch might be given to cover both issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3972) Improve AllGroupsCollector implementations
[ https://issues.apache.org/jira/browse/LUCENE-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13252469#comment-13252469 ] Yonik Seeley commented on LUCENE-3972: -- bq. I would also patch it for the future in either case. Hmmm, if you don't know anything about the integer keys, then a little extra hashing by default is a good idea. But we know a lot about docids, and extra hashing should just lead to an average-case slowdown. Improve AllGroupsCollector implementations -- Key: LUCENE-3972 URL: https://issues.apache.org/jira/browse/LUCENE-3972 Project: Lucene - Java Issue Type: Improvement Components: modules/grouping Reporter: Martijn van Groningen Attachments: LUCENE-3972.patch, LUCENE-3972.patch I think that the performance of TermAllGroupsCollectorm, DVAllGroupsCollector.BR and DVAllGroupsCollector.SortedBR can be improved by using BytesRefHash to store the groups instead of an ArrayList. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3351) eDismax: ps2 and ps3 params
[ https://issues.apache.org/jira/browse/SOLR-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251977#comment-13251977 ] Yonik Seeley commented on SOLR-3351: There was a proposal (and an issue) to fold the slop into the phrase field specification: pf=text~3 would create phrase queries with a slop of 3 This allows different slops for different fields, keeps the number of parameters down, and is more understandable. eDismax: ps2 and ps3 params --- Key: SOLR-3351 URL: https://issues.apache.org/jira/browse/SOLR-3351 Project: Solr Issue Type: Improvement Components: query parsers Reporter: Jan Høydahl Fix For: 4.0 Add support for custom Phrase Slop for pf2 and pf3 of edismax. If not specified, it should use ps as today. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3346) qt Dispatching Request Handler
[ https://issues.apache.org/jira/browse/SOLR-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250742#comment-13250742 ] Yonik Seeley commented on SOLR-3346: I think I would prefer leaving things as they are (as you say, it's just a small piece of code in the SolrDispatchFilter... and qt is all about dispatching!) It would seem to introduce extra overhead for anyone that wanted to use qt as they did before, and there's a good probability that it would introduce more bugs as well. qt Dispatching Request Handler -- Key: SOLR-3346 URL: https://issues.apache.org/jira/browse/SOLR-3346 Project: Solr Issue Type: New Feature Components: search Reporter: David Smiley Fix For: 4.0 Instead of 'qt' being handled by the SolrDispatchFilter (a Servlet Filter), it would be better implemented as a request handler, with a suggested name of DispatchingRequestHandler. This is better because: * it keeps the servlet filter more focused / simplified (albeit just a little) * it simplifies solrconfig.xml by removing/deprecating handleSelect=true. 'qt' is less magic, it works more explicitly. * if you don't want to use 'qt' dispatch, simply don't use DispatchingRequestHandler * DispatchingRequestHandler would get used by EmbeddedSolrServer but SolrDispatchFilter is not. Credit: Hoss's idea, Erik coded a first draft -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3335) testDistribSearch failure
[
https://issues.apache.org/jira/browse/SOLR-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250125#comment-13250125
]
Yonik Seeley commented on SOLR-3335:
I've been looping the full ant test for a while... it failed after about 4
hours (30 runs) the first time and the second time hasn't failed yet (over 8
hours).
testDistribSearch failure
-
Key: SOLR-3335
URL: https://issues.apache.org/jira/browse/SOLR-3335
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 4.0
Happened on my test machine. Is there a way to disable these tests if we
cannot fix them? There are two three tests that fail most of the time and
that apparently nobody knows how to fix (including me).
There is also a typo in the error message (I'm away from home for Easter,
can't do it now).
{noformat}
build 06-Apr-2012 16:11:54[junit] Testsuite:
org.apache.solr.cloud.RecoveryZkTest
build 06-Apr-2012 16:11:54[junit] Testcase:
testDistribSearch(org.apache.solr.cloud.RecoveryZkTest): FAILED
build 06-Apr-2012 16:11:54[junit] There are still nodes recoverying
build 06-Apr-2012 16:11:54[junit]
junit.framework.AssertionFailedError: There are still nodes recoverying
build 06-Apr-2012 16:11:54[junit] at
org.junit.Assert.fail(Assert.java:93)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.cloud.AbstractDistributedZkTestCase.waitForRecoveriesToFinish(AbstractDistributedZkTestCase.java:132)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.cloud.RecoveryZkTest.doTest(RecoveryZkTest.java:84)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:670)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
build 06-Apr-2012 16:11:54[junit] at
java.lang.reflect.Method.invoke(Method.java:597)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:754)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:670)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642)
build 06-Apr-2012 16:11:54[junit] at
org.junit.rules.RunRules.evaluate(RunRules.java:18)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
build
[jira] [Commented] (SOLR-3335) testDistribSearch failure
[
https://issues.apache.org/jira/browse/SOLR-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250157#comment-13250157
]
Yonik Seeley commented on SOLR-3335:
Something weird is going on with the nightly builds (which mostly fail) vs the
normal tests (which mostly pass) on jenkins.
Anyway, it seems like we should keep these tests enabled since they do mostly
pass with the normal tests and provide critical coverage.
testDistribSearch failure
-
Key: SOLR-3335
URL: https://issues.apache.org/jira/browse/SOLR-3335
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 4.0
Happened on my test machine. Is there a way to disable these tests if we
cannot fix them? There are two three tests that fail most of the time and
that apparently nobody knows how to fix (including me).
There is also a typo in the error message (I'm away from home for Easter,
can't do it now).
{noformat}
build 06-Apr-2012 16:11:54[junit] Testsuite:
org.apache.solr.cloud.RecoveryZkTest
build 06-Apr-2012 16:11:54[junit] Testcase:
testDistribSearch(org.apache.solr.cloud.RecoveryZkTest): FAILED
build 06-Apr-2012 16:11:54[junit] There are still nodes recoverying
build 06-Apr-2012 16:11:54[junit]
junit.framework.AssertionFailedError: There are still nodes recoverying
build 06-Apr-2012 16:11:54[junit] at
org.junit.Assert.fail(Assert.java:93)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.cloud.AbstractDistributedZkTestCase.waitForRecoveriesToFinish(AbstractDistributedZkTestCase.java:132)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.cloud.RecoveryZkTest.doTest(RecoveryZkTest.java:84)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:670)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
build 06-Apr-2012 16:11:54[junit] at
java.lang.reflect.Method.invoke(Method.java:597)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:754)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:670)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642)
build 06-Apr-2012 16:11:54[junit] at
org.junit.rules.RunRules.evaluate(RunRules.java:18)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
build 06-Apr-2012 16:11:54[junit] at
[jira] [Commented] (SOLR-3335) testDistribSearch failure
[
https://issues.apache.org/jira/browse/SOLR-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250205#comment-13250205
]
Yonik Seeley commented on SOLR-3335:
bq. if stress is non-zero (which it is if it's nightly)
Gack - I don't know when that happened... seems like we should have some degree
of stress (i.e. query from multiple threads) in the tests that run after any
changes!
bq. Is this just a typo? are the refs to clients in queryPartialResults all
just suppose to be upClients ?
*shrug*... I never reviewed the partial results stuff, but I guess the changes
to this test are from this commit?
{code}
r1294995 | ryan | 2012-02-29 02:32:02 -0500 (Wed, 29 Feb 2012) | 1 line
SOLR-3134: Adding test and fix from Russell Black
{code}
Thanks for looking into that Hoss!
testDistribSearch failure
-
Key: SOLR-3335
URL: https://issues.apache.org/jira/browse/SOLR-3335
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 4.0
Happened on my test machine. Is there a way to disable these tests if we
cannot fix them? There are two three tests that fail most of the time and
that apparently nobody knows how to fix (including me).
There is also a typo in the error message (I'm away from home for Easter,
can't do it now).
{noformat}
build 06-Apr-2012 16:11:54[junit] Testsuite:
org.apache.solr.cloud.RecoveryZkTest
build 06-Apr-2012 16:11:54[junit] Testcase:
testDistribSearch(org.apache.solr.cloud.RecoveryZkTest): FAILED
build 06-Apr-2012 16:11:54[junit] There are still nodes recoverying
build 06-Apr-2012 16:11:54[junit]
junit.framework.AssertionFailedError: There are still nodes recoverying
build 06-Apr-2012 16:11:54[junit] at
org.junit.Assert.fail(Assert.java:93)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.cloud.AbstractDistributedZkTestCase.waitForRecoveriesToFinish(AbstractDistributedZkTestCase.java:132)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.cloud.RecoveryZkTest.doTest(RecoveryZkTest.java:84)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:670)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
build 06-Apr-2012 16:11:54[junit] at
java.lang.reflect.Method.invoke(Method.java:597)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:754)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:670)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642)
build 06-Apr-2012 16:11:54[junit] at
org.junit.rules.RunRules.evaluate(RunRules.java:18)
build 06-Apr-2012 16:11:54[junit] at
[jira] [Commented] (SOLR-3335) testDistribSearch failure
[
https://issues.apache.org/jira/browse/SOLR-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249263#comment-13249263
]
Yonik Seeley commented on SOLR-3335:
I looped this test (RecoveryZkTest) over night on my linux box and it didn't
fail until this morning (after ~900 iterations).
Dawid, what does your test machine look like?
testDistribSearch failure
-
Key: SOLR-3335
URL: https://issues.apache.org/jira/browse/SOLR-3335
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 4.0
Happened on my test machine. Is there a way to disable these tests if we
cannot fix them? There are two three tests that fail most of the time and
that apparently nobody knows how to fix (including me).
There is also a typo in the error message (I'm away from home for Easter,
can't do it now).
{noformat}
build 06-Apr-2012 16:11:54[junit] Testsuite:
org.apache.solr.cloud.RecoveryZkTest
build 06-Apr-2012 16:11:54[junit] Testcase:
testDistribSearch(org.apache.solr.cloud.RecoveryZkTest): FAILED
build 06-Apr-2012 16:11:54[junit] There are still nodes recoverying
build 06-Apr-2012 16:11:54[junit]
junit.framework.AssertionFailedError: There are still nodes recoverying
build 06-Apr-2012 16:11:54[junit] at
org.junit.Assert.fail(Assert.java:93)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.cloud.AbstractDistributedZkTestCase.waitForRecoveriesToFinish(AbstractDistributedZkTestCase.java:132)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.cloud.RecoveryZkTest.doTest(RecoveryZkTest.java:84)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:670)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
build 06-Apr-2012 16:11:54[junit] at
java.lang.reflect.Method.invoke(Method.java:597)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:754)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:670)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642)
build 06-Apr-2012 16:11:54[junit] at
org.junit.rules.RunRules.evaluate(RunRules.java:18)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
build
[jira] [Commented] (SOLR-3335) testDistribSearch failure
[
https://issues.apache.org/jira/browse/SOLR-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249287#comment-13249287
]
Yonik Seeley commented on SOLR-3335:
OK, I'm still on my old ubuntu quad core opteron.
FWIW I started looping TestDistributedSearch (which has started failing
consistently on jenkins) a few hours ago with tests.multiplier=3. Just 3 hours
in (with each run taking ~1min) and no failures yet...
testDistribSearch failure
-
Key: SOLR-3335
URL: https://issues.apache.org/jira/browse/SOLR-3335
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 4.0
Happened on my test machine. Is there a way to disable these tests if we
cannot fix them? There are two three tests that fail most of the time and
that apparently nobody knows how to fix (including me).
There is also a typo in the error message (I'm away from home for Easter,
can't do it now).
{noformat}
build 06-Apr-2012 16:11:54[junit] Testsuite:
org.apache.solr.cloud.RecoveryZkTest
build 06-Apr-2012 16:11:54[junit] Testcase:
testDistribSearch(org.apache.solr.cloud.RecoveryZkTest): FAILED
build 06-Apr-2012 16:11:54[junit] There are still nodes recoverying
build 06-Apr-2012 16:11:54[junit]
junit.framework.AssertionFailedError: There are still nodes recoverying
build 06-Apr-2012 16:11:54[junit] at
org.junit.Assert.fail(Assert.java:93)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.cloud.AbstractDistributedZkTestCase.waitForRecoveriesToFinish(AbstractDistributedZkTestCase.java:132)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.cloud.RecoveryZkTest.doTest(RecoveryZkTest.java:84)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:670)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
build 06-Apr-2012 16:11:54[junit] at
java.lang.reflect.Method.invoke(Method.java:597)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:754)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:670)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642)
build 06-Apr-2012 16:11:54[junit] at
org.junit.rules.RunRules.evaluate(RunRules.java:18)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
build 06-Apr-2012 16:11:54[junit] at
[jira] [Commented] (SOLR-3335) testDistribSearch failure
[
https://issues.apache.org/jira/browse/SOLR-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249394#comment-13249394
]
Yonik Seeley commented on SOLR-3335:
bq. FWIW I started looping TestDistributedSearch (which has started failing
consistently on jenkins) a few hours ago with tests.multiplier=3. Just 3 hours
in (with each run taking ~1min) and no failures yet...
Update: I just got a failure after 642 runs. A response mismatch here:
{code}
// random value sort
for (String f : fieldNames) {
query(q,*:*, sort,f+ desc);
{code}
The actual number of documents failed to match... and no other exceptions in
the test, so I'm not sure how that can happen. Anyway, it doesn't appear to be
related to the super high failure rate on our freebsd-jenkins, which I am
unable to reproduce so far.
testDistribSearch failure
-
Key: SOLR-3335
URL: https://issues.apache.org/jira/browse/SOLR-3335
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 4.0
Happened on my test machine. Is there a way to disable these tests if we
cannot fix them? There are two three tests that fail most of the time and
that apparently nobody knows how to fix (including me).
There is also a typo in the error message (I'm away from home for Easter,
can't do it now).
{noformat}
build 06-Apr-2012 16:11:54[junit] Testsuite:
org.apache.solr.cloud.RecoveryZkTest
build 06-Apr-2012 16:11:54[junit] Testcase:
testDistribSearch(org.apache.solr.cloud.RecoveryZkTest): FAILED
build 06-Apr-2012 16:11:54[junit] There are still nodes recoverying
build 06-Apr-2012 16:11:54[junit]
junit.framework.AssertionFailedError: There are still nodes recoverying
build 06-Apr-2012 16:11:54[junit] at
org.junit.Assert.fail(Assert.java:93)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.cloud.AbstractDistributedZkTestCase.waitForRecoveriesToFinish(AbstractDistributedZkTestCase.java:132)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.cloud.RecoveryZkTest.doTest(RecoveryZkTest.java:84)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:670)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
build 06-Apr-2012 16:11:54[junit] at
java.lang.reflect.Method.invoke(Method.java:597)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:754)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:670)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642)
build 06-Apr-2012 16:11:54[junit] at
org.junit.rules.RunRules.evaluate(RunRules.java:18)
build 06-Apr-2012 16:11:54[junit]
[jira] [Commented] (SOLR-3329) Use consistent svn:keywords
[
https://issues.apache.org/jira/browse/SOLR-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13247956#comment-13247956
]
Yonik Seeley commented on SOLR-3329:
Honestly, I don't think I've ever found that extra info useful...
Use consistent svn:keywords
---
Key: SOLR-3329
URL: https://issues.apache.org/jira/browse/SOLR-3329
Project: Solr
Issue Type: Improvement
Reporter: Ryan McKinley
Fix For: 4.0
In solr, use use svn:keywords haphazardly
We have lots of places with:
{code}
svn propset svn:keywords Date Author Id Revision HeadURL *.java
{code}
In LUCENE-3923, there is a suggestion to get rid of many of these.
The MBeans interface often exposes HeadURL, but we likely want to get rid of
the rest
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3313) Rename Query Type to Request Handler in API and UI
[ https://issues.apache.org/jira/browse/SOLR-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245846#comment-13245846 ] Yonik Seeley commented on SOLR-3313: Yeah, that makes sense. Rename Query Type to Request Handler in API and UI --- Key: SOLR-3313 URL: https://issues.apache.org/jira/browse/SOLR-3313 Project: Solr Issue Type: Improvement Reporter: David Smiley Fix For: 4.0 Nobody should speak of query types any more; it's request handlers. I understand we want to retain the qt parameter as such but I think we should change the names of it wherever we can find it. We can leave some older API methods in place as deprecated. As an example, in SolrJ I have to call solrQuery.setQueryType(/blah) instead of setRequestHandler() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3303) defType param completely ignored
[
https://issues.apache.org/jira/browse/SOLR-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244182#comment-13244182
]
Yonik Seeley commented on SOLR-3303:
http://wiki.apache.org/solr/SolrQuerySyntax
In standard Solr search handlers, the defType param can be used to specify the
default type of the main query (ie: the q param) but it only affects the main
query -- The default type of all other query parameters will remain lucene.
You explicitly specified the query type as boost via your use of q={!boost...}
defType param completely ignored
Key: SOLR-3303
URL: https://issues.apache.org/jira/browse/SOLR-3303
Project: Solr
Issue Type: Bug
Affects Versions: 3.5
Reporter: Bráulio Bhavamitra
Priority: Critical
I've reproduced this bug using the geodist ordering.
'defType' is being completely ignored, and it don't change nothing with 'qt'
added or not.
I'm supposing that in later case defType must be informed, cause edismax (or
dismax) is not default.
The correct behaviour is expected when not using qt (defaulting to the
default handler with no default defType value specified in solrconfig.xml)
and using defType would make the query work.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3218) Range faceting support for CurrencyField
[ https://issues.apache.org/jira/browse/SOLR-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244188#comment-13244188 ] Yonik Seeley commented on SOLR-3218: bq. The alternative to using Strings is to move CurrencyValue to solrj package, what do you think? Strings are good since it doesn't seem like we should push dependencies like this into solrj. Range faceting support for CurrencyField Key: SOLR-3218 URL: https://issues.apache.org/jira/browse/SOLR-3218 Project: Solr Issue Type: Improvement Components: Schema and Analysis Reporter: Jan Høydahl Fix For: 4.0 Attachments: SOLR-3218-1.patch, SOLR-3218-2.patch, SOLR-3218.patch, SOLR-3218.patch, SOLR-3218.patch Spinoff from SOLR-2202. Need to add range faceting capabilities for CurrencyField -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3296) Explore alternatives to Commons CSV
[ https://issues.apache.org/jira/browse/SOLR-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244532#comment-13244532 ] Yonik Seeley commented on SOLR-3296: bq. Wait: a lot of effort doing what? http://commons.apache.org/csv/team-list.html I became a CSV committer to address all of the issues. Explore alternatives to Commons CSV --- Key: SOLR-3296 URL: https://issues.apache.org/jira/browse/SOLR-3296 Project: Solr Issue Type: Improvement Components: Build Reporter: Chris Male In LUCENE-3930 we're implementing some less than ideal solutions to make available the unreleased version of commons-csv. We could remove these solutions if we didn't rely on this lib. So I think we should explore alternatives. I think [opencsv|http://opencsv.sourceforge.net/] is an alternative to consider, I've used it in many commercial projects. Bizarrely Commons-CSV's website says that Opencsv uses a BSD license, but this isn't the case, OpenCSV uses ASL2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3774) check-legal isn't doing its job
[
https://issues.apache.org/jira/browse/LUCENE-3774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13243153#comment-13243153
]
Yonik Seeley commented on LUCENE-3774:
--
bq. I have a different view on this. Things like this (license checking) are
typically integration tests. Having them per-module only complicates build
files and is an unnecessary overhead for running normal tests (because
dependencies change rarely).
+1
Having been bit by the changes in this issue dozens of times already, we
shouldn't be doing these checks on a normal ant test. Seems like it should
be fine to let Jenkins test it.
* SolrCloud demo instructions that have you make a copy of example it example2,
etc.
* mv build build.old so I could compare two runs
* try out a new jar locally w/o dotting all the i's
I've seen users report these errors on the mailing list too, and it's not
apparent to them what the issue is.
check-legal isn't doing its job
---
Key: LUCENE-3774
URL: https://issues.apache.org/jira/browse/LUCENE-3774
Project: Lucene - Java
Issue Type: Improvement
Components: general/build
Affects Versions: 3.6, 4.0
Reporter: Steven Rowe
Assignee: Dawid Weiss
Fix For: 3.6, 4.0
Attachments: LUCENE-3774.patch, LUCENE-3774.patch, LUCENE-3774.patch,
LUCENE-3774.patch, LUCENE-3774.patch, LUCENE-3774.patch, LUCENE3774.patch,
backport.patch
In trunk, the {{check-legal-lucene}} ant target is not checking any
{{lucene/contrib/\*\*/lib/}} directories; the {{modules/**/lib/}} directories
are not being checked; and {{check-legal-solr}} can't be checking
{{solr/example/lib/\*\*/\*.jar}}, because there are currently {{.jar}} files
in there that don't have a license.
These targets are set up to take in a full list of {{lib/}} directories in
which to check, but modules move around, and these lists are not being kept
up-to-date.
Instead, {{check-legal-\*}} should run for each module, if the module has a
{{lib/}} directory, and it should be specialized for modules that have more
than one ({{solr/core/}}) or that have a {{lib/}} directory in a non-standard
place ({{lucene/core/}}).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3296) Explore alternatives to Commons CSV
[ https://issues.apache.org/jira/browse/SOLR-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13242661#comment-13242661 ] Yonik Seeley commented on SOLR-3296: First steps: https://github.com/yonik/noggit https://github.com/yonik/noggit/downloads wrt commons-csv alternatives, it's too risky for little/no gain. I put a lot of effort into getting commons-csv up to snuff, and almost all of the tests for that reside in commons-csv itself, not in Solr. Switching implementations would most likely result in a lot of regressions that we don't have tests for. ps: Steve, you're absolutely correct about the reason why there was never a separate noggit release. If github had been around in 2006, I might have chosen differently. Explore alternatives to Commons CSV --- Key: SOLR-3296 URL: https://issues.apache.org/jira/browse/SOLR-3296 Project: Solr Issue Type: Improvement Components: Build Reporter: Chris Male In LUCENE-3930 we're implementing some less than ideal solutions to make available the unreleased version of commons-csv. We could remove these solutions if we didn't rely on this lib. So I think we should explore alternatives. I think [opencsv|http://opencsv.sourceforge.net/] is an alternative to consider, I've used it in many commercial projects. Bizarrely Commons-CSV's website says that Opencsv uses a BSD license, but this isn't the case, OpenCSV uses ASL2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3296) Explore alternatives to Commons CSV
[ https://issues.apache.org/jira/browse/SOLR-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13242669#comment-13242669 ] Yonik Seeley commented on SOLR-3296: bq. Is this safe to cutover to in trunk? Yep, should be exactly the same code (just with different package names of course). Explore alternatives to Commons CSV --- Key: SOLR-3296 URL: https://issues.apache.org/jira/browse/SOLR-3296 Project: Solr Issue Type: Improvement Components: Build Reporter: Chris Male In LUCENE-3930 we're implementing some less than ideal solutions to make available the unreleased version of commons-csv. We could remove these solutions if we didn't rely on this lib. So I think we should explore alternatives. I think [opencsv|http://opencsv.sourceforge.net/] is an alternative to consider, I've used it in many commercial projects. Bizarrely Commons-CSV's website says that Opencsv uses a BSD license, but this isn't the case, OpenCSV uses ASL2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2202) Money/Currency FieldType
[ https://issues.apache.org/jira/browse/SOLR-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13242813#comment-13242813 ] Yonik Seeley commented on SOLR-2202: Looks like all of the files are in ./build/solr-idea/classes/test/solr/conf except for one... the .json file. It's either not being copied in the first place, or it's being deleted somehow. Money/Currency FieldType Key: SOLR-2202 URL: https://issues.apache.org/jira/browse/SOLR-2202 Project: Solr Issue Type: New Feature Components: Schema and Analysis Affects Versions: 1.5 Reporter: Greg Fodor Assignee: Jan Høydahl Fix For: 3.6, 4.0 Attachments: SOLR-2022-solr-3.patch, SOLR-2202-3x-stabilize-provider-interface.patch, SOLR-2202-fix-NPE-if-no-tlong-fieldType.patch, SOLR-2202-lucene-1.patch, SOLR-2202-no-fieldtype-deps.patch, SOLR-2202-solr-1.patch, SOLR-2202-solr-10.patch, SOLR-2202-solr-2.patch, SOLR-2202-solr-4.patch, SOLR-2202-solr-5.patch, SOLR-2202-solr-6.patch, SOLR-2202-solr-7.patch, SOLR-2202-solr-8.patch, SOLR-2202-solr-9.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch Provides support for monetary values to Solr/Lucene with query-time currency conversion. The following features are supported: - Point queries - Range quries - Sorting - Currency parsing by either currency code or symbol. - Symmetric Asymmetric exchange rates. (Asymmetric exchange rates are useful if there are fees associated with exchanging the currency.) At indexing time, money fields can be indexed in a native currency. For example, if a product on an e-commerce site is listed in Euros, indexing the price field as 1000,EUR will index it appropriately. By altering the currency.xml file, the sorting and querying against Solr can take into account fluctuations in currency exchange rates without having to re-index the documents. The new money field type is a polyfield which indexes two fields, one which contains the amount of the value and another which contains the currency code or symbol. The currency metadata (names, symbols, codes, and exchange rates) are expected to be in an xml file which is pointed to by the field type declaration in the schema.xml. The current patch is factored such that Money utility functions and configuration metadata lie in Lucene (see MoneyUtil and CurrencyConfig), while the MoneyType and MoneyValueSource lie in Solr. This was meant to mirror the work being done on the spacial field types. This patch will be getting used to power the international search capabilities of the search engine at Etsy. Also see WIKI page: http://wiki.apache.org/solr/MoneyFieldType -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3296) Explore alternatives to Commons CSV
[ https://issues.apache.org/jira/browse/SOLR-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13242897#comment-13242897 ] Yonik Seeley commented on SOLR-3296: If the deal is about commons-csv not having a release yet, a much easier (and safer) path seems to just wait for them to do that and upgrade at that time. Explore alternatives to Commons CSV --- Key: SOLR-3296 URL: https://issues.apache.org/jira/browse/SOLR-3296 Project: Solr Issue Type: Improvement Components: Build Reporter: Chris Male In LUCENE-3930 we're implementing some less than ideal solutions to make available the unreleased version of commons-csv. We could remove these solutions if we didn't rely on this lib. So I think we should explore alternatives. I think [opencsv|http://opencsv.sourceforge.net/] is an alternative to consider, I've used it in many commercial projects. Bizarrely Commons-CSV's website says that Opencsv uses a BSD license, but this isn't the case, OpenCSV uses ASL2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3930) nuke jars from source tree and use ivy
[ https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241179#comment-13241179 ] Yonik Seeley commented on LUCENE-3930: -- Ugh... We copied the source for commons-csv and noggit? Feels like the cure is worse than the disease here... nuke jars from source tree and use ivy -- Key: LUCENE-3930 URL: https://issues.apache.org/jira/browse/LUCENE-3930 Project: Lucene - Java Issue Type: Task Components: general/build Reporter: Robert Muir Assignee: Robert Muir Priority: Blocker Fix For: 3.6 Attachments: LUCENE-3930-solr-example.patch, LUCENE-3930-solr-example.patch, LUCENE-3930.patch, LUCENE-3930.patch, LUCENE-3930.patch, ant_-verbose_clean_test.out.txt, noggit-commons-csv.patch, patch-jetty-build.patch As mentioned on the ML thread: switch jars to ivy mechanism?. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3930) nuke jars from source tree and use ivy
[ https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241252#comment-13241252 ] Yonik Seeley commented on LUCENE-3930: -- bq. if anyone else has a different opinion and is willing to sacrifice days of their life arguing with apache board members instead The third option was to do nothing hasty and wait for the actual board to come to a decision and communicate with PMCs. Too late for this issue... but something to consider for the future. nuke jars from source tree and use ivy -- Key: LUCENE-3930 URL: https://issues.apache.org/jira/browse/LUCENE-3930 Project: Lucene - Java Issue Type: Task Components: general/build Reporter: Robert Muir Assignee: Robert Muir Priority: Blocker Fix For: 3.6 Attachments: LUCENE-3930-solr-example.patch, LUCENE-3930-solr-example.patch, LUCENE-3930.patch, LUCENE-3930.patch, LUCENE-3930.patch, ant_-verbose_clean_test.out.txt, noggit-commons-csv.patch, patch-jetty-build.patch As mentioned on the ML thread: switch jars to ivy mechanism?. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3930) nuke jars from source tree and use ivy
[ https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241267#comment-13241267 ] Yonik Seeley commented on LUCENE-3930: -- Let's all please try to keep discussions civil folks. nuke jars from source tree and use ivy -- Key: LUCENE-3930 URL: https://issues.apache.org/jira/browse/LUCENE-3930 Project: Lucene - Java Issue Type: Task Components: general/build Reporter: Robert Muir Assignee: Robert Muir Priority: Blocker Fix For: 3.6 Attachments: LUCENE-3930-solr-example.patch, LUCENE-3930-solr-example.patch, LUCENE-3930.patch, LUCENE-3930.patch, LUCENE-3930.patch, ant_-verbose_clean_test.out.txt, noggit-commons-csv.patch, patch-jetty-build.patch As mentioned on the ML thread: switch jars to ivy mechanism?. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3029) Poor json formatting of spelling collation info
[
https://issues.apache.org/jira/browse/SOLR-3029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241299#comment-13241299
]
Yonik Seeley commented on SOLR-3029:
Thanks for the explanations! (and yeah, I had lost track of the older
issues...)
bq. The collations are ranked, so order is important.
I guess I meant for a single collation:
{code}
collation,[
collationQuery,abcdefgx solra,
hits,0,
misspellingsAndCorrections,[...
{code}
It seems like that should be a map?
{code}
{collationQuery : abcdefgx solra,
hits : 0
misspellingsAndCorrections : {...
}
{code}
And if there are multiple collations, there should be an array of those maps?
bq. I do agree the spellcheck response format leaves something to be desired
and maybe 4.0 is a good time to break backwards and improve it.
+1, go for it!
Poor json formatting of spelling collation info
---
Key: SOLR-3029
URL: https://issues.apache.org/jira/browse/SOLR-3029
Project: Solr
Issue Type: Bug
Components: spellchecker
Affects Versions: 4.0
Reporter: Antony Stubbs
Priority: Blocker
Attachments: SOLR-3029.patch
{noformat}
spellcheck: {
suggestions: [
dalllas,
{
snip
{
word: canallas,
freq: 1
}
]
},
correctlySpelled,
false,
collation,
dallas
]
}
{noformat}
The correctlySpelled and collation key/values are stored as consecutive
elements in an array - quite odd. Is there a reason isn't not a key/value map
like most things?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2202) Money/Currency FieldType
[
https://issues.apache.org/jira/browse/SOLR-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241998#comment-13241998
]
Yonik Seeley commented on SOLR-2202:
I can't seem to run a lot of tests from IntelliJ after this.
{code}
Caused by: java.lang.RuntimeException: Can't find resource
'open-exchange-rates.json' in classpath or
'/opt/code/lusolr/solr/build/solr-idea/classes/test/solr/conf/',
cwd=/opt/code/lusolr
at
org.apache.solr.core.SolrResourceLoader.openResource(SolrResourceLoader.java:293)
at
org.apache.solr.schema.OpenExchangeRatesOrgProvider.reload(OpenExchangeRatesOrgProvider.java:126)
$ find . -name open-exchange-rates.json
./build/solr-core/test-files/solr/conf/open-exchange-rates.json
./core/src/test-files/solr/conf/open-exchange-rates.json
{code}
Anyone else?
Money/Currency FieldType
Key: SOLR-2202
URL: https://issues.apache.org/jira/browse/SOLR-2202
Project: Solr
Issue Type: New Feature
Components: Schema and Analysis
Affects Versions: 1.5
Reporter: Greg Fodor
Assignee: Jan Høydahl
Fix For: 3.6, 4.0
Attachments: SOLR-2022-solr-3.patch,
SOLR-2202-3x-stabilize-provider-interface.patch,
SOLR-2202-fix-NPE-if-no-tlong-fieldType.patch, SOLR-2202-lucene-1.patch,
SOLR-2202-no-fieldtype-deps.patch, SOLR-2202-solr-1.patch,
SOLR-2202-solr-10.patch, SOLR-2202-solr-2.patch, SOLR-2202-solr-4.patch,
SOLR-2202-solr-5.patch, SOLR-2202-solr-6.patch, SOLR-2202-solr-7.patch,
SOLR-2202-solr-8.patch, SOLR-2202-solr-9.patch, SOLR-2202.patch,
SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch,
SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch
Provides support for monetary values to Solr/Lucene with query-time currency
conversion. The following features are supported:
- Point queries
- Range quries
- Sorting
- Currency parsing by either currency code or symbol.
- Symmetric Asymmetric exchange rates. (Asymmetric exchange rates are
useful if there are fees associated with exchanging the currency.)
At indexing time, money fields can be indexed in a native currency. For
example, if a product on an e-commerce site is listed in Euros, indexing the
price field as 1000,EUR will index it appropriately. By altering the
currency.xml file, the sorting and querying against Solr can take into
account fluctuations in currency exchange rates without having to re-index
the documents.
The new money field type is a polyfield which indexes two fields, one which
contains the amount of the value and another which contains the currency code
or symbol. The currency metadata (names, symbols, codes, and exchange rates)
are expected to be in an xml file which is pointed to by the field type
declaration in the schema.xml.
The current patch is factored such that Money utility functions and
configuration metadata lie in Lucene (see MoneyUtil and CurrencyConfig),
while the MoneyType and MoneyValueSource lie in Solr. This was meant to
mirror the work being done on the spacial field types.
This patch will be getting used to power the international search
capabilities of the search engine at Etsy.
Also see WIKI page: http://wiki.apache.org/solr/MoneyFieldType
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2724) Deprecate defaultSearchField and defaultOperator defined in schema.xml
[ https://issues.apache.org/jira/browse/SOLR-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240633#comment-13240633 ] Yonik Seeley commented on SOLR-2724: I think I agree with Hoss and Erick here... we're not really gaining anything with this change, and it does seem likely it will cause problems for people upgrading. Deprecate defaultSearchField and defaultOperator defined in schema.xml -- Key: SOLR-2724 URL: https://issues.apache.org/jira/browse/SOLR-2724 Project: Solr Issue Type: Improvement Components: Schema and Analysis, search Reporter: David Smiley Assignee: David Smiley Priority: Minor Fix For: 3.6, 4.0 Attachments: SOLR-2724_deprecateDefaultSearchField_and_defaultOperator.patch Original Estimate: 2h Remaining Estimate: 2h I've always been surprised to see the defaultSearchField element and solrQueryParser defaultOperator=OR/ defined in the schema.xml file since the first time I saw them. They just seem out of place to me since they are more query parser related than schema related. But not only are they misplaced, I feel they shouldn't exist. For query parsers, we already have a df parameter that works just fine, and explicit field references. And the default lucene query operator should stay at OR -- if a particular query wants different behavior then use q.op or simply use OR. similarity Seems like something better placed in solrconfig.xml than in the schema. In my opinion, defaultSearchField and defaultOperator configuration elements should be deprecated in Solr 3.x and removed in Solr 4. And similarity should move to solrconfig.xml. I am willing to do it, provided there is consensus on it of course. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3029) Poor json formatting of spelling collation info
[
https://issues.apache.org/jira/browse/SOLR-3029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240923#comment-13240923
]
Yonik Seeley commented on SOLR-3029:
OK, this may be too much for 3.6.
I tried an example and it looks like there are a couple of places with this
problem.
I edited solr.xml so the name field looked like
{code}
field name=nameSolr, the Enterprise Search Server solra solrb abcdefgx
abcdefgy/field
{code}
Then I tried the following spellcheck command:
http://localhost:8983/solr/spell?q=abcdefgq%20solrzspellcheck=truespellcheck.collate=truespellcheck.build=truespellcheck.collateExtendedResults=truespellcheck.count=3spellcheck.maxCollations=3wt=jsonindent=true
{code}
spellcheck:{
suggestions:[
abcdefgq,{
numFound:2,
startOffset:0,
endOffset:8,
suggestion:[abcdefgx,
abcdefgy]},
solrz,{
numFound:3,
startOffset:9,
endOffset:14,
suggestion:[solra,
solrb,
solr]},
collation,[
collationQuery,abcdefgx solra,
hits,0,
misspellingsAndCorrections,[
abcdefgq,abcdefgx,
solrz,solra]]]}}
{code}
Apologies if I'm misinterpreting some things - I don't have much experience
with the spellchecker stuff (other than trying to clean up the tests in the
past).
Observations:
- Unless order is really important, suggestions should be a map
- same for collation and misspellingsAndCorrections
- why is collation inside suggestions along with other words? should this
be one level higher?
- why isn't this giving me multiple collations... am I misunderstanding the
spellcheck.maxCollations parameter
- why aren't multiple suggestions returned in misspellingsAndCorrections? (and
what's the purpose of this seemingly redundant info anyway?)
- I briefly tried distributed search by adding
shards=localhost:8983/solrshards.qt=/spell and I get
{code}
error:{
msg:isShard is only acceptable with search handlers,
code:400}}
{code}
Poor json formatting of spelling collation info
---
Key: SOLR-3029
URL: https://issues.apache.org/jira/browse/SOLR-3029
Project: Solr
Issue Type: Bug
Components: spellchecker
Affects Versions: 4.0
Reporter: Antony Stubbs
Priority: Blocker
Attachments: SOLR-3029.patch
{noformat}
spellcheck: {
suggestions: [
dalllas,
{
snip
{
word: canallas,
freq: 1
}
]
},
correctlySpelled,
false,
collation,
dallas
]
}
{noformat}
The correctlySpelled and collation key/values are stored as consecutive
elements in an array - quite odd. Is there a reason isn't not a key/value map
like most things?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2242) Get distinct count of names for a facet field
[
https://issues.apache.org/jira/browse/SOLR-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239544#comment-13239544
]
Yonik Seeley commented on SOLR-2242:
There are other JIRA issues open for adding more facet-related data as well,
and adding a new section for each doesn't seem desirable.
I think I'm still in favor of biting the bullet and changing the facet response
format for 4.0, while having some sort of flag to enable the older format for
back compat.
Get distinct count of names for a facet field
-
Key: SOLR-2242
URL: https://issues.apache.org/jira/browse/SOLR-2242
Project: Solr
Issue Type: New Feature
Components: Response Writers
Affects Versions: 4.0
Reporter: Bill Bell
Priority: Minor
Fix For: 4.0
Attachments: SOLR-2242-3x.patch, SOLR-2242-solr40-3.patch,
SOLR-2242.patch, SOLR-2242.patch, SOLR-2242.patch,
SOLR-2242.shard.withtests.patch, SOLR-2242.solr3.1-fix.patch,
SOLR-2242.solr3.1.patch, SOLR-2242.solr35.patch, SOLR.2242.solr3.1.patch
When returning facet.field=name of field you will get a list of matches for
distinct values. This is normal behavior. This patch tells you how many
distinct values you have (# of rows). Use with limit=-1 and mincount=1.
The feature is called namedistinct. Here is an example:
http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solrindent=trueq=*:*facet=truefacet.mincount=1facet.numFacetTerms=2facet.limit=-1facet.field=price
http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solrindent=trueq=*:*facet=truefacet.mincount=1facet.numFacetTerms=0facet.limit=-1facet.field=price
http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solrindent=trueq=*:*facet=truefacet.mincount=1facet.numFacetTerms=1facet.limit=-1facet.field=price
This currently only works on facet.field.
{code}
lst name=facet_fields
lst name=price
int name=numFacetTerms14/int
int name=0.03/intint name=11.51/intint
name=19.951/intint name=74.991/intint name=92.01/intint
name=179.991/intint name=185.01/intint name=279.951/intint
name=329.951/intint name=350.01/intint name=399.01/intint
name=479.951/intint name=649.991/intint name=2199.01/int
/lst
/lst
{code}
Several people use this to get the group.field count (the # of groups).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3738) Be consistent about negative vInt/vLong
[ https://issues.apache.org/jira/browse/LUCENE-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239618#comment-13239618 ] Yonik Seeley commented on LUCENE-3738: -- Regarding unrolling... it hasn't always proved faster in the past, esp wrt vint. My first try was in 2005: http://www.lucidimagination.com/search/document/6d2efedb4dde07d#2a896a9a9adc3f2d And again in 2006: https://issues.apache.org/jira/browse/LUCENE-639 Be consistent about negative vInt/vLong --- Key: LUCENE-3738 URL: https://issues.apache.org/jira/browse/LUCENE-3738 Project: Lucene - Java Issue Type: Bug Reporter: Michael McCandless Assignee: Uwe Schindler Fix For: 3.6, 4.0 Attachments: LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch Today, write/readVInt allows a negative int, in that it will encode and decode correctly, just horribly inefficiently (5 bytes). However, read/writeVLong fails (trips an assert). I'd prefer that both vInt/vLong trip an assert if you ever try to write a negative number... it's badly trappy today. But, unfortunately, we sometimes rely on this... had we had this assert in 'since the beginning' we could have avoided that. So, if we can't add that assert in today, I think we should at least fix readVLong to handle negative longs... but then you quietly spend 9 bytes (even more trappy!). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3029) Poor json formatting of spelling collation info
[
https://issues.apache.org/jira/browse/SOLR-3029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240055#comment-13240055
]
Yonik Seeley commented on SOLR-3029:
Any objections to changing this for both 3.6 and 4.0?
It's technically a back compat break, but it was messed up to begin with (and
the change should not affect clients using javabin or xml).
Poor json formatting of spelling collation info
---
Key: SOLR-3029
URL: https://issues.apache.org/jira/browse/SOLR-3029
Project: Solr
Issue Type: Bug
Components: spellchecker
Affects Versions: 4.0
Reporter: Antony Stubbs
Attachments: SOLR-3029.patch
{noformat}
spellcheck: {
suggestions: [
dalllas,
{
snip
{
word: canallas,
freq: 1
}
]
},
correctlySpelled,
false,
collation,
dallas
]
}
{noformat}
The correctlySpelled and collation key/values are stored as consecutive
elements in an array - quite odd. Is there a reason isn't not a key/value map
like most things?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3259) Solr 4 aesthetics
[ https://issues.apache.org/jira/browse/SOLR-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233402#comment-13233402 ] Yonik Seeley commented on SOLR-3259: Some ideas: - our fieldType list has grown *huge*... we should probably move the field list to the top of the file where it's easier to find - the preference for JSON over XML seems to be continuing - we should make things more JSON oriented by adding a /query handler that defaults to wt=json and perhaps indent=true - the concept of an example server that you must configure yourself has become less than ideal... perhaps we should just create a server directory (but leave things like exampledocs under example) - some new JSON based example docs that aren't based on electronics from '05 (or as an alternative for certain quickstart guides, start off with a curl command to add some data rather than trying to shove it all in exampledocs) Solr 4 aesthetics - Key: SOLR-3259 URL: https://issues.apache.org/jira/browse/SOLR-3259 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Fix For: 4.0 Solr 4 will be a huge new release... we should take this opportunity to improve the out-of-the-box experience. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3258) Ping query caused exception..Invalid version (expected 2, but 60) or the data in not in 'javabin' format
[
https://issues.apache.org/jira/browse/SOLR-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233426#comment-13233426
]
Yonik Seeley commented on SOLR-3258:
bq. I suspected Solr's distributed capabilities because of the error occuring
with distrib=true.
I was going to ask... do you mean for the ping query to be distributed?
Ping query caused exception..Invalid version (expected 2, but 60) or the data
in not in 'javabin' format
Key: SOLR-3258
URL: https://issues.apache.org/jira/browse/SOLR-3258
Project: Solr
Issue Type: Bug
Environment: solr-impl 4.0-SNAPSHOT 1302403 - markus - 2012-03-19
13:55:51
Reporter: Markus Jelsma
Fix For: 4.0
Attachments: debugging.patch, zkdump.txt
In a test set-up with nodes=2, shards=3 and cores=6 we often see this
exception in the logs. Once every few ping requests this is thrown, other
request return a proper OK.
Ping request handler:
{code}
requestHandler name=/admin/ping class=solr.PingRequestHandler
lst name=invariants
str name=qtselect/str
str name=q*:*/str
int name=rows0/int
/lst
lst name=defaults
str name=wtjson/str
str name=echoParamsall/str
bool name=omitHeadertrue/bool
/lst
/requestHandler
{code}
Exception:
{code}
2012-03-20 13:16:06,405 INFO [solr.core.SolrCore] - [http-80-18] - : [core_a]
webapp=/solr path=/admin/ping params={} status=500 QTime=7
2012-03-20 13:16:06,406 ERROR [solr.servlet.SolrDispatchFilter] -
[http-80-18] - : null:org.apache.solr.common.SolrException: Ping query caused
exception: org.apache.solr.client.solrj.SolrServerException:
java.lang.RuntimeException: Invalid version (expected 2, but 60) or the data
in not in 'javabin' format
at
org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:77)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1540)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:435)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:256)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.apache.solr.common.SolrException:
org.apache.solr.client.solrj.SolrServerException: java.lang.RuntimeException:
Invalid version (expected 2, but 60) or the data in not in 'javabin' format
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1540)
at
org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:68)
... 16 more
Caused by: org.apache.solr.client.solrj.SolrServerException:
java.lang.RuntimeException: Invalid version (expected 2, but 60) or the data
in not in 'javabin' format
at
org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:278)
at
org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHandler.java:158)
at
org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHandler.java:123)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
[jira] [Commented] (SOLR-3259) Solr 4 aesthetics
[ https://issues.apache.org/jira/browse/SOLR-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233629#comment-13233629 ] Yonik Seeley commented on SOLR-3259: Would also be nice to remove the multicore directory in there (since the normal server is already multi-core enabled). Of course if we moved just the essential parts to server, then multicore, example-DIH and exampledocs would all be left behind in example, as they should be. Solr 4 aesthetics - Key: SOLR-3259 URL: https://issues.apache.org/jira/browse/SOLR-3259 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Fix For: 4.0 Solr 4 will be a huge new release... we should take this opportunity to improve the out-of-the-box experience. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2959) edismax uf param does not work with magic fields '_query_' and '_val_'
[ https://issues.apache.org/jira/browse/SOLR-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234040#comment-13234040 ] Yonik Seeley commented on SOLR-2959: +1, looks good. edismax uf param does not work with magic fields '_query_' and '_val_' -- Key: SOLR-2959 URL: https://issues.apache.org/jira/browse/SOLR-2959 Project: Solr Issue Type: Bug Components: query parsers Reporter: Michael Watts Assignee: Hoss Man Priority: Minor Fix For: 3.6 Attachments: SOLR-2959.patch, SOLR-2959.patch, SOLR-2959.patch The edismax query parser should recognize the magic fields '\_query\_' and '\_val\_' as field names that can be allowed/restricted using uf just like any other field name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2424) extracted text from tika has no spaces
[ https://issues.apache.org/jira/browse/SOLR-2424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232611#comment-13232611 ] Yonik Seeley commented on SOLR-2424: Yes, I just confirmed that the command given in the description no longer results in text w/o spaces. extracted text from tika has no spaces -- Key: SOLR-2424 URL: https://issues.apache.org/jira/browse/SOLR-2424 Project: Solr Issue Type: Bug Components: contrib - Solr Cell (Tika extraction) Affects Versions: 3.1 Reporter: Yonik Seeley Fix For: 3.5 Attachments: ET2000 Service Manual.pdf Try this: curl http://localhost:8983/solr/update/extract?extractOnly=truewt=jsonindent=true; -F tutorial=@tutorial.pdf And you get text output w/o spaces: ThisdocumentcoversthebasicsofrunningSolru... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3159) Upgrade to Jetty 8
[
https://issues.apache.org/jira/browse/SOLR-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232622#comment-13232622
]
Yonik Seeley commented on SOLR-3159:
From that link, it looks like it should probably be:
{code}
Call name=setAttribute
Argorg.eclipse.jetty.server.Request.maxFormContentSize/Arg
Arg20/Arg
/Call
{code}
Can anyone test and confirm this works?
bq. These are the same settings we had for jetty 6, but I do not know if this
is still the best choice. In particular, I'm not sure about the
.bio.SocketConnector vs .nio.SelectChannelConnector
The NIO connector was causing intermittent failures on Jenkins. I have no idea
if the bugs were ever found/fixed in Jetty land - but it's a risk. It would be
nice to move to the NIO connector if it is now stable though, since it could
possibly allow for better logging/debugging (i.e. if we can specify our own
thread pool to handle requests such that we can tell different jetty instances
apart during logging).
Upgrade to Jetty 8
--
Key: SOLR-3159
URL: https://issues.apache.org/jira/browse/SOLR-3159
Project: Solr
Issue Type: Task
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Priority: Minor
Fix For: 4.0
Attachments: SOLR-3159-maven.patch
Solr is currently tested (and bundled) with a patched jetty-6 version.
Ideally we can release and test with a standard version.
Jetty-6 (at codehaus) is just maintenance now. New development and
improvements are now hosted at eclipse. Assuming performance is equivalent,
I think we should switch to Jetty 8.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3256) Distributed search throws NPE when using fl=score
[ https://issues.apache.org/jira/browse/SOLR-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233089#comment-13233089 ] Yonik Seeley commented on SOLR-3256: Confirmed... and you don't even need two nodes: http://localhost:8983/solr/select?q=*:*shards=localhost:8983/solrfl=score Distributed search throws NPE when using fl=score - Key: SOLR-3256 URL: https://issues.apache.org/jira/browse/SOLR-3256 Project: Solr Issue Type: Bug Reporter: Tomás Fernández Löbbe Priority: Minor Fix For: 4.0 Steps to reproduce the problem: Start two Solr instances (may use the example configuration) add some documents to both instances execute a query like: http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:8984/solrq=(ipod%20OR%20display)*fl=score* Expected result: List of scores or at least an exception saying that this request is not supported (may not make too much sense to do fl=score, but a descriptive exception can help debug the problem) Getting: SEVERE: null:java.lang.NullPointerException at org.apache.solr.handler.component.QueryComponent.returnFields(QueryComponent.java:985) at org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:637) at org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:612) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:307) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1540) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:435) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:256) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) at org.eclipse.jetty.server.Server.handle(Server.java:351) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534) at java.lang.Thread.run(Thread.java:636) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3256) Distributed search throws NPE when using fl=score
[
https://issues.apache.org/jira/browse/SOLR-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233090#comment-13233090
]
Yonik Seeley commented on SOLR-3256:
It looks like the fl is modified for the first phase to id,score but not on
the second phase.
{code}
INFO: [] webapp=/solr path=/select
params={fl=id,scoreshard.url=localhost:8983/solrNOW=1332206350114start=0q=*:*distrib=falseisShard=truewt=javabinfsv=truerows=10version=2}
hits=32 status=0 QTime=1
Mar 19, 2012 9:19:10 PM org.apache.solr.core.SolrCore execute
INFO: [] webapp=/solr path=/select
params={fl=scoreshard.url=localhost:8983/solrNOW=1332206350114q=*:*ids=SP2514N,GB18030TEST,apple,F8V7067-APL-KIT,adata,6H500F0,MA147LL/A,ati,IW-02,asusdistrib=falseisShard=truewt=javabinrows=10version=2}
status=0 QTime=1
{code}
Distributed search throws NPE when using fl=score
-
Key: SOLR-3256
URL: https://issues.apache.org/jira/browse/SOLR-3256
Project: Solr
Issue Type: Bug
Reporter: Tomás Fernández Löbbe
Priority: Minor
Fix For: 4.0
Steps to reproduce the problem:
Start two Solr instances (may use the example configuration)
add some documents to both instances
execute a query like:
http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:8984/solrq=(ipod%20OR%20display)*fl=score*
Expected result:
List of scores or at least an exception saying that this request is not
supported (may not make too much sense to do fl=score, but a descriptive
exception can help debug the problem)
Getting:
SEVERE: null:java.lang.NullPointerException
at
org.apache.solr.handler.component.QueryComponent.returnFields(QueryComponent.java:985)
at
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:637)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:612)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:307)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1540)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:435)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:256)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111)
at org.eclipse.jetty.server.Server.handle(Server.java:351)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230)
at
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66)
at
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534)
at java.lang.Thread.run(Thread.java:636)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
[jira] [Commented] (SOLR-3256) Distributed search throws NPE when using fl=score
[
https://issues.apache.org/jira/browse/SOLR-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233103#comment-13233103
]
Yonik Seeley commented on SOLR-3256:
Culprit is line 948 of QueryComponent:
{code}
// currently, score is synonymous with *,score so
// don't add id if the fl is empty or score or it would change the
meaning.
if (fl.length()!=0 !score.equals(fl) !*.equals(fl)) {
sreq.params.set(CommonParams.FL, fl+','+uniqueField.getName());
}
{code}
I think with the new pseudo-fields / ReturnFields feature, score no longer
means *,score.
Furthermore, it doesn't look like the multiple fl param feature is working
with distributed search:
http://localhost:8983/solr/select?q=*:*shards=localhost:8983/solrfl=idfl=pricefl=cat
(the response only contains id)
Distributed search throws NPE when using fl=score
-
Key: SOLR-3256
URL: https://issues.apache.org/jira/browse/SOLR-3256
Project: Solr
Issue Type: Bug
Reporter: Tomás Fernández Löbbe
Priority: Minor
Fix For: 4.0
Steps to reproduce the problem:
Start two Solr instances (may use the example configuration)
add some documents to both instances
execute a query like:
http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:8984/solrq=(ipod%20OR%20display)*fl=score*
Expected result:
List of scores or at least an exception saying that this request is not
supported (may not make too much sense to do fl=score, but a descriptive
exception can help debug the problem)
Getting:
SEVERE: null:java.lang.NullPointerException
at
org.apache.solr.handler.component.QueryComponent.returnFields(QueryComponent.java:985)
at
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:637)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:612)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:307)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1540)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:435)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:256)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111)
at org.eclipse.jetty.server.Server.handle(Server.java:351)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230)
at
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66)
at
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534)
at java.lang.Thread.run(Thread.java:636)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please
[jira] [Commented] (SOLR-2949) QueryElevationComponent does not fully support distributed search
[ https://issues.apache.org/jira/browse/SOLR-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13231260#comment-13231260 ] Yonik Seeley commented on SOLR-2949: In distributedProcess, I understand the switching on reverse=true for the QEC comparator, but it looks like it modifies all of the sort fields? AFAIK, it's only QEC that currently has a field comparator that is reverse of the natural ordering of the objects it creates. Perhaps we just need to check for instanceof ElevationComparatorSource? QueryElevationComponent does not fully support distributed search - Key: SOLR-2949 URL: https://issues.apache.org/jira/browse/SOLR-2949 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Assignee: Mark Miller Priority: Minor Fix For: 3.6, 4.0 Attachments: SOLR-2949.patch The QueryElevationComponent does not fully support distributed search. Add tests and make a fix for it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3250) Dynamic Field capabilities based on value not name
[ https://issues.apache.org/jira/browse/SOLR-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230243#comment-13230243 ] Yonik Seeley commented on SOLR-3250: Of course hopefully everyone knows schemaless is mostly marketing b.s. - when people do this, there is still a schema, but it's guessed on first use (and hence generally a horrible idea for production systems). It would be easy enough on a single node... but how does one handle a cluster? Say you index price=0 on nodeA, and price=100.0 on nodeB? A quick thought on how it might work: - have a separate file auto_fields.json that keeps track of the mappings that would be the same for all cores using that schema - when we run across a field we haven't seen before, we must guess a type for it, then grab a lock - update the auto_fields.json - we can update our in-memory schema with any new fields we find in auto_fields.json - works the same in ZK mode... it's just the auto_fields.json is in ZK, and we would use something like optimistic locking to update it Dynamic Field capabilities based on value not name -- Key: SOLR-3250 URL: https://issues.apache.org/jira/browse/SOLR-3250 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll In some situations, one already knows the schema of their content, so having to declare a schema in Solr becomes cumbersome in some situations. For instance, if you have all your content in JSON (or can easily generate it) or other typed serializations, then you already have a schema defined. It would be nice if we could have support for dynamic fields that used whatever name was passed in, but then picked the appropriate FieldType for that field based on the value of the content. So, for instance, if the input is a number, it would select the appropriate numeric type. If it is a plain text string, it would pick the appropriate text field (you could even add in language detection here). If it is comma separated, it would treat them as keywords, etc. Also, we could likely send in a hint as to the type too. With this approach, you of course have a first in wins situation, but assuming you have this schema defined elsewhere, it is likely fine. Supporting such cases would allow us to be schemaless when appropriate, while offering the benefits of schemas when appropriate. Naturally, one could mix and match these too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3207) Add field name validation
[ https://issues.apache.org/jira/browse/SOLR-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230287#comment-13230287 ] Yonik Seeley commented on SOLR-3207: bq. same used for java identifiers (Character#isJavaIdentifierPart), plus the use of trailing '.' and '-' I think we should prob define it as I documented in the schema: !-- field names should consist of alphanumeric or underscore characters only and not start with a digit. This is not currently strictly enforced, but other field names will not have first class support from all components and back compatibility is not guaranteed. -- Add field name validation - Key: SOLR-3207 URL: https://issues.apache.org/jira/browse/SOLR-3207 Project: Solr Issue Type: Improvement Affects Versions: 4.0 Reporter: Luca Cavanna Fix For: 4.0 Attachments: SOLR-3207.patch Given the SOLR-2444 updated fl syntax and the SOLR-2719 regression, it would be useful to add some kind of validation regarding the field names you can use on Solr. The objective would be adding consistency, allowing only field names that you can then use within fl, sorting etc. The rules, taken from the actual StrParser behaviour, seem to be the following: - same used for java identifiers (Character#isJavaIdentifierPart), plus the use of trailing '.' and '-' - for the first character the rule is Character#isJavaIdentifierStart minus '$' (The dash can't be used as first character (SOLR-3191) for example) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3251) dynamically add field to schema
[
https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230373#comment-13230373
]
Yonik Seeley commented on SOLR-3251:
Any ideas for an external API?
We could use a single entry point for all things schema related...
http://localhost:8983/solr/schema
{addField:{myfield:{type:int ...}}
Or more specific to fields...
http://localhost:8983/solr/fields
OR
PUT/POST to http://localhost:8983/solr/schema/fields (nesting all schema
related stuff under schema would help pollute the namespace less)
{myfield:{type:int ...}}
I'm leaning toward the last option. Thoughts?
dynamically add field to schema
---
Key: SOLR-3251
URL: https://issues.apache.org/jira/browse/SOLR-3251
Project: Solr
Issue Type: New Feature
Reporter: Yonik Seeley
Attachments: SOLR-3251.patch
One related piece of functionality needed for SOLR-3250 is the ability to
dynamically add a field to the schema.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3251) dynamically add field to schema
[ https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230393#comment-13230393 ] Yonik Seeley commented on SOLR-3251: bq. Does this imply that the schema would be writeable? The in-memory schema object yes. The question is how to persist changes. I was thinking it might be easiest to keep a separate file alongside schema.xml for dynamically added fields for now. The term dynamicFields has already been taken though and we probably shouldn't overload it. Maybe extra_fields.json? Or maybe even schema.json/schema.yaml that acts as an extension of schema.xml (and could acquire additional features over time such as the ability to define types too?) But a separate file that just lists fields will be much quicker (and easier) to update. Reloading a full schema.xml (along with type instantiation) would currently be somewhat prohibitive. dynamically add field to schema --- Key: SOLR-3251 URL: https://issues.apache.org/jira/browse/SOLR-3251 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Attachments: SOLR-3251.patch One related piece of functionality needed for SOLR-3250 is the ability to dynamically add a field to the schema. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3207) Add field name validation
[ https://issues.apache.org/jira/browse/SOLR-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230422#comment-13230422 ] Yonik Seeley commented on SOLR-3207: bq. Regarding the trailing characters, do you mean we shouldn't use isJavaIdentifierPart anymore but something else? That was just a shortcut... looking again, it's pretty open (maybe more open than we want?) esp since unicode changes over time. Anyway, isJavaIdentifierPart doesn't include - or . If people do need another separator type character, we could allow $ too (just not as the first char, since that's taken by variable dereferencing). bq. That's even more restrictive than my patch since I've used the existing rules applied while parsing the fl parameter (ReturnFields class). Allowing '-' in the fl was just to resolve that regression for people who already used fieldnames like that and are upgrading. If we want to start validating field names strictly, then we should bump the schema version number (and should skip validating when the version number is less than that). Add field name validation - Key: SOLR-3207 URL: https://issues.apache.org/jira/browse/SOLR-3207 Project: Solr Issue Type: Improvement Affects Versions: 4.0 Reporter: Luca Cavanna Fix For: 4.0 Attachments: SOLR-3207.patch Given the SOLR-2444 updated fl syntax and the SOLR-2719 regression, it would be useful to add some kind of validation regarding the field names you can use on Solr. The objective would be adding consistency, allowing only field names that you can then use within fl, sorting etc. The rules, taken from the actual StrParser behaviour, seem to be the following: - same used for java identifiers (Character#isJavaIdentifierPart), plus the use of trailing '.' and '-' - for the first character the rule is Character#isJavaIdentifierStart minus '$' (The dash can't be used as first character (SOLR-3191) for example) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230574#comment-13230574 ] Yonik Seeley commented on LUCENE-3795: -- bq. I'd be very surprised to hear if this is true. If Math.toRadians had been written as x*(PI/180.0) then the compiler would have done constant folding and it would simply be multiplication by a constant. But it's unfortunately written as x/180.0*PI (for no good reason in this case), and the compiler/JVM is not allowed to do the simple transformation by itself. That's why we do it. Sometimes knowing how optimizers work and the restrictions on them allow one to know what will be faster or slower without benchmarking. I did benchmark it after the fact (after you questioned it), and it was indeed the case that Math.toRadians was much slower than a simple multiply. Replace spatial contrib module with LSP's spatial-lucene module --- Key: LUCENE-3795 URL: https://issues.apache.org/jira/browse/LUCENE-3795 Project: Lucene - Java Issue Type: New Feature Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been in development for approximately 1 year by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready. LSP is here: http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/. I'll add more comments to prevent the issue description from being too long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[
https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230685#comment-13230685
]
Yonik Seeley commented on LUCENE-3795:
--
bq. Can I see the benchmark? The trivial things I am trying seems to end up
equivalent
One way that can happen is if you don't use the values produced - hotspot can
eliminate the method calls altogether.
{code}
public class X {
public static double foo(double val) {
// return Math.toRadians(val);
return val * (Math.PI/180.0);
}
public static void main(String[] args) {
double x = 1.12345;
for (int i=0; i1; i++) {
x += foo(x) - foo(x+1);
}
System.out.println(x);
}
}
{code}
Replace spatial contrib module with LSP's spatial-lucene module
---
Key: LUCENE-3795
URL: https://issues.apache.org/jira/browse/LUCENE-3795
Project: Lucene - Java
Issue Type: New Feature
Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
Fix For: 4.0
I propose that Lucene's spatial contrib module be replaced with the
spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been
in development for approximately 1 year by David Smiley, Ryan McKinley, and
Chris Male and we feel it is ready. LSP is here:
http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene
module is intuitively in svn/trunk/spatial-lucene/.
I'll add more comments to prevent the issue description from being too long.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'
[ https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230842#comment-13230842 ] Yonik Seeley commented on SOLR-3161: Note that qt is needed even for distrib search in some cases... I was just trying to debug the query elevation component by hitting /elevate, and that turned around and hit /select (which doesn't have QEC by default). So I needed to use shards.qt=/elevate to get it to work. We really need to think about if we really want to disable qt by default... Use of 'qt' should be restricted to searching and should not start with a '/' - Key: SOLR-3161 URL: https://issues.apache.org/jira/browse/SOLR-3161 Project: Solr Issue Type: Improvement Components: search, web gui Reporter: David Smiley Assignee: David Smiley Fix For: 3.6, 4.0 Attachments: SOLR-3161-disable-qt-by-default.patch, SOLR-3161-dispatching-request-handler.patch, SOLR-3161-dispatching-request-handler.patch I haven't yet looked at the code involved for suggestions here; I'm speaking based on how I think things should work and not work, based on intuitiveness and security. In general I feel it is best practice to use '/' leading request handler names and not use qt, but I don't hate it enough when used in limited (search-only) circumstances to propose its demise. But if someone proposes its deprecation that then I am +1 for that. Here is my proposal: Solr should error if the parameter qt is supplied with a leading '/'. (trunk only) Solr should only honor qt if the target request handler extends solr.SearchHandler. The new admin UI should only use 'qt' when it has to. For the query screen, it could present a little pop-up menu of handlers to choose from, including /select?qt=mycustom for handlers that aren't named with a leading '/'. This choice should be positioned at the top. And before I forget, me or someone should investigate if there are any similar security problems with the shards.qt parameter. Perhaps shards.qt can abide by the same rules outlined above. Does anyone foresee any problems with this proposal? On a related subject, I think the notion of a default request handler is bad - the default=true thing. Honestly I'm not sure what it does, since I noticed Solr trunk redirects '/solr/' to the new admin UI at '/solr/#/'. Assuming it doesn't do anything useful anymore, I think it would be clearer to use requestHandler name=/select class=solr.SearchHandler instead of what's there now. The delta is to put the leading '/' on this request handler name, and remove the default attribute. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3239) Function for returning a CurrencyField as a virtual field
[
https://issues.apache.org/jira/browse/SOLR-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228403#comment-13228403
]
Yonik Seeley commented on SOLR-3239:
Nice idea using a function here!
Function for returning a CurrencyField as a virtual field
-
Key: SOLR-3239
URL: https://issues.apache.org/jira/browse/SOLR-3239
Project: Solr
Issue Type: New Feature
Reporter: Jan Høydahl
Fix For: 4.0
With the new CurrencyField from SOLR-2202, we can now do range queries, sort
and soon faceting on CurrencyField.
One thing we cannot do is return a converted value. We can only return the
stored value which must be in the same currency as it was entered, e.g.
10.0,USD. People now have to do this conversion in application layer,
reading the same currency.xml file as in Solr. This is a mess to keep in
sync, and is hard to support with other ExchangeRateProviders or in other
client languages than Java.
This patch should implement a Function which takes a field name and requested
currency as input and returns the converted value. Optionally it could also
take care of localized display, e.g. $10.0 instead of 10.0,USD. Proposed
syntax:
{code}
fl=title,price:currency(price_c,EUR) # Returns price_c in EUR as
price
fl=title,price:currency(price_c,EUR,en_US) # Returns price_c in EUR,
formatted according to en_US locale
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3866) Make CompositeReader.getSequentialSubReaders() and the corresponding IndexReaderContext methods return unmodifiable ListR extends IndexReader
[ https://issues.apache.org/jira/browse/LUCENE-3866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228415#comment-13228415 ] Yonik Seeley commented on LUCENE-3866: -- I think we should allow users to access in the most low-level efficient manner, just as lucene can. Remember, this is expert level stuff! Seems like at most we would need a javadoc comment saying don't modify this. Make CompositeReader.getSequentialSubReaders() and the corresponding IndexReaderContext methods return unmodifiable ListR extends IndexReader --- Key: LUCENE-3866 URL: https://issues.apache.org/jira/browse/LUCENE-3866 Project: Lucene - Java Issue Type: Improvement Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: 4.0 Since Lucene 2.9 we have the method getSequentialSubReader() returning IndexReader[]. Based on hardly-to-debug errors in user's code, Robert and me realized that returning an array from a public API is an anti-pattern. If the array is intended to be modifiable (like byte[] in terms,...), it is fine to use arrays in public APIs, but not, if the array must be protected from modification. As IndexReaders are 100% unmodifiable in trunk code (no deletions,...), the only possibility to corrumpt the reader is by modifying the array returned by getSequentialSubReaders(). We should prevent this. The same theoretically applies to FieldCache, too - but the party that is afraid of performance problems is too big to fight against that :( For getSequentialSubReaders there is no performance problem at all. The binary search of reader-ids inside BaseCompositeReader can still be done with the internal protected array, but public APIs should expose only a unmodifiable List. The same applies to leaves() and children() in IndexReaderContext. This change to list would also allow to make CompositeReader and CompositeReaderContext IterableR extends IndexReader, so some loops would look nice. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3145) Velocity /browse GUI should stick to AND as defaultOperator
[ https://issues.apache.org/jira/browse/SOLR-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228522#comment-13228522 ] Yonik Seeley commented on SOLR-3145: bq. SOLR-1889 was the correct change [...] Changing the queryparser default to AND is very bad +1 (but probably for different reasons than you ;-) But Jan is talking about just changing the default for just an example GUI (/browse), and not any query parsers. That's pretty minor - not a big deal either way, but I do think that from a finished product perspective, more people expect all of their query terms to appear in matching documents (and I believe this is how google does it?) Velocity /browse GUI should stick to AND as defaultOperator --- Key: SOLR-3145 URL: https://issues.apache.org/jira/browse/SOLR-3145 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.0 Reporter: Jan Høydahl Assignee: Jan Høydahl Fix For: 4.0 Attachments: SOLR-3145.patch After SOLR-1889 was committed, the DisMax mm parameter defaults to whatever set in q.op. Since defaultOperator in schema.xml is OR, this means that DisMax now defaults to OR (mm=0) instead of the old default (mm=100%). It should stick to AND as before. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3145) Velocity /browse GUI should stick to AND as defaultOperator
[ https://issues.apache.org/jira/browse/SOLR-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228557#comment-13228557 ] Yonik Seeley commented on SOLR-3145: bq. I believe this is how google does it? bq. This is false. Rather strong/blanket statement. It seems roughly true that adding non-trivial words to a google search lowers the number of matches. I guess we'll continue to disagree with a lowest common denominator approach to languages. It's too bad that our example has no stopwords or stemming any more because of this philosophy. Velocity /browse GUI should stick to AND as defaultOperator --- Key: SOLR-3145 URL: https://issues.apache.org/jira/browse/SOLR-3145 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.0 Reporter: Jan Høydahl Assignee: Jan Høydahl Fix For: 4.0 Attachments: SOLR-3145.patch After SOLR-1889 was committed, the DisMax mm parameter defaults to whatever set in q.op. Since defaultOperator in schema.xml is OR, this means that DisMax now defaults to OR (mm=0) instead of the old default (mm=100%). It should stick to AND as before. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3145) Velocity /browse GUI should stick to AND as defaultOperator
[ https://issues.apache.org/jira/browse/SOLR-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228616#comment-13228616 ] Yonik Seeley commented on SOLR-3145: bq. explicit sorting is a no-go for most use cases Heh. Seems we live in very different worlds. Perhaps Lucene is only about full-text search (at least it was in the past), but Solr has always been about much more than that. Sorting by other things than full-text relevance is extremely common. Velocity /browse GUI should stick to AND as defaultOperator --- Key: SOLR-3145 URL: https://issues.apache.org/jira/browse/SOLR-3145 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.0 Reporter: Jan Høydahl Assignee: Jan Høydahl Fix For: 4.0 Attachments: SOLR-3145.patch After SOLR-1889 was committed, the DisMax mm parameter defaults to whatever set in q.op. Since defaultOperator in schema.xml is OR, this means that DisMax now defaults to OR (mm=0) instead of the old default (mm=100%). It should stick to AND as before. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'
[ https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228629#comment-13228629 ] Yonik Seeley commented on SOLR-3161: bq. Regarding qt=/update what is your opinion on a compromise way forward? The most flexible way would be to add a method to SolrRequestHandler like boolean indirectDispatch(req) that would work for any type of request handler (and update handlers would default to false). But if one doesn't want this feature bleeding into the whole request handler architecture, we could distinguish update handlers from other handlers by adding a new base class or a marker interface. Use of 'qt' should be restricted to searching and should not start with a '/' - Key: SOLR-3161 URL: https://issues.apache.org/jira/browse/SOLR-3161 Project: Solr Issue Type: Improvement Components: search, web gui Reporter: David Smiley Assignee: David Smiley Fix For: 3.6, 4.0 Attachments: SOLR-3161-disable-qt-by-default.patch, SOLR-3161-dispatching-request-handler.patch, SOLR-3161-dispatching-request-handler.patch I haven't yet looked at the code involved for suggestions here; I'm speaking based on how I think things should work and not work, based on intuitiveness and security. In general I feel it is best practice to use '/' leading request handler names and not use qt, but I don't hate it enough when used in limited (search-only) circumstances to propose its demise. But if someone proposes its deprecation that then I am +1 for that. Here is my proposal: Solr should error if the parameter qt is supplied with a leading '/'. (trunk only) Solr should only honor qt if the target request handler extends solr.SearchHandler. The new admin UI should only use 'qt' when it has to. For the query screen, it could present a little pop-up menu of handlers to choose from, including /select?qt=mycustom for handlers that aren't named with a leading '/'. This choice should be positioned at the top. And before I forget, me or someone should investigate if there are any similar security problems with the shards.qt parameter. Perhaps shards.qt can abide by the same rules outlined above. Does anyone foresee any problems with this proposal? On a related subject, I think the notion of a default request handler is bad - the default=true thing. Honestly I'm not sure what it does, since I noticed Solr trunk redirects '/solr/' to the new admin UI at '/solr/#/'. Assuming it doesn't do anything useful anymore, I think it would be clearer to use requestHandler name=/select class=solr.SearchHandler instead of what's there now. The delta is to put the leading '/' on this request handler name, and remove the default attribute. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'
[ https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228657#comment-13228657 ] Yonik Seeley commented on SOLR-3161: As hoss points out, not all searching request handlers inherit from SearchHandler. bq. Adding what you propose adds more complexity than it's worth, IMO. The ability to distinguish an update handler from a request handler doesn't sound complex... the majority of the cases could be handled by adding implements SolrUpdateHandler to ContentStreamHandlerBase. Use of 'qt' should be restricted to searching and should not start with a '/' - Key: SOLR-3161 URL: https://issues.apache.org/jira/browse/SOLR-3161 Project: Solr Issue Type: Improvement Components: search, web gui Reporter: David Smiley Assignee: David Smiley Fix For: 3.6, 4.0 Attachments: SOLR-3161-disable-qt-by-default.patch, SOLR-3161-dispatching-request-handler.patch, SOLR-3161-dispatching-request-handler.patch I haven't yet looked at the code involved for suggestions here; I'm speaking based on how I think things should work and not work, based on intuitiveness and security. In general I feel it is best practice to use '/' leading request handler names and not use qt, but I don't hate it enough when used in limited (search-only) circumstances to propose its demise. But if someone proposes its deprecation that then I am +1 for that. Here is my proposal: Solr should error if the parameter qt is supplied with a leading '/'. (trunk only) Solr should only honor qt if the target request handler extends solr.SearchHandler. The new admin UI should only use 'qt' when it has to. For the query screen, it could present a little pop-up menu of handlers to choose from, including /select?qt=mycustom for handlers that aren't named with a leading '/'. This choice should be positioned at the top. And before I forget, me or someone should investigate if there are any similar security problems with the shards.qt parameter. Perhaps shards.qt can abide by the same rules outlined above. Does anyone foresee any problems with this proposal? On a related subject, I think the notion of a default request handler is bad - the default=true thing. Honestly I'm not sure what it does, since I noticed Solr trunk redirects '/solr/' to the new admin UI at '/solr/#/'. Assuming it doesn't do anything useful anymore, I think it would be clearer to use requestHandler name=/select class=solr.SearchHandler instead of what's there now. The delta is to put the leading '/' on this request handler name, and remove the default attribute. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3013) Add UIMA based tokenizers / filters that can be used in the schema.xml
[ https://issues.apache.org/jira/browse/SOLR-3013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228809#comment-13228809 ] Yonik Seeley commented on SOLR-3013: bq. Well, it's still marked Resolution: unresolved so I assume not. As long as commit messages have the JIRA issue in there, you can just click on All to see all commit related activity for the issue. Add UIMA based tokenizers / filters that can be used in the schema.xml -- Key: SOLR-3013 URL: https://issues.apache.org/jira/browse/SOLR-3013 Project: Solr Issue Type: Improvement Components: update Affects Versions: 3.5 Reporter: Tommaso Teofili Assignee: Tommaso Teofili Priority: Minor Labels: uima, update_request_handler Fix For: 3.6, 4.0 Attachments: SOLR-3013.patch Add UIMA based tokenizers / filters that can be declared and used directly inside the schema.xml. Thus instead of using the UIMA UpdateRequestProcessor one could directly define per-field NLP capable tokenizers / filters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[
https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228823#comment-13228823
]
Yonik Seeley commented on LUCENE-3795:
--
Guys, was there a specific reason why the degrees-radians conversion
optimizations were removed?
Example:
{code}
-return vals.doubleVal(doc) * DistanceUtils.DEGREES_TO_RADIANS;
+return Math.toRadians(vals.doubleVal(doc));
{code}
It won't matter for query setup, but will matter for per-document calculations.
Replace spatial contrib module with LSP's spatial-lucene module
---
Key: LUCENE-3795
URL: https://issues.apache.org/jira/browse/LUCENE-3795
Project: Lucene - Java
Issue Type: New Feature
Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
Fix For: 4.0
I propose that Lucene's spatial contrib module be replaced with the
spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been
in development for approximately 1 year by David Smiley, Ryan McKinley, and
Chris Male and we feel it is ready. LSP is here:
http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene
module is intuitively in svn/trunk/spatial-lucene/.
I'll add more comments to prevent the issue description from being too long.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3215) We should clone the SolrInputDocument before adding locally and then send that clone to replicas.
[ https://issues.apache.org/jira/browse/SOLR-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228889#comment-13228889 ] Yonik Seeley commented on SOLR-3215: Not sure I understand the problem this is solving. _version_ is added to the SolrInputDocument and then that can be indexed locally and sent to replicas. DistributedUpdateProcessor should come right before RunUpdateProcessor (or are you assuming we might support random update processors in-between? Are there use cases for this?) We should clone the SolrInputDocument before adding locally and then send that clone to replicas. - Key: SOLR-3215 URL: https://issues.apache.org/jira/browse/SOLR-3215 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.0 Attachments: SOLR-3215.patch If we don't do this, the behavior is a little unexpected. You cannot avoid having other processors always hit documents twice unless we support using multiple update chains. We have another issue open that should make this better, but I'd like to do this sooner than that. We are going to have to end up cloning anyway when we want to offer the ability to not wait for the local add before sending to replicas. Cloning with the current SolrInputDocument, SolrInputField apis is a little scary - there is an Object to contend with - but it seems we can pretty much count on that being a primitive that we don't have to clone? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228922#comment-13228922 ] Yonik Seeley commented on LUCENE-3795: -- bq. Surely the JVM can inline the Math.* methods, especially this one. Inlining yes, but not optimizing (compilers are very restricted in how they can optimize floating point calculations). Unfortunately Math.toRadians uses double precision division, which is much more expensive than multiplication. I just did a quick test, and Math.toRadians was more than 3 times slower. I've got most of the changes locally so I'll finish it up... Replace spatial contrib module with LSP's spatial-lucene module --- Key: LUCENE-3795 URL: https://issues.apache.org/jira/browse/LUCENE-3795 Project: Lucene - Java Issue Type: New Feature Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been in development for approximately 1 year by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready. LSP is here: http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/. I'll add more comments to prevent the issue description from being too long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'
[ https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227609#comment-13227609 ] Yonik Seeley commented on SOLR-3161: I don't think we should remove the ability to use qt with /-prefixed handlers, esp since the current patch here would disable qt by default. Use of 'qt' should be restricted to searching and should not start with a '/' - Key: SOLR-3161 URL: https://issues.apache.org/jira/browse/SOLR-3161 Project: Solr Issue Type: Improvement Components: search, web gui Reporter: David Smiley Assignee: David Smiley Fix For: 3.6, 4.0 Attachments: SOLR-3161-disable-qt-by-default.patch, SOLR-3161-dispatching-request-handler.patch, SOLR-3161-dispatching-request-handler.patch I haven't yet looked at the code involved for suggestions here; I'm speaking based on how I think things should work and not work, based on intuitiveness and security. In general I feel it is best practice to use '/' leading request handler names and not use qt, but I don't hate it enough when used in limited (search-only) circumstances to propose its demise. But if someone proposes its deprecation that then I am +1 for that. Here is my proposal: Solr should error if the parameter qt is supplied with a leading '/'. (trunk only) Solr should only honor qt if the target request handler extends solr.SearchHandler. The new admin UI should only use 'qt' when it has to. For the query screen, it could present a little pop-up menu of handlers to choose from, including /select?qt=mycustom for handlers that aren't named with a leading '/'. This choice should be positioned at the top. And before I forget, me or someone should investigate if there are any similar security problems with the shards.qt parameter. Perhaps shards.qt can abide by the same rules outlined above. Does anyone foresee any problems with this proposal? On a related subject, I think the notion of a default request handler is bad - the default=true thing. Honestly I'm not sure what it does, since I noticed Solr trunk redirects '/solr/' to the new admin UI at '/solr/#/'. Assuming it doesn't do anything useful anymore, I think it would be clearer to use requestHandler name=/select class=solr.SearchHandler instead of what's there now. The delta is to put the leading '/' on this request handler name, and remove the default attribute. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3230) Performance improvement for geofilt by doing a bbox approximation and then Filter
[
https://issues.apache.org/jira/browse/SOLR-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227891#comment-13227891
]
Yonik Seeley commented on SOLR-3230:
bq. There is no way to cache and force the order on 1st request?
You would currently need to use the lucene query parser to construct a single
query with both:
{code}
fq=+_query_:{!bbox} +_query_:{!geofilt}
{code}
Not pretty, but lets you experiment at least.
bq. Parameter? style=range or fieldcache? Default to fieldcache as it is now?
perhaps method=fc?
As far as the default, it's really tough to tell. For small distances, I'd
guess that range queries would normally be faster, and that's likely to be the
common case?
Performance improvement for geofilt by doing a bbox approximation and then
Filter
-
Key: SOLR-3230
URL: https://issues.apache.org/jira/browse/SOLR-3230
Project: Solr
Issue Type: Improvement
Reporter: Bill Bell
Assignee: Grant Ingersoll
Fix For: 4.0
Attachments: SOLR-3230.patch
This changes {!geofilt} to use a bounding box and then does a accurate filter.
See attachment
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3221) Make Shard handler threadpool configurable
[ https://issues.apache.org/jira/browse/SOLR-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227906#comment-13227906 ] Yonik Seeley commented on SOLR-3221: bq. The above monitor contention would appear to suggest that in some cases its possible for liveness issues to occur and for simple queries to be starved of resources simply due to a lack of attention from the viewpoint of context switching. that's pretty interesting... how many concurrent requests were you running through a single aggregator? Make Shard handler threadpool configurable -- Key: SOLR-3221 URL: https://issues.apache.org/jira/browse/SOLR-3221 Project: Solr Issue Type: Improvement Affects Versions: 3.6, 4.0 Reporter: Greg Bowyer Assignee: Erick Erickson Labels: distributed, http, shard Attachments: SOLR-3221-3x_branch.patch, SOLR-3221-3x_branch.patch, SOLR-3221-3x_branch.patch, SOLR-3221-3x_branch.patch, SOLR-3221-3x_branch.patch, SOLR-3221-trunk.patch, SOLR-3221-trunk.patch, SOLR-3221-trunk.patch, SOLR-3221-trunk.patch, SOLR-3221-trunk.patch From profiling of monitor contention, as well as observations of the 95th and 99th response times for nodes that perform distributed search (or ‟aggregator‟ nodes) it would appear that the HttpShardHandler code currently does a suboptimal job of managing outgoing shard level requests. Presently the code contained within lucene 3.5's SearchHandler and Lucene trunk / 3x's ShardHandlerFactory create arbitrary threads in order to service distributed search requests. This is done presently to limit the size of the threadpool such that it does not consume resources in deployment configurations that do not use distributed search. This unfortunately has two impacts on the response time if the node coordinating the distribution is under high load. The usage of the MaxConnectionsPerHost configuration option results in aggressive activity on semaphores within HttpCommons, it has been observed that the aggregator can have a response time far greater than that of the searchers. The above monitor contention would appear to suggest that in some cases its possible for liveness issues to occur and for simple queries to be starved of resources simply due to a lack of attention from the viewpoint of context switching. With, as mentioned above the http commons connection being hotly contended The fair, queue based configuration eliminates this, at the cost of throughput. This patch aims to make the threadpool largely configurable allowing for those using solr to choose the throughput vs latency balance they desire. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3230) Performance improvement for geofilt by doing a bbox approximation and then Filter
[
https://issues.apache.org/jira/browse/SOLR-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227077#comment-13227077
]
Yonik Seeley commented on SOLR-3230:
Looks like this patch would probably break post filtering for geofilt since the
spatial query would no longer be top-level.
geofilt already does do a bounding box, but it does it frange style where it
checks the fieldcache against documents.
It will tend to be be faster when many points match, and slower when few points
match.
It will also tend to be faster when cache=false and few points match the main
query + other filters.
Hence, it's very important to test these differences in the exact context they
will be used in (i.e. with typical queries and filters for your app).
One way to put the bbox before the geofilt when both are non-cached is
{code}
fq={!bbox cache=false cost=50}
fq={!geofilt cache=false cost=60}
{code}
I'm not sure what the right default is, or if we can somehow dynamically detect
which will be better for a particular request.
We could add a flag on geofilt to allow switching between the different
bounding box styles (fieldcache vs standard range).
Performance improvement for geofilt by doing a bbox approximation and then
Filter
-
Key: SOLR-3230
URL: https://issues.apache.org/jira/browse/SOLR-3230
Project: Solr
Issue Type: Improvement
Reporter: Bill Bell
Assignee: Grant Ingersoll
Fix For: 4.0
Attachments: SOLR-3230.patch
This changes {!geofilt} to use a bounding box and then does a accurate filter.
See attachment
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'
[ https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227300#comment-13227300 ] Yonik Seeley commented on SOLR-3161: It's not clear... do these proposals eliminate the possibility of using qt=/myhandler? I'm not sure we should be removing functionality that many have found useful. Use of 'qt' should be restricted to searching and should not start with a '/' - Key: SOLR-3161 URL: https://issues.apache.org/jira/browse/SOLR-3161 Project: Solr Issue Type: Improvement Components: search, web gui Reporter: David Smiley Assignee: David Smiley Fix For: 3.6, 4.0 Attachments: SOLR-3161-disable-qt-by-default.patch, SOLR-3161-dispatching-request-handler.patch, SOLR-3161-dispatching-request-handler.patch I haven't yet looked at the code involved for suggestions here; I'm speaking based on how I think things should work and not work, based on intuitiveness and security. In general I feel it is best practice to use '/' leading request handler names and not use qt, but I don't hate it enough when used in limited (search-only) circumstances to propose its demise. But if someone proposes its deprecation that then I am +1 for that. Here is my proposal: Solr should error if the parameter qt is supplied with a leading '/'. (trunk only) Solr should only honor qt if the target request handler extends solr.SearchHandler. The new admin UI should only use 'qt' when it has to. For the query screen, it could present a little pop-up menu of handlers to choose from, including /select?qt=mycustom for handlers that aren't named with a leading '/'. This choice should be positioned at the top. And before I forget, me or someone should investigate if there are any similar security problems with the shards.qt parameter. Perhaps shards.qt can abide by the same rules outlined above. Does anyone foresee any problems with this proposal? On a related subject, I think the notion of a default request handler is bad - the default=true thing. Honestly I'm not sure what it does, since I noticed Solr trunk redirects '/solr/' to the new admin UI at '/solr/#/'. Assuming it doesn't do anything useful anymore, I think it would be clearer to use requestHandler name=/select class=solr.SearchHandler instead of what's there now. The delta is to put the leading '/' on this request handler name, and remove the default attribute. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2719) REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing fl=my-field-name type usecases
[ https://issues.apache.org/jira/browse/SOLR-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222379#comment-13222379 ] Yonik Seeley commented on SOLR-2719: I've been saying for a while that using roughly java identifiers for field names was best practice, but we should document it somewhere. I don't think we should change StrParser.getId to be more permissive though - that will just cause more problems in the future (say when we want to start adding infix and want a-b to be a minus b. There's not a regression in that specific code since the function parser has never accepted - as part of a field name. REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing fl=my-field-name type usecases - Key: SOLR-2719 URL: https://issues.apache.org/jira/browse/SOLR-2719 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.0 Reporter: Nik V. Babichev Priority: Blocker Labels: field, fl, query, queryparser Fix For: 4.0 Attachments: SOLR-2719.patch fl=my-hyphen-field in query params parsed as my instead of my-hyphen-field. OAS.search.ReturnFields use method getId() from OAS.search.QueryParsing in which check chars if (!Character.isJavaIdentifierPart(ch) ch != '.') Hyphen is not JavaIdentifierPart and this check break when first - is found. This problem solve by passing '-' to check: if (!Character.isJavaIdentifierPart(ch) ch != '.' ch != '-') break; But I don't know how it can affect on whole project. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2719) REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing fl=my-field-name type usecases
[
https://issues.apache.org/jira/browse/SOLR-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222408#comment-13222408
]
Yonik Seeley commented on SOLR-2719:
bq. Yonik, I see your point. On the other hand, the dash is a widely used
character within field names. The regression is on the Solr behaviour, and I
think it's pretty annoying from a user perspective.
The easiest way to handle this would be this code in ReturnFields:
{code}
// short circuit test for a really simple field name
String key = null;
String field = sp.getId(null);
char ch = sp.ch();
{code}
Instead of using getId, we should hand-roll something that also accepts - as
part of the field name. That would leave function parser (and other users of
getId) alone, but allow fieldnames with dashes in the fl param.
bq. What matters more than anything else is consistency.
If we really want to go for consistency, then we should not accept - anywhere
(rather than attempting to expand it to everywhere).
REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing
fl=my-field-name type usecases
-
Key: SOLR-2719
URL: https://issues.apache.org/jira/browse/SOLR-2719
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 4.0
Reporter: Nik V. Babichev
Priority: Blocker
Labels: field, fl, query, queryparser
Fix For: 4.0
Attachments: SOLR-2719.patch
fl=my-hyphen-field in query params parsed as my instead of
my-hyphen-field.
OAS.search.ReturnFields use method getId() from OAS.search.QueryParsing
in which check chars if (!Character.isJavaIdentifierPart(ch) ch != '.')
Hyphen is not JavaIdentifierPart and this check break when first - is found.
This problem solve by passing '-' to check:
if (!Character.isJavaIdentifierPart(ch) ch != '.' ch != '-') break;
But I don't know how it can affect on whole project.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2719) REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing fl=my-field-name type usecases
[ https://issues.apache.org/jira/browse/SOLR-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222449#comment-13222449 ] Yonik Seeley commented on SOLR-2719: bq. How about trying to achieve both? I mean, are there many other places where we should do the same (adding the dash support)? I think this regression is limited to fl since that code was changed to support pseudo-fields. bq. QueryParsing#parseSort has the same problem. I just tried trunk with sort=a-b_s desc and it seemed to work fine. REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing fl=my-field-name type usecases - Key: SOLR-2719 URL: https://issues.apache.org/jira/browse/SOLR-2719 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.0 Reporter: Nik V. Babichev Priority: Blocker Labels: field, fl, query, queryparser Fix For: 4.0 Attachments: SOLR-2719.patch fl=my-hyphen-field in query params parsed as my instead of my-hyphen-field. OAS.search.ReturnFields use method getId() from OAS.search.QueryParsing in which check chars if (!Character.isJavaIdentifierPart(ch) ch != '.') Hyphen is not JavaIdentifierPart and this check break when first - is found. This problem solve by passing '-' to check: if (!Character.isJavaIdentifierPart(ch) ch != '.' ch != '-') break; But I don't know how it can affect on whole project. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package
[ https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222917#comment-13222917 ] Yonik Seeley commented on SOLR-3204: Background here: http://markmail.org/message/lsxtxoetpw7a47uf As far as I can determine, this is just a maven meta-data issue? i.e. it doesn't seem like we should change java package names, but just make sure that the maven meta-data is completely distinct from any official commons-csv releases? (disclaimer: I still really know nothing of maven, other than it's becoming more a pain all the time ;-) solr-commons-csv must not use the org.apache.commons.csv package Key: SOLR-3204 URL: https://issues.apache.org/jira/browse/SOLR-3204 Project: Solr Issue Type: Bug Affects Versions: 3.5 Reporter: Emmanuel Bourg Priority: Blocker Fix For: 3.6 The solr-commons-csv artifact reused the code from the Apache Commons CSV project but the package wasn't changed to something else than org.apache.commons.csv in the process. This creates a compatibility issue as the Apache Commons team works toward an official release of Commons CSV. It prevents Commons CSV from using its own org.apache.commons.csv package, or forces the renaming of all the classes to avoid a classpath conflict. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3198) Apache Solr to adhere to Apache Project Branding Requirements
[ https://issues.apache.org/jira/browse/SOLR-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221662#comment-13221662 ] Yonik Seeley commented on SOLR-3198: I'd rather not add TM to the logo... it's not actually required (and the version attached here is blurry in any case). Apache Solr to adhere to Apache Project Branding Requirements -- Key: SOLR-3198 URL: https://issues.apache.org/jira/browse/SOLR-3198 Project: Solr Issue Type: New Feature Components: documentation Reporter: Lewis John McGibbney Fix For: 3.6, 4.0 Attachments: SOLR-3198.patch, Solr_tm.png The ASF project branding requirements [0] provide guidelines for projects to follow and adhre to. This is a trivial task, so I'll patch the site and upload it. [0] http://www.apache.org/foundation/marks/pmcs.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3180) ChaosMonkey test failures
[ https://issues.apache.org/jira/browse/SOLR-3180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221712#comment-13221712 ] Yonik Seeley commented on SOLR-3180: Failures are *much* less frequent, but I still got one after about 7 hours I think. I saw a commit fail (due to the interrupted exception), but then I later saw the IW.close() succeed (which caused Solr to cap the log file, assuming that everything was in the index). As a result, I just committed a change to the shutdown code to do an explicit commit. ChaosMonkey test failures - Key: SOLR-3180 URL: https://issues.apache.org/jira/browse/SOLR-3180 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Yonik Seeley Handle intermittent failures in the ChaosMonkey tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3191) field exclusion from fl
[ https://issues.apache.org/jira/browse/SOLR-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221713#comment-13221713 ] Yonik Seeley commented on SOLR-3191: +1, looks great Jan! field exclusion from fl --- Key: SOLR-3191 URL: https://issues.apache.org/jira/browse/SOLR-3191 Project: Solr Issue Type: Improvement Reporter: Luca Cavanna Priority: Minor I think it would be useful to add a way to exclude field from the Solr response. If I have for example 100 stored fields and I want to return all of them but one, it would be handy to list just the field I want to exclude instead of the 99 fields for inclusion through fl. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3197) Allow firstSearcher and newSearcher listeners to run in multiple threads
[
https://issues.apache.org/jira/browse/SOLR-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221715#comment-13221715
]
Yonik Seeley commented on SOLR-3197:
The original rational was do we really want to peg more than one CPU with
warmup while we are still serving live traffic?
But some people are using pretty big boxes these days.
Beware some startup code that expects a single threaded executor though - we
can't just switch that w/o other code changes!
See the SolrCore constructor for more details.
Allow firstSearcher and newSearcher listeners to run in multiple threads
Key: SOLR-3197
URL: https://issues.apache.org/jira/browse/SOLR-3197
Project: Solr
Issue Type: Improvement
Reporter: Lance Norskog
SolrCore submits all listeners (firstSearcher and newSearcher) to a java
ExecutorService, but uses a single-threaded one.
line 965 in the trunk:
{code}
SolrCore.java around line 965: final ExecutorService searcherExecutor =
Executors.newSingleThreadExecutor();
line 1280 in the trunk:
SolrCore.java around line 1280 runs first the, and then the first and new
searchers, all with the searcherExecutor object created at line 965.
Would it work if we changed this ExecutorService to a thread pool version?
This seems like it should work:
{code}
java.util.concurrent.Executors.newFixedThreadPool(int nThreads, ThreadFactory
threadFactory);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3182) If there is only one core, let it be the default without specifying a default in solr.xml
[
https://issues.apache.org/jira/browse/SOLR-3182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220999#comment-13220999
]
Yonik Seeley commented on SOLR-3182:
bq. Other than that, does anyone object to committing this?
I haven't thought through the implications, but it could be dicey for
multi-core use.
If you start with two cores open (and maybe even no default core), then close
one core and all of a sudden the other becomes the default?
Perhaps this need for a default core could instead be generalized... some sort
of config option that made the default the first active core (sorted by core
name)?
If there is only one core, let it be the default without specifying a default
in solr.xml
-
Key: SOLR-3182
URL: https://issues.apache.org/jira/browse/SOLR-3182
Project: Solr
Issue Type: Improvement
Components: multicore
Affects Versions: 3.6, 4.0
Reporter: Russell Black
Priority: Minor
Labels: patch
Attachments: SOLR-3182-default-core.patch
Original Estimate: 10m
Remaining Estimate: 10m
Our particular need for this is as follows. We operate in a sharded
environment with one core per server. Each shard also acts as a collator.
We want to use a hardware load balancer to choose which shard will do the
collation for each query. But in order to do that, each server's single core
would have to carry the same name so that it could be accessed by the same
url across servers. However we name the cores by their shard number
(query0,query1,...) because it parallels with the way we name our
indexing/master cores (index0, index1,...). This naming convention also
gives us the flexibility of moving to a multicore environment in the future
without having to rename the cores, although admittedly that would complicate
load balancing.
In a system with a large number of shards and the anticipation of adding more
going forward, setting a defaultCoreName attribute in each solr.xml file
becomes inconvenient, especially since there is no Solr admin API for setting
defaultCoreName. It would have to be done by hand or with some automated
tool we would write in house. Even if there were an API, logically it seems
unnecessary to have to declare the only core to be the default.
Fortunately this behavior can be implemented with the following simple patch:
{code}
Index: solr/core/src/java/org/apache/solr/core/CoreContainer.java
===
--- solr/core/src/java/org/apache/solr/core/CoreContainer.java
(revision 1295229)
+++ solr/core/src/java/org/apache/solr/core/CoreContainer.java
(working copy)
@@ -870,6 +870,10 @@
}
private String checkDefault(String name) {
+// if there is only one core, let it be the default without specifying a
default in solr.xml
+if (defaultCoreName.trim().length() == 0 name.trim().length() == 0
cores.size() == 1) {
+ return cores.values().iterator().next().getName();
+}
return name.length() == 0 || defaultCoreName.equals(name) ||
name.trim().length() == 0 ? : name;
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3182) If there is only one core, let it be the default without specifying a default in solr.xml
[
https://issues.apache.org/jira/browse/SOLR-3182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221054#comment-13221054
]
Yonik Seeley commented on SOLR-3182:
bq. It simply becomes accessible by an additional URL when it becomes the only
core.
But then the reverse case could also be jarring when someone is able to access
a core by virtue of it being default, and then that ability is suddenly removed
when a new core is created.
If there is only one core, let it be the default without specifying a default
in solr.xml
-
Key: SOLR-3182
URL: https://issues.apache.org/jira/browse/SOLR-3182
Project: Solr
Issue Type: Improvement
Components: multicore
Affects Versions: 3.6, 4.0
Reporter: Russell Black
Priority: Minor
Labels: patch
Attachments: SOLR-3182-default-core.patch
Original Estimate: 10m
Remaining Estimate: 10m
Our particular need for this is as follows. We operate in a sharded
environment with one core per server. Each shard also acts as a collator.
We want to use a hardware load balancer to choose which shard will do the
collation for each query. But in order to do that, each server's single core
would have to carry the same name so that it could be accessed by the same
url across servers. However we name the cores by their shard number
(query0,query1,...) because it parallels with the way we name our
indexing/master cores (index0, index1,...). This naming convention also
gives us the flexibility of moving to a multicore environment in the future
without having to rename the cores, although admittedly that would complicate
load balancing.
In a system with a large number of shards and the anticipation of adding more
going forward, setting a defaultCoreName attribute in each solr.xml file
becomes inconvenient, especially since there is no Solr admin API for setting
defaultCoreName. It would have to be done by hand or with some automated
tool we would write in house. Even if there were an API, logically it seems
unnecessary to have to declare the only core to be the default.
Fortunately this behavior can be implemented with the following simple patch:
{code}
Index: solr/core/src/java/org/apache/solr/core/CoreContainer.java
===
--- solr/core/src/java/org/apache/solr/core/CoreContainer.java
(revision 1295229)
+++ solr/core/src/java/org/apache/solr/core/CoreContainer.java
(working copy)
@@ -870,6 +870,10 @@
}
private String checkDefault(String name) {
+// if there is only one core, let it be the default without specifying a
default in solr.xml
+if (defaultCoreName.trim().length() == 0 name.trim().length() == 0
cores.size() == 1) {
+ return cores.values().iterator().next().getName();
+}
return name.length() == 0 || defaultCoreName.equals(name) ||
name.trim().length() == 0 ? : name;
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221069#comment-13221069 ] Yonik Seeley commented on LUCENE-3795: -- While it's fair game to ask if something barely used like commons-lang can be removed, it doesn't seem like the other things should be blockers to getting this committed. As long as spatial4j.jar is properly licensed, where that project should live is a different issue and has nothing to do with this. If we didn't know any of the authors of this jar, we wouldn't be having the discussion at all. bq. We all agreed modules should be treated like lucene core I don't recall that - modules are shared code by both Lucene and Solr. There's a desire to not pull in all of solr in a module of course, but dependencies on other jars or other modules should be fine. Replace spatial contrib module with LSP's spatial-lucene module --- Key: LUCENE-3795 URL: https://issues.apache.org/jira/browse/LUCENE-3795 Project: Lucene - Java Issue Type: New Feature Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been in development for approximately 1 year by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready. LSP is here: http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/. I'll add more comments to prevent the issue description from being too long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3180) ChaosMonkey test failures
[ https://issues.apache.org/jira/browse/SOLR-3180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221300#comment-13221300 ] Yonik Seeley commented on SOLR-3180: Just checked in a fix for this as well as a test that recovers from more than one tlog at startup. ChaosMonkey test failures - Key: SOLR-3180 URL: https://issues.apache.org/jira/browse/SOLR-3180 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Yonik Seeley Handle intermittent failures in the ChaosMonkey tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3173) Database semantics - insert and update
[ https://issues.apache.org/jira/browse/SOLR-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13219175#comment-13219175 ] Yonik Seeley commented on SOLR-3173: bq. I belive you are already commenting on the related Jira issue that I havnt created yet Optimistic locking as a superset to insert/update: What I already had in mind: - update only a specific version of the document by specifying it's exact version: _version_=12345 - add a document only if it doesn't already exist (i.e. insert): _version_=-1 - add a document regardless: don't specify a version So now that I look at it again, it looks like what's missing is your UPDATE semantics which would only replace the record if it already existed (a weaker form of the first case... any positive version is OK). But I really wonder how useful those semantics are (only add a doc if it's overwriting an existing doc, regardless of what version or what data it contains?) If there are usecases, we certainly should be able to do it. As far as what \_version\_ is, it's new and used for solrcloud to handle reorders of updates to replicas (among other things). The leader shard decides what the version of a document should be (versions only increase), and forwards the doc with the version to the replicas. If a replica receives the same doc with a lower version, it knows that it can safely drop it because it already has a newer version. Database semantics - insert and update -- Key: SOLR-3173 URL: https://issues.apache.org/jira/browse/SOLR-3173 Project: Solr Issue Type: New Feature Components: update Affects Versions: 3.5 Environment: All Reporter: Per Steffensen Assignee: Per Steffensen Labels: RDBMS, insert, nosql, uniqueKey, update Fix For: 4.0 Original Estimate: 168h Remaining Estimate: 168h In order increase the ability of Solr to be used as a NoSql database (lots of concurrent inserts, updates, deletes and queries in the entire lifetime of the index) instead of just a search index (first: everything indexed (in one thread), after: only queries), I would like Solr to support the following features inspired by RDBMSs and other NoSql databases. * Given a solr-core with a schema containing a uniqueKey-field uniqueField and a document Dold, when trying to INSERT a new document Dnew where Dold.uniqueField is equal to Dnew.uniqueField, then I want a DocumentAlredyExists error. If no such document Dold exists I want Dnew indexed into the solr-core. * Given a solr-core with a schema containing a uniqueKey-field uniqueField and a document Dold, when trying to UPDATE a document Dnew where Dold.uniqueField is equal to Dnew.uniqueField I want Dold deleted from and Dnew added to the index (just as it is today).If no such document Dold exists I want nothing to happen (Dnew is not added to the index) The essence of this issue is to be able to state your intent (insert or update) and have slightly different semantics (from each other and the existing update) depending on you intent. The functionality provided by this issue is only really meaningfull when you run with updateLog activated. This issue might be solved more or less at the same time as SOLR-3178, and only one single SVN patch might be given to cover both issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3179) handle commit failures
[ https://issues.apache.org/jira/browse/SOLR-3179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13219195#comment-13219195 ] Yonik Seeley commented on SOLR-3179: Specific to a commit failure, we probably shouldn't try to do peersync or log replay or anything, but should go straight to replication? One issue I've hit in the tests is that a commit may fail currently, but updates continue to succeed because they are simply buffered in memory. Seems like it would be a good idea of we could recognize that we are in real trouble ASAP. handle commit failures -- Key: SOLR-3179 URL: https://issues.apache.org/jira/browse/SOLR-3179 Project: Solr Issue Type: Improvement Reporter: Yonik Seeley We may be able to be more proactive about handing some failures (like a commit failure). In cloud mode, we should probably mark ourselves down and put ourselves in recovery mode? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3180) ChaosMonkey test failures
[ https://issues.apache.org/jira/browse/SOLR-3180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13219246#comment-13219246 ] Yonik Seeley commented on SOLR-3180: We've come a long way and the monkey has uncovered a number of bugs that we've fixed and is helping to make a really solid solution. I just uncovered another one having to do with races on shutdown. When we kill the Jetty instance, it can cause an interrupted exception that closes the underlying NIO files under lucene. If a commit is happening concurrently then what can happen is that we can end up with more than one unfinished transaction log. We call preCommit, which move the current tlog to prevTlog. The commit fails, but concurrently other updates are coming in and they cause a new tlog to be created. Even other updates coming in after this point can also succeed since they are simply buffered in memory by the IW. ChaosMonkey test failures - Key: SOLR-3180 URL: https://issues.apache.org/jira/browse/SOLR-3180 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Yonik Seeley Handle intermittent failures in the ChaosMonkey tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3140) Make omitNorms default for all numeric field types
[ https://issues.apache.org/jira/browse/SOLR-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13219631#comment-13219631 ] Yonik Seeley commented on SOLR-3140: Although length normalization on StringType fields *could* be useful, we should think about the best default. The user can always switch it of course. But on the other hand, the string type defined by the example schema already specifies omitNorms=true, and as long as we don't change that I don't think the default for the java class is a big deal either way. Keeping it the same has the slight benefit of making it easier for the minority of people who defined their own string fields and purposely wanted norms. Make omitNorms default for all numeric field types -- Key: SOLR-3140 URL: https://issues.apache.org/jira/browse/SOLR-3140 Project: Solr Issue Type: Improvement Components: Schema and Analysis Reporter: Jan Høydahl Labels: omitNorms Fix For: 4.0 Attachments: SOLR-3140.patch Today norms are enabled for all Solr field types by default, while in Lucene norms are omitted for the numeric types. Propose to make the Solr defaults the same as in Lucene, so that if someone occasionally wants index-side boost for a numeric field type they must say omitNorms=false. This lets us simplify the example schema too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3173) Database semantics - insert and update
[ https://issues.apache.org/jira/browse/SOLR-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218571#comment-13218571 ] Yonik Seeley commented on SOLR-3173: Here's an idea: we already have a _version_ field for documents (that can also be passed in the URL for other things like deletes), we simply reuse that. Positive versions are adds, negative versions are deletes. If a document comes into the shad leader and already has a _version_, then it's considered an optimistic concurrency request... the document should be replacing an existing document with exactly that version. If the _version_ passed is negative, then the document should not already exist (all deleted documents are considered equal). No new config needed, and optimistic concurrency can be selected on a per-request basis to the same handler. Database semantics - insert and update -- Key: SOLR-3173 URL: https://issues.apache.org/jira/browse/SOLR-3173 Project: Solr Issue Type: New Feature Components: update Affects Versions: 3.5 Environment: All Reporter: Per Steffensen Assignee: Per Steffensen Labels: RDBMS, insert, nosql, uniqueKey, update Fix For: 4.0 Original Estimate: 168h Remaining Estimate: 168h In order increase the ability of Solr to be used as a NoSql database (lots of concurrent inserts, updates, deletes and queries in the entire lifetime of the index) instead of just a search index (first: everything indexed (in one thread), after: only queries), I would like Solr to support the following features inspired by RDBMSs and other NoSql databases. * Given a solr-core with a schema containing a uniqueKey-field uniqueField and a document Dold, when trying to INSERT a new document Dnew where Dold.uniqueField is equal to Dnew.uniqueField, then I want a DocumentAlredyExists error. If no such document Dold exists I want Dnew indexed into the solr-core. * Given a solr-core with a schema containing a uniqueKey-field uniqueField and a document Dold, when trying to UPDATE a document Dnew where Dold.uniqueField is equal to Dnew.uniqueField I want Dold deleted from and Dnew added to the index (just as it is today).If no such document Dold exists I want nothing to happen (Dnew is not added to the index) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
