[JENKINS] Lucene-Artifacts-5.3 - Build # 6 - Failure
Build: https://builds.apache.org/job/Lucene-Artifacts-5.3/6/ No tests ran. Build Log: [...truncated 12829 lines...] BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.3/lucene/build.xml:393: java.net.ConnectException: Connection timed out at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:579) at java.net.Socket.connect(Socket.java:528) at sun.net.NetworkClient.doConnect(NetworkClient.java:180) at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) at sun.net.www.http.HttpClient.init(HttpClient.java:211) at sun.net.www.http.HttpClient.New(HttpClient.java:308) at sun.net.www.http.HttpClient.New(HttpClient.java:326) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:996) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:932) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:850) at org.apache.tools.ant.taskdefs.Get$GetThread.openConnection(Get.java:660) at org.apache.tools.ant.taskdefs.Get$GetThread.get(Get.java:579) at org.apache.tools.ant.taskdefs.Get$GetThread.run(Get.java:569) Total time: 7 minutes 7 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Sending artifact delta relative to Lucene-Artifacts-5.3 #5 Archived 13 artifacts Archive block size is 32768 Received 1229 blocks and 139470122 bytes Compression is 22.4% Took 1 min 1 sec Publishing Javadoc Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-5.3 - Build # 8 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.3/8/ 7 tests failed. REGRESSION: org.apache.solr.TestDistributedSearch.test Error Message: Captured an uncaught exception in thread: Thread[id=74293, name=Thread-69129, state=RUNNABLE, group=TGRP-TestDistributedSearch] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=74293, name=Thread-69129, state=RUNNABLE, group=TGRP-TestDistributedSearch] at __randomizedtesting.SeedInfo.seed([CE256CC33CAC869:84B669169D36A591]:0) Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:36086/dau/g/collection1: java.lang.NullPointerException at org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:102) at org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:748) at org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:731) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:410) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068) at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:210) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:106) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83) at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) at org.eclipse.jetty.server.Server.handle(Server.java:499) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) at java.lang.Thread.run(Thread.java:745) at __randomizedtesting.SeedInfo.seed([CE256CC33CAC869]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958) at org.apache.solr.TestDistributedSearch$1.run(TestDistributedSearch.java:1110) REGRESSION: org.apache.solr.cloud.AsyncCallRequestStatusResponseTest.testAsyncCallStatusResponse Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([CE256CC33CAC869:56E333201DF045B0]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.cloud.AsyncCallRequestStatusResponseTest.testAsyncCallStatusResponse(AsyncCallRequestStatusResponseTest.java:38) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at
[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701038#comment-14701038
]
Karl Wright commented on LUCENE-6699:
-
[~mikemccand]: I take part of this back.
The Bkd query code looks in part like this:
{code}
case GeoArea.OVERLAPS:
// They do overlap but neither
contains the other:
//System.out.println(
crosses1);
return
BKD3DTreeReader.Relation.CROSSES;
case GeoArea.WITHIN:
// Cell fully contains the shape:
//System.out.println(
crosses2);
return
BKD3DTreeReader.Relation.CROSSES;
{code}
So, you are already treating WITHIN and OVERLAPS the same.
As for the case where, instead of CONTAINS, an OVERLAPS result may occur, I
believe that will simply mean that the algorithm needs to work harder than it
strictly should, in that case. Please tell me if I am wrong! (FWIW, there
aren't any current examples of this behavior that I know of, other than to use
GeoCompositeShape to glue together other shapes.)
So I guess what I'm saying is that we *should* be able to get bkd working
without changing geo3d's code further, unless there are other bugs.
FWIW, this is why the problem hasn't been noted until now; the spatial4j
definitions are loose enough to allow the current degree of behavior. Given
the difficulty of changing that behavior, I may simply change the comments, if
we can get bkd working.
Integrate lat/lon BKD and spatial3d
---
Key: LUCENE-6699
URL: https://issues.apache.org/jira/browse/LUCENE-6699
Project: Lucene - Core
Issue Type: New Feature
Reporter: Michael McCandless
Assignee: Michael McCandless
Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch,
LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch
I'm opening this for discussion, because I'm not yet sure how to do
this integration, because of my ignorance about spatial in general and
spatial3d in particular :)
Our BKD tree impl is very fast at doing lat/lon shape intersection
(bbox, polygon, soon distance: LUCENE-6698) against previously indexed
points.
I think to integrate with spatial3d, we would first need to record
lat/lon/z into doc values. Somewhere I saw discussion about how we
could stuff all 3 into a single long value with acceptable precision
loss? Or, we could use BinaryDocValues? We need all 3 dims available
to do the fast per-hit query time filtering.
But, second: what do we index into the BKD tree? Can we just index
earth surface lat/lon, and then at query time is spatial3d able to
give me an enclosing surface lat/lon bbox for a 3d shape? Or
... must we index all 3 dimensions into the BKD tree (seems like this
could be somewhat wasteful)?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7939) Result Grouping: Number of results in group is not according to specs
Esther Goldbraich created SOLR-7939: --- Summary: Result Grouping: Number of results in group is not according to specs Key: SOLR-7939 URL: https://issues.apache.org/jira/browse/SOLR-7939 Project: Solr Issue Type: Bug Components: search, SolrCloud Affects Versions: 4.7.1 Reporter: Esther Goldbraich When using result grouping (group=true), Solr specs state the following about the rows and group.limit params: rows - The number of groups to return. group.limit - Number of rows to return in each group. We are using Solr cloud with a single collection and 64 shards. When grouping by field (i.e. using the group.field parameter), the behavior is as expected. However, when grouping by query (using group.query), the number of documents inside each group is affected by the rows param, instead of the group.limit param. This is different than what is mentioned in the specs. Moreover, when switching to a non-sharded environment (64 collections, 1 shard per collection), the behavior is different, and the number of docs inside each group is affected by the group.query param, as expected. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] 5.3.0 RC2
Thanks everyone! The vote for 5.3.0 RC2 has now passed. I shall start the process of publishing and releasing this. On Tue, Aug 18, 2015 at 10:53 AM, david.w.smi...@gmail.com david.w.smi...@gmail.com wrote: +1 (Java 7) SUCCESS! [1:02:40.331020] -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7884) Omit reverse lookups in SystemInfoHandler
[
https://issues.apache.org/jira/browse/SOLR-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14700800#comment-14700800
]
Robert Krüger commented on SOLR-7884:
-
Sorry, my bad. I didn't read SOLR-5043. That would work perfectly in my case as
I don't need the system info at all. Thanks for pointing me to that again.
Omit reverse lookups in SystemInfoHandler
-
Key: SOLR-7884
URL: https://issues.apache.org/jira/browse/SOLR-7884
Project: Solr
Issue Type: Improvement
Affects Versions: 5.2.1
Reporter: Robert Krüger
Attachments: SOLR-7884.patch
The method SystemInfoHandler.init contains this code:
{code:java}
try {
InetAddress addr = InetAddress.getLocalHost();
hostname = addr.getCanonicalHostName();
} catch (UnknownHostException e) {
//default to null
}
}
{code}
The call to getCanonicalHostName triggers a DNS reverse lookup, that on Mac
OSX times out after 30 seconds if the current network setup has a problem
with reverse lookup and then returns the IP address as host name. In our
product this leads to a hang of 2x30 seconds (one for the SystemInfoHandler
of the container and another one for that of the core) during startup under
these conditions. Unfortunately I have found no way to make this reproducible
by simulating it as it depends on local network config, os and whatever else.
As Solr is shipped bundled with a desktop application, there is currently no
workaround because the user network configuration is beyond our reach.
The suggested fix for this is to replace the call to getCanonicalHostName by
one to getHostName(), which is done for exactly this purpose (obtaining a
host string for logging) in the popular Logback framework (see
http://logback.qos.ch/xref/ch/qos/logback/core/util/ContextUtil.html, how
they do it).
Otherwise Solr has been working perfectly in this setup (bundled with a
desktop app) for a long time and it would be great to remove that last
obstacle to make it a nicer citizen bundlingwise.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7940) [CollectionAPI] Frequent Cluster Status timeout
Stephan Lagraulet created SOLR-7940:
---
Summary: [CollectionAPI] Frequent Cluster Status timeout
Key: SOLR-7940
URL: https://issues.apache.org/jira/browse/SOLR-7940
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.10.2
Environment: Ubuntu on Azure
Reporter: Stephan Lagraulet
Very often we have a timeout when we call
http://server2:8080/solr/admin/collections?action=CLUSTERSTATUSwt=json
{code}
{responseHeader:
{status: 500,
QTime: 180100},
error:
{msg: CLUSTERSTATUS the collection time out:180s,
trace: org.apache.solr.common.SolrException: CLUSTERSTATUS the collection
time out:180s\n\tat
org.apache.solr.handler.admin.CollectionsHandler.handleResponse(CollectionsHandler.java:368)\n\tat
org.apache.solr.handler.admin.CollectionsHandler.handleResponse(CollectionsHandler.java:320)\n\tat
org.apache.solr.handler.admin.CollectionsHandler.handleClusterStatus(CollectionsHandler.java:640)\n\tat
org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:220)\n\tat
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.handleAdminRequest(SolrDispatchFilter.java:729)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:267)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)\n\tat
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1338)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)\n\tat
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)\n\tat
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)\n\tat
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111)\n\tat
org.eclipse.jetty.server.Server.handle(Server.java:350)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944)\n\tat
org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:630)\n\tat
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230)\n\tat
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:77)\n\tat
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:606)\n\tat
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:46)\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:603)\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:538)\n\tat
java.lang.Thread.run(Thread.java:745)\n,
code: 500}}
{code}
The cluster has 3 SolR nodes with 6 small collections replicated on all nodes.
We were using this api to monitor cluster state but it was failing every 10
minutes. We switched by using ZkStateReader in CloudSolrServer and it has been
working for a day without problems.
Is there a kind of deadlock as this call was been made on the three nodes
concurrently?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1898) Improved reporting of exceptions during indexing
[
https://issues.apache.org/jira/browse/SOLR-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-1898:
--
Labels: newdev (was: )
Reviving old issue. These ideas make sense (cannot remember if they perhaps are
implemented already). Should be simple for newbies to attempt too, tagging as
newdev
Improved reporting of exceptions during indexing
Key: SOLR-1898
URL: https://issues.apache.org/jira/browse/SOLR-1898
Project: Solr
Issue Type: Improvement
Reporter: Grant Ingersoll
Labels: newdev
Recently indexing some data where I had mismatched types going in (schema was
an int, I was sending in a float) and got:
{code}
Apr 30, 2010 3:48:46 PM org.apache.solr.common.SolrException log
SEVERE: java.lang.NumberFormatException: For input string: 0.0
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:458)
at java.lang.Integer.parseInt(Integer.java:499)
at org.apache.solr.schema.TrieField.createField(TrieField.java:426)
{code}
I think our indexing exception handling needs to add at least two things (we
also need per document handling of errors during batch, but that is covered
by SOLR-445, see also SOLR-482)
1. If there was an error creating the field, the exception should specify
what the field name is.
2. All document exceptions should, if there is a unique key, report the
unique key of the document that failed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1866) Test bug - JettyWebappTest: plugin classes do not have access to webapp libs
[ https://issues.apache.org/jira/browse/SOLR-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14700865#comment-14700865 ] Jan Høydahl commented on SOLR-1866: --- Still an issue? Test bug - JettyWebappTest: plugin classes do not have access to webapp libs Key: SOLR-1866 URL: https://issues.apache.org/jira/browse/SOLR-1866 Project: Solr Issue Type: Bug Reporter: Mark Miller Priority: Minor Attachments: SOLR-1866.patch The JettyWebappTest straddles example and src/webapp in a way that the Plugin classloader's parent WebappClassloader points to src/webapp which has no libs dir. This can cause problems - eg its a problem with the current velocity setup - though the issue has been skirted by removing slf logging references. Probably the best solution is to run off the webapp - but I wonder if its worth depending on building the webapp for tests when all of them don't need it. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-1941) Jetty configuration is faulty with many cores simultaneous requests
[ https://issues.apache.org/jira/browse/SOLR-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl closed SOLR-1941. - Resolution: Cannot Reproduce Closing old issue as cannot reproduce. Since 5 years ago there has been several new Jetty versions and loads of testing and optimization for multiple cores, so this is likely not a bug (anymore). Jetty configuration is faulty with many cores simultaneous requests - Key: SOLR-1941 URL: https://issues.apache.org/jira/browse/SOLR-1941 Project: Solr Issue Type: Bug Affects Versions: 3.1 Reporter: David Smiley There is a problem with the default configuration of Jetty in the Solr trunk release (not present in Solr 1.4 and prior). There is a difference in the jetty configuration which is for the latest Solr to use the QueuedThreadPool (as seen in jetty.xml). Previously, it had used a BoundedThreadPool implementation that I've heard is considered deprecated presently. I have a multi-core setup where Jetty is serving up lots of Solr cores 9+ and when our client does a distributed search (3 of them at a time actually), it triggers a condition in which the query takes 50 plus seconds to respond. During this time, the machine is effectively idle, seemingly waiting for something. To fix this, go back to the former BoundedThreadPool implementation or don't use Jetty. FWIW this has triggered us to swtich to Tomcat. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14700857#comment-14700857 ] Karl Wright commented on LUCENE-6699: - [~mikemccand]: In order to reliably distinguish between the case of an edge just touching a shape and actually crossing into it, which is what I need here, I need to count the number of crossings per edge. This is fundamentally easy to do, for a single edge. However, there are quite a number of downstream complications, because shapes include a number of edges, not just one, and we have to put it all together. For example, if one shape happens to go through an endpoint where two edges intersect, it should really count as one intersection, not two. Making matters more complicated, composite shapes may consist of simple shapes that overlap and thus the algorithm will be even more fraught and need correspondingly more thought. The upshot of this is that the infrastructure I currently have in place needs a substantial upgrade in order to be able to reliably distinguish WITHIN from OVERLAP in the corner case where the shape just abuts the solid. This will take me a couple of days, most likely. Unfortunately, there's also a corner case with composite shapes where OVERLAP may be returned instead of CONTAINS, so this clearly *has* to be fixed for BKD to work correctly for all shapes. So I apologize for the delay. Stay tuned. Integrate lat/lon BKD and spatial3d --- Key: LUCENE-6699 URL: https://issues.apache.org/jira/browse/LUCENE-6699 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Assignee: Michael McCandless Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch I'm opening this for discussion, because I'm not yet sure how to do this integration, because of my ignorance about spatial in general and spatial3d in particular :) Our BKD tree impl is very fast at doing lat/lon shape intersection (bbox, polygon, soon distance: LUCENE-6698) against previously indexed points. I think to integrate with spatial3d, we would first need to record lat/lon/z into doc values. Somewhere I saw discussion about how we could stuff all 3 into a single long value with acceptable precision loss? Or, we could use BinaryDocValues? We need all 3 dims available to do the fast per-hit query time filtering. But, second: what do we index into the BKD tree? Can we just index earth surface lat/lon, and then at query time is spatial3d able to give me an enclosing surface lat/lon bbox for a 3d shape? Or ... must we index all 3 dimensions into the BKD tree (seems like this could be somewhat wasteful)? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-1864) Master/Slave replication causes tomcat to be unresponsive on slave till replication is being done.
[ https://issues.apache.org/jira/browse/SOLR-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl closed SOLR-1864. - Resolution: Duplicate Closing as duplicate. If you believe this is not correct, please re-open and provide more information on the issue. Master/Slave replication causes tomcat to be unresponsive on slave till replication is being done. -- Key: SOLR-1864 URL: https://issues.apache.org/jira/browse/SOLR-1864 Project: Solr Issue Type: Bug Components: replication (java) Affects Versions: 1.5 Environment: Centos 5.2, Tomcat5, java version 1.6.0 OpenJDK Runtime Environment (build 1.6.0-b09) OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode) Reporter: Marcin Hi guys, I have found a strange behaviour on tomcat5, centos 5.2. While replication is being done ( million rows) tomcat5 seems to be unresponsive till its finished. Please help cheers, /Marcin -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (LUCENE-2376) java.lang.OutOfMemoryError:Java heap space
[ https://issues.apache.org/jira/browse/LUCENE-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl closed LUCENE-2376. --- Resolution: Invalid Closing old inactive issue which seemed to be a usage problem.´ Please re-open if you feel there is a bug in Lucene that needs fixing :) java.lang.OutOfMemoryError:Java heap space -- Key: LUCENE-2376 URL: https://issues.apache.org/jira/browse/LUCENE-2376 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 2.9.1 Environment: Windows Reporter: Shivender Devarakonda Attachments: CheckIndex_JavaHeapOOM.txt, CheckIndex_PermGenSpaceOOM.txt, InfoStreamOutput.txt I see an OutOfMemory error in our product and it is happening when we have some data objects on which we built the index. I see the following OutOfmemory error, this is happening after we call Indexwriter.optimize(): 4/06/10 02:03:42.160 PM PDT [ERROR] [Lucene Merge Thread #12] In thread Lucene Merge Thread #12 and the message is org.apache.lucene.index.MergePolicy$MergeException: java.lang.OutOfMemoryError: Java heap space 4/06/10 02:03:42.207 PM PDT [VERBOSE] [Lucene Merge Thread #12] [Manager] Uncaught Exception in thread Lucene Merge Thread #12 org.apache.lucene.index.MergePolicy$MergeException: java.lang.OutOfMemoryError: Java heap space at org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:351) at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:315) Caused by: java.lang.OutOfMemoryError: Java heap space at java.util.HashMap.resize(HashMap.java:462) at java.util.HashMap.addEntry(HashMap.java:755) at java.util.HashMap.put(HashMap.java:385) at org.apache.lucene.index.FieldInfos.addInternal(FieldInfos.java:256) at org.apache.lucene.index.FieldInfos.read(FieldInfos.java:366) at org.apache.lucene.index.FieldInfos.init(FieldInfos.java:71) at org.apache.lucene.index.SegmentReader$CoreReaders.init(SegmentReader.java:116) at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:638) at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:608) at org.apache.lucene.index.IndexWriter$ReaderPool.get(IndexWriter.java:686) at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4979) at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:4614) at org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:235) at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:291) 4/06/10 02:03:42.895 PM PDT [ERROR] this writer hit an OutOfMemoryError; cannot complete optimize -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-1631) NPE's reported from QueryComponent.mergeIds
[ https://issues.apache.org/jira/browse/SOLR-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl closed SOLR-1631. - Resolution: Cannot Reproduce Closing old issue as Cannot Reproduce. Tons of edits to that part of the code since. If anyone have encountered this in recent versions, please re-open this issue with attached stack trace. NPE's reported from QueryComponent.mergeIds --- Key: SOLR-1631 URL: https://issues.apache.org/jira/browse/SOLR-1631 Project: Solr Issue Type: Bug Components: search Reporter: Hoss Man Multiple reports of QueryComponent.mergeIds occasionally throwing NPE... http://markmail.org/message/aqzaaphbuow4sa5o http://old.nabble.com/NullPointerException-thrown-during-updates-to-index-to26613309.html#a26613309 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_51) - Build # 13646 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13646/ Java: 64bit/jdk1.8.0_51 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.HttpPartitionTest Error Message: ObjectTracker found 1 object(s) that were not released!!! [TransactionLog] Stack Trace: java.lang.AssertionError: ObjectTracker found 1 object(s) that were not released!!! [TransactionLog] at __randomizedtesting.SeedInfo.seed([48AAE2F144024F8]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:236) at sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 10438 lines...] [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest [junit4] 2 Creating dataDir: /home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.HttpPartitionTest_48AAE2F144024F8-001/init-core-data-001 [junit4] 2 748343 INFO (SUITE-HttpPartitionTest-seed#[48AAE2F144024F8]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: / [junit4] 2 748345 INFO (TEST-HttpPartitionTest.test-seed#[48AAE2F144024F8]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2 748345 INFO (Thread-2478) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2 748345 INFO (Thread-2478) [] o.a.s.c.ZkTestServer Starting server [junit4] 2 748445 INFO (TEST-HttpPartitionTest.test-seed#[48AAE2F144024F8]) [] o.a.s.c.ZkTestServer start zk server on port:52110 [junit4] 2 748446 INFO (TEST-HttpPartitionTest.test-seed#[48AAE2F144024F8]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2 748446 INFO (TEST-HttpPartitionTest.test-seed#[48AAE2F144024F8]) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2 748448 INFO (zkCallback-1700-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@ab28106 name:ZooKeeperConnection Watcher:127.0.0.1:52110 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2 748448 INFO (TEST-HttpPartitionTest.test-seed#[48AAE2F144024F8]) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2 748448 INFO (TEST-HttpPartitionTest.test-seed#[48AAE2F144024F8]) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2 748448 INFO (TEST-HttpPartitionTest.test-seed#[48AAE2F144024F8]) [] o.a.s.c.c.SolrZkClient makePath: /solr [junit4] 2 748450 INFO
[jira] [Comment Edited] (SOLR-7884) Omit reverse lookups in SystemInfoHandler
[
https://issues.apache.org/jira/browse/SOLR-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14700800#comment-14700800
]
Robert Krüger edited comment on SOLR-7884 at 8/18/15 6:49 AM:
--
Sorry, my bad. I didn't read SOLR-5043. The first proposed fix with the
background thread would work perfectly in my case as I don't care about the
system info at all. I am not sure if the second one would work as I do not know
under which circumstances the SystemInfoHandler is actually used. Just delaying
the hang until after application startup would actually make matters worse for
my scenario. Waiting for an app to start up slowly is one thing. Having the app
hang unexpectedly after it has started would make it look seriously broken.
was (Author: rmk_apache):
Sorry, my bad. I didn't read SOLR-5043. That would work perfectly in my case as
I don't need the system info at all. Thanks for pointing me to that again.
Omit reverse lookups in SystemInfoHandler
-
Key: SOLR-7884
URL: https://issues.apache.org/jira/browse/SOLR-7884
Project: Solr
Issue Type: Improvement
Affects Versions: 5.2.1
Reporter: Robert Krüger
Attachments: SOLR-7884.patch
The method SystemInfoHandler.init contains this code:
{code:java}
try {
InetAddress addr = InetAddress.getLocalHost();
hostname = addr.getCanonicalHostName();
} catch (UnknownHostException e) {
//default to null
}
}
{code}
The call to getCanonicalHostName triggers a DNS reverse lookup, that on Mac
OSX times out after 30 seconds if the current network setup has a problem
with reverse lookup and then returns the IP address as host name. In our
product this leads to a hang of 2x30 seconds (one for the SystemInfoHandler
of the container and another one for that of the core) during startup under
these conditions. Unfortunately I have found no way to make this reproducible
by simulating it as it depends on local network config, os and whatever else.
As Solr is shipped bundled with a desktop application, there is currently no
workaround because the user network configuration is beyond our reach.
The suggested fix for this is to replace the call to getCanonicalHostName by
one to getHostName(), which is done for exactly this purpose (obtaining a
host string for logging) in the popular Logback framework (see
http://logback.qos.ch/xref/ch/qos/logback/core/util/ContextUtil.html, how
they do it).
Otherwise Solr has been working perfectly in this setup (bundled with a
desktop app) for a long time and it would be great to remove that last
obstacle to make it a nicer citizen bundlingwise.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1963) Improve/Speed up Solr Cloud tests
[ https://issues.apache.org/jira/browse/SOLR-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14700894#comment-14700894 ] Jan Høydahl commented on SOLR-1963: --- Can we close this? Guess cloud tests have improved quite much, and we could open more specific jiras if need be? Improve/Speed up Solr Cloud tests - Key: SOLR-1963 URL: https://issues.apache.org/jira/browse/SOLR-1963 Project: Solr Issue Type: Improvement Reporter: Mark Miller Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7927) Transaction log consumes lot of memory when indexing large documents
[ https://issues.apache.org/jira/browse/SOLR-7927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-7927: Attachment: SOLR-7927.patch Trivial patch attached to use array of 3 * string.length Transaction log consumes lot of memory when indexing large documents Key: SOLR-7927 URL: https://issues.apache.org/jira/browse/SOLR-7927 Project: Solr Issue Type: Bug Components: update Affects Versions: 5.2.1 Reporter: Shalin Shekhar Mangar Fix For: Trunk, 5.4 Attachments: SOLR-7927.patch Solr is started with 1280M heap. ./bin/solr start -m 1280m Indexing a 100MB JSON file (using curl) containing large JSON documents from project Gutenberg fails with OOM but indexing a 549M JSON file containing small documents is indexed just fine. The same 100MB JSON file with the same heap size can be indexed just fine if I disable the transaction log. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (LUCENE-2420) fdx size mismatch overflow causes RuntimeException
[ https://issues.apache.org/jira/browse/LUCENE-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl closed LUCENE-2420. --- Resolution: Not A Problem Closing old inactive issue. If this is still something you think needs fixing, please re-open this issue and provide more information. fdx size mismatch overflow causes RuntimeException Key: LUCENE-2420 URL: https://issues.apache.org/jira/browse/LUCENE-2420 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 3.0.1 Environment: CentOS 5.4 Reporter: Steven Bethard I just saw the following error: java.lang.RuntimeException: after flush: fdx size mismatch: -512764976 docs vs 30257618564 length in bytes of _0.fdx file exists?=true at org.apache.lucene.index.StoredFieldsWriter.closeDocStore(StoredFieldsWriter.java:97) at org.apache.lucene.index.DocFieldProcessor.closeDocStore(DocFieldProcessor.java:51) at org.apache.lucene.index.DocumentsWriter.closeDocStore(DocumentsWriter.java:371) at org.apache.lucene.index.IndexWriter.flushDocStores(IndexWriter.java:1724) at org.apache.lucene.index.IndexWriter.doFlushInternal(IndexWriter.java:3565) at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3491) at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3482) at org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1658) at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1621) at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1585) Note the negative SegmentWriteState.numDocsInStore. I assume this is because Lucene has a limit of 2 ^ 31 - 1 = 2147483647 (sizeof(int)) documents per index, though I couldn't find this documented clearly anywhere. It would have been nice to get this error earlier, back when I exceeded the limit, rather than now, after a bunch of indexing that was apparently doomed to fail. Hence, two suggestions: * State clearly somewhere that the maximum number of documents in a Lucene index is sizeof(int). * Throw an exception when an IndexWriter first exceeds this number rather than only on close. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1554) Passing a callback url to DIH
[ https://issues.apache.org/jira/browse/SOLR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14700883#comment-14700883 ] Jan Høydahl commented on SOLR-1554: --- Reviving old inactive issue. [~szott], have you had a chance to test out the attached patch? Do others have opinion on this feature? Passing a callback url to DIH - Key: SOLR-1554 URL: https://issues.apache.org/jira/browse/SOLR-1554 Project: Solr Issue Type: New Feature Components: contrib - DataImportHandler Affects Versions: 1.5, 3.1 Reporter: Sascha Szott Priority: Minor Attachments: SOLR-1554.patch To provide an easy way to check if an DIH import process is completed (i.e., without having to implement a custom Solr EventListener), it should be possible to pass a callback url along a URL to a DIH request handler. Ideally, the callback should somehow indicate the import operation's result (successful / not successful). This would obviate an additional call of the request handler to get the import operation's result and statistics, respectively. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1975) SolrJ API does not include streaming uploaded data from Java Writer or OutputStream
[ https://issues.apache.org/jira/browse/SOLR-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14700902#comment-14700902 ] Jan Høydahl commented on SOLR-1975: --- [~goksron], can you elaborate on the use case you have for this and if you believe it is still a need? SolrJ API does not include streaming uploaded data from Java Writer or OutputStream --- Key: SOLR-1975 URL: https://issues.apache.org/jira/browse/SOLR-1975 Project: Solr Issue Type: Improvement Components: clients - java Reporter: Lance Norskog Priority: Minor The SolrJ API does not include the ability to upload data from a java.io.Writer or java.io.OutputStream. To do this requires implementing the ContentStream interface. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7941) multivalued params are concatenated when using config API
[
https://issues.apache.org/jira/browse/SOLR-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-7941:
-
Description:
{code}
curl http://localhost:8983/solr/example/config -H
'Content-type:application/json' -d '{
update-requesthandler : {
name: /rh,
class:solr.DumpRequestHandler,
defaults:{ p: [a,b,c ]}
}
}’
{code}
makes {{p}} be a literal string of {{'\[a,b,c]'}} - instead of an array of
strings
was:
{code}
curl http://localhost:8983/solr/example/config -H
'Content-type:application/json' -d '{
update-requesthandler : {
name: “/rh,
class:solr.DumpRequestHandler,
defaults:{ “p: [“a”,”b,c ]}
}
}’
{code}
makes {{p}} be a literal string of {{'\[a,b,c]'}} - instead of an array of
strings
multivalued params are concatenated when using config API
-
Key: SOLR-7941
URL: https://issues.apache.org/jira/browse/SOLR-7941
Project: Solr
Issue Type: Bug
Reporter: Noble Paul
Assignee: Noble Paul
Attachments: SOLR-7941.patch
{code}
curl http://localhost:8983/solr/example/config -H
'Content-type:application/json' -d '{
update-requesthandler : {
name: /rh,
class:solr.DumpRequestHandler,
defaults:{ p: [a,b,c ]}
}
}’
{code}
makes {{p}} be a literal string of {{'\[a,b,c]'}} - instead of an array of
strings
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] 5.3.0 RC2
oops , I shall wait On Tue, Aug 18, 2015 at 4:37 PM, Adrien Grand jpou...@gmail.com wrote: Aren't we supposed to wait for 72 hours after a RC has been uploaded before publishing?[1] [1] https://wiki.apache.org/lucene-java/ReleaseTodo#Publishing On Tue, Aug 18, 2015 at 1:04 PM, Noble Paul noble.p...@gmail.com wrote: Thanks everyone! The vote for 5.3.0 RC2 has now passed. I shall start the process of publishing and releasing this. On Tue, Aug 18, 2015 at 10:53 AM, david.w.smi...@gmail.com david.w.smi...@gmail.com wrote: +1 (Java 7) SUCCESS! [1:02:40.331020] -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1554) Passing a callback url to DIH
[ https://issues.apache.org/jira/browse/SOLR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701230#comment-14701230 ] James Dyer commented on SOLR-1554: -- Just looking at this patch quickly, I see that UrlCallbackListener.java correctly implements the EventListener interface. So if we included this in our distribution, users could just specify this for onImportEnd as shown [on the old wiki page|https://wiki.apache.org/solr/DataImportHandler#EventListeners] . Its not clear to me why the other 3 classes need modification. Also, a unit test would be nice, but arguably a pain to write. Passing a callback url to DIH - Key: SOLR-1554 URL: https://issues.apache.org/jira/browse/SOLR-1554 Project: Solr Issue Type: New Feature Components: contrib - DataImportHandler Affects Versions: 1.5, 3.1 Reporter: Sascha Szott Priority: Minor Attachments: SOLR-1554.patch To provide an easy way to check if an DIH import process is completed (i.e., without having to implement a custom Solr EventListener), it should be possible to pass a callback url along a URL to a DIH request handler. Ideally, the callback should somehow indicate the import operation's result (successful / not successful). This would obviate an additional call of the request handler to get the import operation's result and statistics, respectively. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7941) multivalued params are concatenated when using config API
Noble Paul created SOLR-7941:
Summary: multivalued params are concatenated when using config API
Key: SOLR-7941
URL: https://issues.apache.org/jira/browse/SOLR-7941
Project: Solr
Issue Type: Bug
Reporter: Noble Paul
Assignee: Noble Paul
{code}
curl http://localhost:8983/solr/example/config -H
'Content-type:application/json' -d '{
update-requesthandler : {
name: “/rh,
class:solr.DumpRequestHandler,
defaults:{ “p: [“a”,”b,c ]}
}
}’
{code}
makes {{p}} be a literal string of {{'\[a,b,c]'}} - instead of an array of
strings
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7941) multivalued params are concatenated when using config API
[
https://issues.apache.org/jira/browse/SOLR-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-7941:
-
Attachment: SOLR-7941.patch
a testcase that reproduces this
multivalued params are concatenated when using config API
-
Key: SOLR-7941
URL: https://issues.apache.org/jira/browse/SOLR-7941
Project: Solr
Issue Type: Bug
Reporter: Noble Paul
Assignee: Noble Paul
Attachments: SOLR-7941.patch
{code}
curl http://localhost:8983/solr/example/config -H
'Content-type:application/json' -d '{
update-requesthandler : {
name: “/rh,
class:solr.DumpRequestHandler,
defaults:{ “p: [“a”,”b,c ]}
}
}’
{code}
makes {{p}} be a literal string of {{'\[a,b,c]'}} - instead of an array of
strings
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701092#comment-14701092
]
Karl Wright commented on LUCENE-6699:
-
Here's the proposed comment change to GeoArea:
{code}
/**
* Find the spatial relationship between a shape and the current geo area.
* Note: return value is how the GeoShape relates to the GeoArea, not the
* other way around. For example, if this GeoArea is entirely within the
* shape, then CONTAINS should be returned. If the shape is entirely enclosed
* by this GeoArea, then WITHIN should be returned.
*
* It is permissible to return OVERLAPS instead of WITHIN if the shape
* intersects with the area at even a single point. So, a circle inscribed in
* a rectangle could return either OVERLAPS or WITHIN, depending on
* implementation. It is not permissible to return CONTAINS or DISJOINT
* in this circumstance, however.
*
* Similarly, it is permissible to return OVERLAPS instead of CONTAINS
* under conditions where the shape consists of multiple independent
overlapping
* subshapes, and the area overlaps one of the subshapes. It is not
permissible
* to return WITHIN or DISJOINT in this circumstance, however.
*
* @param shape is the shape to consider.
* @return the relationship, from the perspective of the shape.
*/
public int getRelationship(GeoShape shape);
{code}
Integrate lat/lon BKD and spatial3d
---
Key: LUCENE-6699
URL: https://issues.apache.org/jira/browse/LUCENE-6699
Project: Lucene - Core
Issue Type: New Feature
Reporter: Michael McCandless
Assignee: Michael McCandless
Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch,
LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch
I'm opening this for discussion, because I'm not yet sure how to do
this integration, because of my ignorance about spatial in general and
spatial3d in particular :)
Our BKD tree impl is very fast at doing lat/lon shape intersection
(bbox, polygon, soon distance: LUCENE-6698) against previously indexed
points.
I think to integrate with spatial3d, we would first need to record
lat/lon/z into doc values. Somewhere I saw discussion about how we
could stuff all 3 into a single long value with acceptable precision
loss? Or, we could use BinaryDocValues? We need all 3 dims available
to do the fast per-hit query time filtering.
But, second: what do we index into the BKD tree? Can we just index
earth surface lat/lon, and then at query time is spatial3d able to
give me an enclosing surface lat/lon bbox for a 3d shape? Or
... must we index all 3 dimensions into the BKD tree (seems like this
could be somewhat wasteful)?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] 5.3.0 RC2
Sorry, the vote has not yet passed. On Tue, Aug 18, 2015 at 7:04 AM, Noble Paul noble.p...@gmail.com wrote: Thanks everyone! The vote for 5.3.0 RC2 has now passed. I shall start the process of publishing and releasing this. On Tue, Aug 18, 2015 at 10:53 AM, david.w.smi...@gmail.com david.w.smi...@gmail.com wrote: +1 (Java 7) SUCCESS! [1:02:40.331020] -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] 5.3.0 RC2
Aren't we supposed to wait for 72 hours after a RC has been uploaded before publishing?[1] [1] https://wiki.apache.org/lucene-java/ReleaseTodo#Publishing On Tue, Aug 18, 2015 at 1:04 PM, Noble Paul noble.p...@gmail.com wrote: Thanks everyone! The vote for 5.3.0 RC2 has now passed. I shall start the process of publishing and releasing this. On Tue, Aug 18, 2015 at 10:53 AM, david.w.smi...@gmail.com david.w.smi...@gmail.com wrote: +1 (Java 7) SUCCESS! [1:02:40.331020] -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 3424 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3424/ 1 tests failed. REGRESSION: org.apache.solr.cloud.BasicDistributedZkTest.test Error Message: commitWithin did not work on node: http://127.0.0.1:56271/skreb/collection1 expected:68 but was:67 Stack Trace: java.lang.AssertionError: commitWithin did not work on node: http://127.0.0.1:56271/skreb/collection1 expected:68 but was:67 at __randomizedtesting.SeedInfo.seed([1BCCB1D6C5CE5556:93988E0C6B3238AE]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.solr.cloud.BasicDistributedZkTest.test(BasicDistributedZkTest.java:333) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at
[jira] [Updated] (SOLR-7941) multivalued params are concatenated when using config API
[
https://issues.apache.org/jira/browse/SOLR-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-7941:
-
Attachment: SOLR-7941.patch
fix w/ a testcase
multivalued params are concatenated when using config API
-
Key: SOLR-7941
URL: https://issues.apache.org/jira/browse/SOLR-7941
Project: Solr
Issue Type: Bug
Reporter: Noble Paul
Assignee: Noble Paul
Attachments: SOLR-7941.patch, SOLR-7941.patch
{code}
curl http://localhost:8983/solr/example/config -H
'Content-type:application/json' -d '{
update-requesthandler : {
name: /rh,
class:solr.DumpRequestHandler,
defaults:{ p: [a,b,c ]}
}
}’
{code}
makes {{p}} be a literal string of {{'\[a,b,c]'}} - instead of an array of
strings
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 931 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/931/ 3 tests failed. REGRESSION: org.apache.solr.handler.TestReplicationHandler.doTestStressReplication Error Message: timed out waiting for collection1 startAt time to exceed: Tue Aug 18 18:09:01 MEST 2015 Stack Trace: java.lang.AssertionError: timed out waiting for collection1 startAt time to exceed: Tue Aug 18 18:09:01 MEST 2015 at __randomizedtesting.SeedInfo.seed([E5F76943B73D63E3:3E5C6985B2150A50]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.handler.TestReplicationHandler.watchCoreStartAt(TestReplicationHandler.java:1417) at org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:769) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) FAILED: org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=18660,
Re: A post on the user's list made me wonder about a replace node utility/collections API call
On Tue, Aug 18, 2015, at 06:35 PM, Erick Erickson wrote: As SolrCloud works its way into larger and larger situations, the possibility of a node just failing (hardware fault, somebody spills coffee on it, whatever) increases. Currently to replace the whole node, the best I can come up with is ADDREPLICA/DELETEREPLICA for all the replicas on the node. All the information should be in ZK to allow a command saying something like for every replica on nodeX, make a new one on nodeY. True, the names would be different Worth a JIRA? It could be a Collections API call or a SolrJ utility or even a different script. Or maybe just a utility that would generate the appropriate URLs for someone to submit themselves. I'm not sure there's enough need but thought I'd see what others thought before raising a JIRA. I like the idea. If it were an API, we could then expose it via that UI to allow a known bad node to be decommissioned easily, by looking at the cloud graph. Upayavira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6744) equals methods should compare classes directly, not use instanceof
[
https://issues.apache.org/jira/browse/LUCENE-6744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701688#comment-14701688
]
Edward Ribeiro commented on LUCENE-6744:
My two cents: I have always preferred to use {{instanceof}}, but was unaware of
the potential problems and inconsistencies of using it. :( So, for stir up a
little bit of discussion, I would like let you with two SO links that discuss
this issue in depth:
http://stackoverflow.com/questions/596462/any-reason-to-prefer-getclass-over-instanceof-when-generating-equals
http://stackoverflow.com/questions/27581/what-issues-should-be-considered-when-overriding-equals-and-hashcode-in-java/32223#32223
Best,
eddie
equals methods should compare classes directly, not use instanceof
--
Key: LUCENE-6744
URL: https://issues.apache.org/jira/browse/LUCENE-6744
Project: Lucene - Core
Issue Type: Bug
Reporter: Hoss Man
Labels: newdev
from a 2015-07-12 email to the dev list from Fuxiang Chen...
{noformat}
We have found some inconsistencies in the overriding of the equals() method
in some files with respect to the conforming to the contract structure
based on the Java Specification.
Affected files:
1) ConstValueSource.java
2) DoubleConstValueSource.java
3) FixedBitSet.java
4) GeohashFunction.java
5) LongBitSet.java
6) SpanNearQuery.java
7) StringDistanceFunction.java
8) ValueSourceRangeFilter.java
9) VectorDistanceFunction.java
The above files all uses instanceof in the overridden equals() method in
comparing two objects.
According to the Java Specification, the equals() method must be reflexive,
symmetric, transitive and consistent. In the case of symmetric, it is
stated that x.equals(y) should return true if and only if y.equals(x)
returns true. Using instanceof is asymmetric and is not a valid symmetric
contract.
A more preferred way will be to compare the classes instead. i.e. if
(this.getClass() != o.getClass()).
However, if compiling the source code using JDK 7 and above, and if
developers still prefer to use instanceof, you can make use of the static
methods of Objects such as Objects.equals(this.id, that.id). (Making use of
the static methods of Objects is currently absent in the methods.) It will
be easier to override the equals() method and will ensure that the
overridden equals() method will fulfill the contract rules.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6697) Use 1D KD tree for alternative to postings based numeric range filters
[ https://issues.apache.org/jira/browse/LUCENE-6697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701836#comment-14701836 ] Michael McCandless commented on LUCENE-6697: bq. My Jenkins found a failing seed on branch_5x w/Java8 for TestRangeTree.testAllEqual() This was a fun one to track down :) https://issues.apache.org/jira/browse/LUCENE-6745 is the root cause... Use 1D KD tree for alternative to postings based numeric range filters -- Key: LUCENE-6697 URL: https://issues.apache.org/jira/browse/LUCENE-6697 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 5.3, Trunk Attachments: LUCENE-6697.patch, LUCENE-6697.patch, LUCENE-6697.patch Today Lucene uses postings to index a numeric value at multiple precision levels for fast range searching. It's somewhat costly: each numeric value is indexed with multiple terms (4 terms by default) ... I think a dedicated 1D BKD tree should be more compact and perform better. It should also easily generalize beyond 64 bits to arbitrary byte[], e.g. for LUCENE-5596, but I haven't explored that here. A 1D BKD tree just sorts all values, and then indexes adjacent leaf blocks of size 512-1024 (by default) values per block, and their docIDs, into a fully balanced binary tree. Building the range filter is then just a recursive walk through this tree. It's the same structure we use for 2D lat/lon BKD tree, just with 1D instead. I implemented it as a DocValuesFormat that also writes the numeric tree on the side. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7888) Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a BooleanQuery filter parameter available in Solr
[
https://issues.apache.org/jira/browse/SOLR-7888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arcadius Ahouansou updated SOLR-7888:
-
Attachment: SOLR-7888.patch
Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a
BooleanQuery filter parameter available in Solr
--
Key: SOLR-7888
URL: https://issues.apache.org/jira/browse/SOLR-7888
Project: Solr
Issue Type: New Feature
Components: Suggester
Affects Versions: 5.2.1
Reporter: Arcadius Ahouansou
Assignee: Jan Høydahl
Fix For: 5.4
Attachments: SOLR-7888.patch, SOLR-7888.patch
LUCENE-6464 has introduced a very flexible lookup method that takes as
parameter a BooleanQuery that is used for filtering results.
This ticket is to expose that method to Solr.
This would allow user to do:
{code}
/suggest?suggest=truesuggest.build=truesuggest.q=termsuggest.contextFilterQuery=contexts:tennis
/suggest?suggest=truesuggest.build=truesuggest.q=termsuggest.contextFilterQuery=contexts:golf
AND contexts:football
{code}
etc
Given that the context filtering in currently only implemented by the
{code}AnalyzingInfixSuggester{code} and by the
{code}BlendedInfixSuggester{code}, this initial implementation will support
only these 2 lookup implementations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated LUCENE-6699: Attachment: LUCENE-6699.patch Patch which fixes Mike's tests; it seems like the query implementation is unhappy when the bounds does not start *outside* the area that needs to be searched. Integrate lat/lon BKD and spatial3d --- Key: LUCENE-6699 URL: https://issues.apache.org/jira/browse/LUCENE-6699 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Assignee: Michael McCandless Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch I'm opening this for discussion, because I'm not yet sure how to do this integration, because of my ignorance about spatial in general and spatial3d in particular :) Our BKD tree impl is very fast at doing lat/lon shape intersection (bbox, polygon, soon distance: LUCENE-6698) against previously indexed points. I think to integrate with spatial3d, we would first need to record lat/lon/z into doc values. Somewhere I saw discussion about how we could stuff all 3 into a single long value with acceptable precision loss? Or, we could use BinaryDocValues? We need all 3 dims available to do the fast per-hit query time filtering. But, second: what do we index into the BKD tree? Can we just index earth surface lat/lon, and then at query time is spatial3d able to give me an enclosing surface lat/lon bbox for a 3d shape? Or ... must we index all 3 dimensions into the BKD tree (seems like this could be somewhat wasteful)? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6744) equals methods should compare classes directly, not use instanceof
Hoss Man created LUCENE-6744:
Summary: equals methods should compare classes directly, not use
instanceof
Key: LUCENE-6744
URL: https://issues.apache.org/jira/browse/LUCENE-6744
Project: Lucene - Core
Issue Type: Bug
Reporter: Hoss Man
from a 2015-07-12 email to the dev list from Fuxiang Chen...
{noformat}
We have found some inconsistencies in the overriding of the equals() method
in some files with respect to the conforming to the contract structure
based on the Java Specification.
Affected files:
1) ConstValueSource.java
2) DoubleConstValueSource.java
3) FixedBitSet.java
4) GeohashFunction.java
5) LongBitSet.java
6) SpanNearQuery.java
7) StringDistanceFunction.java
8) ValueSourceRangeFilter.java
9) VectorDistanceFunction.java
The above files all uses instanceof in the overridden equals() method in
comparing two objects.
According to the Java Specification, the equals() method must be reflexive,
symmetric, transitive and consistent. In the case of symmetric, it is
stated that x.equals(y) should return true if and only if y.equals(x)
returns true. Using instanceof is asymmetric and is not a valid symmetric
contract.
A more preferred way will be to compare the classes instead. i.e. if
(this.getClass() != o.getClass()).
However, if compiling the source code using JDK 7 and above, and if
developers still prefer to use instanceof, you can make use of the static
methods of Objects such as Objects.equals(this.id, that.id). (Making use of
the static methods of Objects is currently absent in the methods.) It will
be easier to override the equals() method and will ensure that the
overridden equals() method will fulfill the contract rules.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] 5.3.0 RC2
+1 SUCCESS! [0:51:02.991482] - Mark On Tue, Aug 18, 2015 at 10:19 AM Adrien Grand jpou...@gmail.com wrote: I found a typo in the changelog that looks like my sister is a popular singer but I don't think it's worth a respin. :-) Also Elasticsearch looks happy with this RC. +1 SUCCESS! [1:00:50.650985] On Mon, Aug 17, 2015 at 2:24 PM, Noble Paul noble.p...@gmail.com wrote: hi all, Please vote for the 2nd release candidate for Lucene/Solr 5.3.0 The artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229 You can run the smoke tester directly with this command: python3 -u dev-tools/scripts/smokeTestRelease.py https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/ -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Mark about.me/markrmiller
A post on the user's list made me wonder about a replace node utility/collections API call
As SolrCloud works its way into larger and larger situations, the possibility of a node just failing (hardware fault, somebody spills coffee on it, whatever) increases. Currently to replace the whole node, the best I can come up with is ADDREPLICA/DELETEREPLICA for all the replicas on the node. All the information should be in ZK to allow a command saying something like for every replica on nodeX, make a new one on nodeY. True, the names would be different Worth a JIRA? It could be a Collections API call or a SolrJ utility or even a different script. Or maybe just a utility that would generate the appropriate URLs for someone to submit themselves. I'm not sure there's enough need but thought I'd see what others thought before raising a JIRA. Erick - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6745) RAMInputStream.clone is not thread safe
[ https://issues.apache.org/jira/browse/LUCENE-6745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-6745: --- Attachment: LUCENE-6745.patch Patch w/ test and fix ... Other dir impls seem to be OK. RAMInputStream.clone is not thread safe --- Key: LUCENE-6745 URL: https://issues.apache.org/jira/browse/LUCENE-6745 Project: Lucene - Core Issue Type: Bug Reporter: Michael McCandless Assignee: Michael McCandless Fix For: Trunk, 5.4 Attachments: LUCENE-6745.patch This took some time to track down ... it's the root cause of the RangeTree failures that [~steve_rowe] found at https://issues.apache.org/jira/browse/LUCENE-6697?focusedCommentId=14696999page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14696999 The problem happens when one thread is using the original IndexInput (RAMInputStream) from a RAMDirectory, but other threads are also cloning that IndexInput at the same time. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6744) equals methods should compare classes directly, not use instanceof
[
https://issues.apache.org/jira/browse/LUCENE-6744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated LUCENE-6744:
-
Labels: newdev (was: )
equals methods should compare classes directly, not use instanceof
--
Key: LUCENE-6744
URL: https://issues.apache.org/jira/browse/LUCENE-6744
Project: Lucene - Core
Issue Type: Bug
Reporter: Hoss Man
Labels: newdev
from a 2015-07-12 email to the dev list from Fuxiang Chen...
{noformat}
We have found some inconsistencies in the overriding of the equals() method
in some files with respect to the conforming to the contract structure
based on the Java Specification.
Affected files:
1) ConstValueSource.java
2) DoubleConstValueSource.java
3) FixedBitSet.java
4) GeohashFunction.java
5) LongBitSet.java
6) SpanNearQuery.java
7) StringDistanceFunction.java
8) ValueSourceRangeFilter.java
9) VectorDistanceFunction.java
The above files all uses instanceof in the overridden equals() method in
comparing two objects.
According to the Java Specification, the equals() method must be reflexive,
symmetric, transitive and consistent. In the case of symmetric, it is
stated that x.equals(y) should return true if and only if y.equals(x)
returns true. Using instanceof is asymmetric and is not a valid symmetric
contract.
A more preferred way will be to compare the classes instead. i.e. if
(this.getClass() != o.getClass()).
However, if compiling the source code using JDK 7 and above, and if
developers still prefer to use instanceof, you can make use of the static
methods of Objects such as Objects.equals(this.id, that.id). (Making use of
the static methods of Objects is currently absent in the methods.) It will
be easier to override the equals() method and will ensure that the
overridden equals() method will fulfill the contract rules.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Suggestion for overriding equals() method
Fuxiang: thank you for your email about this. I've filed this in our jira tracker -- if you have a patch you'd like to provide to help move this issue forward, please attach there... https://issues.apache.org/jira/browse/LUCENE-6744 https://wiki.apache.org/lucene-java/HowToContribute : Date: Sun, 12 Jul 2015 14:29:02 +0800 : From: Fuxiang Chen fche...@cse.ust.hk : Reply-To: dev@lucene.apache.org : To: dev@lucene.apache.org : Subject: Suggestion for overriding equals() method : : Dear Developers, : : We have found some inconsistencies in the overriding of the equals() method : in some files with respect to the conforming to the contract structure : based on the Java Specification. : : Affected files: : 1) ConstValueSource.java : 2) DoubleConstValueSource.java : 3) FixedBitSet.java : 4) GeohashFunction.java : 5) LongBitSet.java : 6) SpanNearQuery.java : 7) StringDistanceFunction.java : 8) ValueSourceRangeFilter.java : 9) VectorDistanceFunction.java : : The above files all uses instanceof in the overridden equals() method in : comparing two objects. : : According to the Java Specification, the equals() method must be reflexive, : symmetric, transitive and consistent. In the case of symmetric, it is : stated that x.equals(y) should return true if and only if y.equals(x) : returns true. Using instanceof is asymmetric and is not a valid symmetric : contract. : : A more preferred way will be to compare the classes instead. i.e. if : (this.getClass() != o.getClass()). : : However, if compiling the source code using JDK 7 and above, and if : developers still prefer to use instanceof, you can make use of the static : methods of Objects such as Objects.equals(this.id, that.id). (Making use of : the static methods of Objects is currently absent in the methods.) It will : be easier to override the equals() method and will ensure that the : overridden equals() method will fulfill the contract rules. : : Do kindly consider making the suggestion for the changes. : : Reference: : [1] http://stackoverflow.com/questions/19642810 (based on the latest : highest answer) : [2] http://docs.oracle.com/javase/7/docs/api/java/util/Objects.html (based : on [1]) : [3] http://stackoverflow.com/questions/7132649 (based on the highest answer) : : Thanks! : : -- : Warmest Regards, : Fuxiang : -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5043) hostanme lookup in SystemInfoHandler should be refactored to not block core (re)load
[
https://issues.apache.org/jira/browse/SOLR-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701720#comment-14701720
]
Hoss Man commented on SOLR-5043:
Ram: the approach you're suggesting was explicitly discussed in the past and
deemed a bad idea because it means that if DNS changes there is no way for a
solr admin to trigger a refresh of the cached hostname -- which is why the
existing code explicitly has the comment not static, so core reload will
refresh -- that way users could at least trigger a core reload when doing
things like server swaps (or disaster recovery fail over of whole colos using
subnet aliases, etc...)
bq. Having this on a per-instance basis like it does currently would also mean
that you have one more thread running per core, even if temporarily, that might
cause issues if you have lots of cores starting up at the same time in a JVM.
which is why the suggestion of using a single threaded CompletionService,
overwritting a single static variable each time there is a core reload, is a
better one (that unfortunately noone has ever got arround to implementing)
bq. ...on the flip side, with this patch, you might sometimes not get the
hostname when you expect it (so technically it's a functional difference)
It's always been the case that if there is a DNS problem you'll get {{null}}
instead of the canonical hostname, and at a later time you might start getting
a new/different/correct hostname (currently if/when DNS is fixed and hte core
reloads) so improvements that return null if/when a hostname is unresolvable
shouldn't be ruled out just for that reason.
The more we talk about the various trade offs involved with this type of
problem, the more and more I ultimately feel like we really shouldn't invest
too much complexity in the code just to account for people with bad/broken DNS
configurations.
my current feeling is:
* we should fix the current SystemInfoHandler init logic to log errors when
there are DNS problems so they should up in the logs, but otherwise leave
things along.
* For situations like SOLR-7884 i think an advanced, seriously expert, system
property that says hey solr, under no circumstances should you try to do any
DNS lookups because i know my DNS is busted would be a good idea, and should
be implemented by a generic helper method for use both here and in the various
parts of the disributed update/search logic in the cloud code. (with forbidden
API checks to prevent any future code other then this helper method from doing
DNS related methods)
hostanme lookup in SystemInfoHandler should be refactored to not block core
(re)load
Key: SOLR-5043
URL: https://issues.apache.org/jira/browse/SOLR-5043
Project: Solr
Issue Type: Improvement
Reporter: Hoss Man
Attachments: SOLR-5043-lazy.patch, SOLR-5043.patch
SystemInfoHandler currently lookups the hostname of the machine on it's init,
and caches for it's lifecycle -- there is a comment to the effect that the
reason for this is because on some machines (notably ones with wacky DNS
settings) looking up the hostname can take a long ass time in some JVMs...
{noformat}
// on some platforms, resolving canonical hostname can cause the thread
// to block for several seconds if nameservices aren't available
// so resolve this once per handler instance
//(ie: not static, so core reload will refresh)
{noformat}
But as we move forward with a lot more multi-core, solr-cloud, dynamically
updated instances, even paying this cost per core-reload is expensive.
we should refactoring this so that SystemInfoHandler instances init
immediately, with some kind of lazy loading of the hostname info in a
background thread, (especially since hte only real point of having that info
here is for UI use so you cna keep track of what machine you are looking at)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7888) Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a BooleanQuery filter parameter available in Solr
[
https://issues.apache.org/jira/browse/SOLR-7888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701722#comment-14701722
]
Arcadius Ahouansou commented on SOLR-7888:
--
Hello [~janhoy].
Sorry I have been away for quite a while.
I have just uploaded an updated version of the patch.
Changes dones are as follow:
- No need to pass the query field anymore. the internal
{{AnalyzingInfixSuggester.CONTEXTS_FIELD_NAME}} is used as query field i.e. the
recommended way to filter is just {{ctx2 AND ctx3}} instead of the old way
{{contexts:ctx2 AND contexts:ctx3}}
- Most of the logic for parsing queries has been moved into
{{SuggestComponent.java}} to {{SolrSuggester.java}}
- Multiple suggester can be configured, each one having a different analyzer
for the context field.
- The {{contextAnalyzerFieldType}} config is optional and by default, the
analyzer of the context field will be used
- There is a test
{{testContextFilterParamIsIgnoredWhenContextIsNotImplemented()}} to test that
if you send context filtering query to a suggester that does not support
context, the filtering is just ignored and suggest return result.
Along the same line, there is also a test
{{testContextFilteringIsIgnoredWhenContextIsImplementedButNotConfigured()}}
So, the implementation is more friendly now.
- Suggester build will throw exception only if you configure context in
solrconfig.xml on a suggester that does not support context. But queries still
return normally, just the build operation for the concerned suggester fails.
There is a test
{{testBuildThrowsIllegalArgumentExceptionWhenContextIsConfiguredButNotImplemented()}}
to cover that
- buildAll will fail for all (not just the concerned suggester) if you
configure context in solrconfig.xml on a suggester that does not support context
- Regarding the parameter name. The initial implementation if did used the name
{{suggest.cfq}} for ContextFilterQuery. Then I looked at
{{suggest.dictionary}}, {{suggest.reloadAll}} etc which are plain English. For
now, I have not yet changed the name. I will change it as soon as we agreed on
that.
Please let me know in case I have missed anything you mentioned.
Thank you very much.
Arcadius
Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a
BooleanQuery filter parameter available in Solr
--
Key: SOLR-7888
URL: https://issues.apache.org/jira/browse/SOLR-7888
Project: Solr
Issue Type: New Feature
Components: Suggester
Affects Versions: 5.2.1
Reporter: Arcadius Ahouansou
Assignee: Jan Høydahl
Fix For: 5.4
Attachments: SOLR-7888.patch, SOLR-7888.patch
LUCENE-6464 has introduced a very flexible lookup method that takes as
parameter a BooleanQuery that is used for filtering results.
This ticket is to expose that method to Solr.
This would allow user to do:
{code}
/suggest?suggest=truesuggest.build=truesuggest.q=termsuggest.contextFilterQuery=contexts:tennis
/suggest?suggest=truesuggest.build=truesuggest.q=termsuggest.contextFilterQuery=contexts:golf
AND contexts:football
{code}
etc
Given that the context filtering in currently only implemented by the
{code}AnalyzingInfixSuggester{code} and by the
{code}BlendedInfixSuggester{code}, this initial implementation will support
only these 2 lookup implementations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-5.3-Linux (32bit/jdk1.9.0-ea-b76) - Build # 90 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.3-Linux/90/ Java: 32bit/jdk1.9.0-ea-b76 -client -XX:+UseG1GC -Djava.locale.providers=JRE,SPI 1 tests failed. FAILED: org.apache.solr.search.ReturnFieldsTest.testWhitespace Error Message: Not really whitespace? (@11): Stack Trace: java.lang.AssertionError: Not really whitespace? (@11): at __randomizedtesting.SeedInfo.seed([8624FA60A6C6F3F6:40524E2E1AE49400]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.lucene.util.TestUtil.randomWhitespace(TestUtil.java:1217) at org.apache.solr.search.ReturnFieldsTest.testWhitespace(ReturnFieldsTest.java:351) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:504) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:746) Build Log: [...truncated 10349 lines...] [junit4] Suite: org.apache.solr.search.ReturnFieldsTest [junit4] 2 Creating dataDir:
[jira] [Created] (LUCENE-6745) RAMInputStream.clone is not thread safe
Michael McCandless created LUCENE-6745: -- Summary: RAMInputStream.clone is not thread safe Key: LUCENE-6745 URL: https://issues.apache.org/jira/browse/LUCENE-6745 Project: Lucene - Core Issue Type: Bug Reporter: Michael McCandless Assignee: Michael McCandless Fix For: Trunk, 5.4 This took some time to track down ... it's the root cause of the RangeTree failures that [~steve_rowe] found at https://issues.apache.org/jira/browse/LUCENE-6697?focusedCommentId=14696999page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14696999 The problem happens when one thread is using the original IndexInput (RAMInputStream) from a RAMDirectory, but other threads are also cloning that IndexInput at the same time. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6745) RAMInputStream.clone is not thread safe
[ https://issues.apache.org/jira/browse/LUCENE-6745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701857#comment-14701857 ] David Smiley commented on LUCENE-6745: -- Nice catch :-)Nice test too. RAMInputStream.clone is not thread safe --- Key: LUCENE-6745 URL: https://issues.apache.org/jira/browse/LUCENE-6745 Project: Lucene - Core Issue Type: Bug Reporter: Michael McCandless Assignee: Michael McCandless Fix For: Trunk, 5.4 Attachments: LUCENE-6745.patch This took some time to track down ... it's the root cause of the RangeTree failures that [~steve_rowe] found at https://issues.apache.org/jira/browse/LUCENE-6697?focusedCommentId=14696999page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14696999 The problem happens when one thread is using the original IndexInput (RAMInputStream) from a RAMDirectory, but other threads are also cloning that IndexInput at the same time. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6745) RAMInputStream.clone is not thread safe
[ https://issues.apache.org/jira/browse/LUCENE-6745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701922#comment-14701922 ] Uwe Schindler commented on LUCENE-6745: --- Should the test have a shotgun? BTW, I would prefer using ExecutorService for the test. RAMInputStream.clone is not thread safe --- Key: LUCENE-6745 URL: https://issues.apache.org/jira/browse/LUCENE-6745 Project: Lucene - Core Issue Type: Bug Reporter: Michael McCandless Assignee: Michael McCandless Fix For: Trunk, 5.4 Attachments: LUCENE-6745.patch This took some time to track down ... it's the root cause of the RangeTree failures that [~steve_rowe] found at https://issues.apache.org/jira/browse/LUCENE-6697?focusedCommentId=14696999page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14696999 The problem happens when one thread is using the original IndexInput (RAMInputStream) from a RAMDirectory, but other threads are also cloning that IndexInput at the same time. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 768 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/768/ 4 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest Error Message: ERROR: SolrIndexSearcher opens=31 closes=30 Stack Trace: java.lang.AssertionError: ERROR: SolrIndexSearcher opens=31 closes=30 at __randomizedtesting.SeedInfo.seed([EF6380E83FB00BFF]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:467) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:233) at sun.reflect.GeneratedMethodAccessor70.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest Error Message: 2 threads leaked from SUITE scope at org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest: 1) Thread[id=24187, name=qtp703560321-24187, state=WAITING, group=TGRP-ChaosMonkeyNothingIsSafeTest] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:502) at org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient.blockUntilFinished(ConcurrentUpdateSolrClient.java:404) at org.apache.solr.update.StreamingSolrClients.blockUntilFinished(StreamingSolrClients.java:103) at org.apache.solr.update.SolrCmdDistributor.blockAndDoRetries(SolrCmdDistributor.java:231) at org.apache.solr.update.SolrCmdDistributor.finish(SolrCmdDistributor.java:89) at org.apache.solr.update.processor.DistributedUpdateProcessor.doFinish(DistributedUpdateProcessor.java:781) at org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:1655) at org.apache.solr.update.processor.LogUpdateProcessor.finish(LogUpdateProcessorFactory.java:183) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:83) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:151) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2079) at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:667) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:210) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:106) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
RE: [VOTE] 5.3.0 RC2
Hi, I just noticed that there is - next to Adrien's hot sister from the changelog - an unused bin/ directory in the root folder that was accidentally committed my Mark Miller. I deleted it now in SVN, but this should also not hold the release. It is also only in Solr's src.tgz file. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Uwe Schindler [mailto:u...@thetaphi.de] Sent: Tuesday, August 18, 2015 9:49 PM To: dev@lucene.apache.org Subject: RE: [VOTE] 5.3.0 RC2 Smoked with Java 7 AND Java 8: Java 1.7 JAVA_HOME=/home/thetaphi/jdk1.7.0_80 Java 1.8 JAVA_HOME=/home/thetaphi/jdk1.8.0_51 SUCCESS! [3:00:31.633551] (most of the time it was downloading Maven Artifacts...) I also checked the artifacts on Windows 7, unzipped to Desktop with whitespace in my file user name. Lucene looks fine, no comments. Solr starts up correctly, techproducts example also works and post.jar committed the documents from whitespace directory to new index with whitespace directory. +1 to release! Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Noble Paul [mailto:noble.p...@gmail.com] Sent: Monday, August 17, 2015 2:24 PM To: Lucene Dev Subject: [VOTE] 5.3.0 RC2 hi all, Please vote for the 2nd release candidate for Lucene/Solr 5.3.0 The artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2- rev1696229 You can run the smoke tester directly with this command: python3 -u dev-tools/scripts/smokeTestRelease.py https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2- rev1696229/ -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Updating CWIKI Javadoc macros for 5.3
DONE. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de/ http://www.thetaphi.de eMail: u...@thetaphi.de From: Cassandra Targett [mailto:casstarg...@gmail.com] Sent: Wednesday, August 19, 2015 12:14 AM To: dev@lucene.apache.org Subject: Updating CWIKI Javadoc macros for 5.3 Hi Uwe, Would you please update the CWIKI Javadoc macro links to point to the 5_3_0 paths. They don't exist yet, but I'd like to get an RC of the Ref Guide going very soon. https://cwiki.apache.org/confluence/display/solr/Internal+-+How+Javadoc+Links+Work#Internal-HowJavadocLinksWork-GuidePublishing:ChangingVersionsInAllLinks Thanks much, Cassandra
RE: [VOTE] 5.3.0 RC2
Smoked with Java 7 AND Java 8: Java 1.7 JAVA_HOME=/home/thetaphi/jdk1.7.0_80 Java 1.8 JAVA_HOME=/home/thetaphi/jdk1.8.0_51 SUCCESS! [3:00:31.633551] (most of the time it was downloading Maven Artifacts...) I also checked the artifacts on Windows 7, unzipped to Desktop with whitespace in my file user name. Lucene looks fine, no comments. Solr starts up correctly, techproducts example also works and post.jar committed the documents from whitespace directory to new index with whitespace directory. +1 to release! Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Noble Paul [mailto:noble.p...@gmail.com] Sent: Monday, August 17, 2015 2:24 PM To: Lucene Dev Subject: [VOTE] 5.3.0 RC2 hi all, Please vote for the 2nd release candidate for Lucene/Solr 5.3.0 The artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2- rev1696229 You can run the smoke tester directly with this command: python3 -u dev-tools/scripts/smokeTestRelease.py https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2- rev1696229/ -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Updating CWIKI Javadoc macros for 5.3
You're quick! Thanks. On Tue, Aug 18, 2015 at 5:17 PM, Uwe Schindler u...@thetaphi.de wrote: DONE. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de *From:* Cassandra Targett [mailto:casstarg...@gmail.com] *Sent:* Wednesday, August 19, 2015 12:14 AM *To:* dev@lucene.apache.org *Subject:* Updating CWIKI Javadoc macros for 5.3 Hi Uwe, Would you please update the CWIKI Javadoc macro links to point to the 5_3_0 paths. They don't exist yet, but I'd like to get an RC of the Ref Guide going very soon. https://cwiki.apache.org/confluence/display/solr/Internal+-+How+Javadoc+Links+Work#Internal-HowJavadocLinksWork-GuidePublishing:ChangingVersionsInAllLinks Thanks much, Cassandra
[jira] [Commented] (SOLR-5043) hostanme lookup in SystemInfoHandler should be refactored to not block core (re)load
[
https://issues.apache.org/jira/browse/SOLR-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701849#comment-14701849
]
Ramkumar Aiyengar commented on SOLR-5043:
-
Ah, my bad, I interpreted the comment to mean not static (for other reasons),
so core reload will (unfortunately) refresh (, but that's not a big deal) :)
Makes sense overall..
hostanme lookup in SystemInfoHandler should be refactored to not block core
(re)load
Key: SOLR-5043
URL: https://issues.apache.org/jira/browse/SOLR-5043
Project: Solr
Issue Type: Improvement
Reporter: Hoss Man
Attachments: SOLR-5043-lazy.patch, SOLR-5043.patch
SystemInfoHandler currently lookups the hostname of the machine on it's init,
and caches for it's lifecycle -- there is a comment to the effect that the
reason for this is because on some machines (notably ones with wacky DNS
settings) looking up the hostname can take a long ass time in some JVMs...
{noformat}
// on some platforms, resolving canonical hostname can cause the thread
// to block for several seconds if nameservices aren't available
// so resolve this once per handler instance
//(ie: not static, so core reload will refresh)
{noformat}
But as we move forward with a lot more multi-core, solr-cloud, dynamically
updated instances, even paying this cost per core-reload is expensive.
we should refactoring this so that SystemInfoHandler instances init
immediately, with some kind of lazy loading of the hostname info in a
background thread, (especially since hte only real point of having that info
here is for UI use so you cna keep track of what machine you are looking at)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6745) RAMInputStream.clone is not thread safe
[ https://issues.apache.org/jira/browse/LUCENE-6745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701915#comment-14701915 ] Robert Muir commented on LUCENE-6745: - +1 RAMInputStream.clone is not thread safe --- Key: LUCENE-6745 URL: https://issues.apache.org/jira/browse/LUCENE-6745 Project: Lucene - Core Issue Type: Bug Reporter: Michael McCandless Assignee: Michael McCandless Fix For: Trunk, 5.4 Attachments: LUCENE-6745.patch This took some time to track down ... it's the root cause of the RangeTree failures that [~steve_rowe] found at https://issues.apache.org/jira/browse/LUCENE-6697?focusedCommentId=14696999page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14696999 The problem happens when one thread is using the original IndexInput (RAMInputStream) from a RAMDirectory, but other threads are also cloning that IndexInput at the same time. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Updating CWIKI Javadoc macros for 5.3
Hi Uwe, Would you please update the CWIKI Javadoc macro links to point to the 5_3_0 paths. They don't exist yet, but I'd like to get an RC of the Ref Guide going very soon. https://cwiki.apache.org/confluence/display/solr/Internal+-+How+Javadoc+Links+Work#Internal-HowJavadocLinksWork-GuidePublishing:ChangingVersionsInAllLinks Thanks much, Cassandra
[jira] [Commented] (SOLR-7942) fix error logging when index is locked on startup, add deprecation warning if unlockOnStartup is configured
[
https://issues.apache.org/jira/browse/SOLR-7942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702080#comment-14702080
]
Hoss Man commented on SOLR-7942:
bq. ...In the default config, if directory is locked you have a second Solr
instance somewhere running
right: i'd like to improve that errmsg to make the most common situation
(multiple instances) more obvious, but also point out it depends on your
config. the main thing though is to stop mentioning unlockOnStartup completley
-- because right now even if you aren't using it, you'll get an error
mentioning it, and if you go searching for it it'll be hard to find because
we're removing it from the ref guide.
the only time you should ever get a log msg mentioning unlockOnStartup is_if_
you already have it configured -- then we should tell you to stop (the first
point)
In any case, this isn't a major issue, i just wanted to file it as a reminder
to clean it up as soon as i have some time.
fix error logging when index is locked on startup, add deprecation warning if
unlockOnStartup is configured
---
Key: SOLR-7942
URL: https://issues.apache.org/jira/browse/SOLR-7942
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: Hoss Man
Priority: Minor
LUCENE-6508 removed support for unlockOnStartup, but the way the changes are
made are inconsistent with how other config options have been deprecated in
the past, and cause a confusing error message if an index is locked on
startup...
* in 5x, the SolrConfig constructor should log a warning if the
unlockOnStartup option is specified (regardless of whether it's true or
false) so users know they need to cleanup their configs and change their
expectations (even if they never get - or have not yet gotten - a lock
problem)
* in SolrCore, the LockObtainFailedException that is thrown if the index is
locked should _not_ say {{Solr now longer supports forceful unlocking via
'unlockOnStartup'}}
** besides the no/now typo, this wording missleads users into thinking that
the LockObtainFailedException error is in some way related to that config
option -- creating an implication that using that option lead them to this
error. we shouldn't mention that here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702096#comment-14702096 ] Karl Wright commented on LUCENE-6699: - +/- 1 would work, but would remove all benefit, and then some. Bear in mind that I still don't know *why* your code needs this, but within Geo3d, everything +/-Vector.MINIMUM_RESOLUTION (which is 1e-12 at the moment) is considered the same. Integrate lat/lon BKD and spatial3d --- Key: LUCENE-6699 URL: https://issues.apache.org/jira/browse/LUCENE-6699 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Assignee: Michael McCandless Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch I'm opening this for discussion, because I'm not yet sure how to do this integration, because of my ignorance about spatial in general and spatial3d in particular :) Our BKD tree impl is very fast at doing lat/lon shape intersection (bbox, polygon, soon distance: LUCENE-6698) against previously indexed points. I think to integrate with spatial3d, we would first need to record lat/lon/z into doc values. Somewhere I saw discussion about how we could stuff all 3 into a single long value with acceptable precision loss? Or, we could use BinaryDocValues? We need all 3 dims available to do the fast per-hit query time filtering. But, second: what do we index into the BKD tree? Can we just index earth surface lat/lon, and then at query time is spatial3d able to give me an enclosing surface lat/lon bbox for a 3d shape? Or ... must we index all 3 dimensions into the BKD tree (seems like this could be somewhat wasteful)? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702107#comment-14702107 ] Karl Wright commented on LUCENE-6699: - I was able to repro this with that seed as well. Looking deeper. Integrate lat/lon BKD and spatial3d --- Key: LUCENE-6699 URL: https://issues.apache.org/jira/browse/LUCENE-6699 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Assignee: Michael McCandless Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch I'm opening this for discussion, because I'm not yet sure how to do this integration, because of my ignorance about spatial in general and spatial3d in particular :) Our BKD tree impl is very fast at doing lat/lon shape intersection (bbox, polygon, soon distance: LUCENE-6698) against previously indexed points. I think to integrate with spatial3d, we would first need to record lat/lon/z into doc values. Somewhere I saw discussion about how we could stuff all 3 into a single long value with acceptable precision loss? Or, we could use BinaryDocValues? We need all 3 dims available to do the fast per-hit query time filtering. But, second: what do we index into the BKD tree? Can we just index earth surface lat/lon, and then at query time is spatial3d able to give me an enclosing surface lat/lon bbox for a 3d shape? Or ... must we index all 3 dimensions into the BKD tree (seems like this could be somewhat wasteful)? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6745) RAMInputStream.clone is not thread safe
[ https://issues.apache.org/jira/browse/LUCENE-6745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701961#comment-14701961 ] Michael McCandless commented on LUCENE-6745: bq. Should the test have a shotgun? BTW, I would prefer using ExecutorService for the test. I prefer to keep concurrency constructs to a minimum ... I think it's important that our tests are approachable. And the bug repros fine w/o the shotgun. RAMInputStream.clone is not thread safe --- Key: LUCENE-6745 URL: https://issues.apache.org/jira/browse/LUCENE-6745 Project: Lucene - Core Issue Type: Bug Reporter: Michael McCandless Assignee: Michael McCandless Fix For: Trunk, 5.4 Attachments: LUCENE-6745.patch This took some time to track down ... it's the root cause of the RangeTree failures that [~steve_rowe] found at https://issues.apache.org/jira/browse/LUCENE-6697?focusedCommentId=14696999page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14696999 The problem happens when one thread is using the original IndexInput (RAMInputStream) from a RAMDirectory, but other threads are also cloning that IndexInput at the same time. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-5.3 - Build # 9 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.3/9/ 2 tests failed. FAILED: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test Error Message: Error from server at https://127.0.0.1:48730: Error CREATEing SolrCore 'halfcollection_shard1_replica1': Unable to create core [halfcollection_shard1_replica1] Caused by: Could not get shard id for core: halfcollection_shard1_replica1 Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:48730: Error CREATEing SolrCore 'halfcollection_shard1_replica1': Unable to create core [halfcollection_shard1_replica1] Caused by: Could not get shard id for core: halfcollection_shard1_replica1 at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.makeRequest(CollectionsAPIDistributedZkTest.java:301) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testErrorHandling(CollectionsAPIDistributedZkTest.java:418) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:168) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[JENKINS] Lucene-Solr-Tests-5.3-Java7 - Build # 20 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.3-Java7/20/ No tests ran. Build Log: [...truncated 297 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_3 org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/lucene_solr_5_3 failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/lucene_solr_5_3 failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: OPTIONS request failed on '/repos/asf/lucene/dev/branches/lucene_solr_5_3' svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/lucene_solr_5_3': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:771) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/lucene_solr_5_3': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141) at
[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #1517: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1517/ No tests ran. Build Log: [...truncated 304 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/trunk org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' svn: E170001: OPTIONS of '/repos/asf/lucene/dev/trunk': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:771) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E170001: OPTIONS of '/repos/asf/lucene/dev/trunk': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.createDefaultErrorMessage(HTTPRequest.java:455) at
[JENKINS] Lucene-Artifacts-trunk - Build # 2744 - Failure
Build: https://builds.apache.org/job/Lucene-Artifacts-trunk/2744/ No tests ran. Build Log: [...truncated 300 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/trunk org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' svn: E170001: OPTIONS of '/repos/asf/lucene/dev/trunk': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:771) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E170001: OPTIONS of '/repos/asf/lucene/dev/trunk': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.createDefaultErrorMessage(HTTPRequest.java:455) at
[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 932 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/932/ No tests ran. Build Log: [...truncated 160 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/branch_5x': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:771) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/branch_5x': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141) at
[JENKINS] Solr-Artifacts-trunk - Build # 2636 - Still Failing
Build: https://builds.apache.org/job/Solr-Artifacts-trunk/2636/ No tests ran. Build Log: [...truncated 8 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/trunk org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' svn: E170001: OPTIONS of '/repos/asf/lucene/dev/trunk': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:771) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E170001: OPTIONS of '/repos/asf/lucene/dev/trunk': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.createDefaultErrorMessage(HTTPRequest.java:455) at
[JENKINS] Solr-Artifacts-5.x - Build # 909 - Failure
Build: https://builds.apache.org/job/Solr-Artifacts-5.x/909/ No tests ran. Build Log: [...truncated 303 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/branch_5x': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:771) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/branch_5x': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141) at
[JENKINS] Solr-Artifacts-5.x - Build # 911 - Still Failing
Build: https://builds.apache.org/job/Solr-Artifacts-5.x/911/ No tests ran. Build Log: [...truncated 8 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/branch_5x': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:771) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/branch_5x': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141) at
[JENKINS] Solr-Artifacts-5.3 - Build # 7 - Failure
Build: https://builds.apache.org/job/Solr-Artifacts-5.3/7/ No tests ran. Build Log: [...truncated 302 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_3 org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/lucene_solr_5_3 failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/lucene_solr_5_3 failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: OPTIONS request failed on '/repos/asf/lucene/dev/branches/lucene_solr_5_3' svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/lucene_solr_5_3': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:771) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/lucene_solr_5_3': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141) at
[JENKINS] Solr-Artifacts-trunk - Build # 2635 - Failure
Build: https://builds.apache.org/job/Solr-Artifacts-trunk/2635/ No tests ran. Build Log: [...truncated 307 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/trunk org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' svn: E170001: OPTIONS of '/repos/asf/lucene/dev/trunk': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:771) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E170001: OPTIONS of '/repos/asf/lucene/dev/trunk': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.createDefaultErrorMessage(HTTPRequest.java:455) at
[JENKINS] Lucene-Artifacts-5.x - Build # 931 - Failure
Build: https://builds.apache.org/job/Lucene-Artifacts-5.x/931/ No tests ran. Build Log: [...truncated 296 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/branch_5x': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:771) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/branch_5x': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141) at
[JENKINS] Lucene-Artifacts-5.x - Build # 932 - Still Failing
Build: https://builds.apache.org/job/Lucene-Artifacts-5.x/932/ No tests ran. Build Log: [...truncated 6 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/branch_5x': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:771) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/branch_5x': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141) at
[JENKINS] Solr-Artifacts-5.x - Build # 910 - Still Failing
Build: https://builds.apache.org/job/Solr-Artifacts-5.x/910/ No tests ran. Build Log: [...truncated 8 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/branch_5x': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:771) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/branch_5x': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141) at
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 3426 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3426/ No tests ran. Build Log: [...truncated 295 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/branch_5x': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:771) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/branch_5x': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141) at
[JENKINS] Lucene-Artifacts-5.3 - Build # 7 - Still Failing
Build: https://builds.apache.org/job/Lucene-Artifacts-5.3/7/ No tests ran. Build Log: [...truncated 43 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_3 org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/lucene_solr_5_3 failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/lucene_solr_5_3 failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: OPTIONS request failed on '/repos/asf/lucene/dev/branches/lucene_solr_5_3' svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/lucene_solr_5_3': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:771) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/lucene_solr_5_3': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141) at
[jira] [Created] (SOLR-7942) fix error logging when index is locked on startup, add deprecation warning if unlockOnStartup is configured
Hoss Man created SOLR-7942:
--
Summary: fix error logging when index is locked on startup, add
deprecation warning if unlockOnStartup is configured
Key: SOLR-7942
URL: https://issues.apache.org/jira/browse/SOLR-7942
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: Hoss Man
Priority: Minor
LUCENE-6508 removed support for unlockOnStartup, but the way the changes are
made are inconsistent with how other config options have been deprecated in the
past, and cause a confusing error message if an index is locked on startup...
* in 5x, the SolrConfig constructor should log a warning if the unlockOnStartup
option is specified (regardless of whether it's true or false) so users know
they need to cleanup their configs and change their expectations (even if they
never get - or have not yet gotten - a lock problem)
* in SolrCore, the LockObtainFailedException that is thrown if the index is
locked should _not_ say {{Solr now longer supports forceful unlocking via
'unlockOnStartup'}}
** besides the no/now typo, this wording missleads users into thinking that the
LockObtainFailedException error is in some way related to that config option --
creating an implication that using that option lead them to this error. we
shouldn't mention that here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702100#comment-14702100
]
Michael McCandless commented on LUCENE-6699:
Hmm I'm still seeing test failures w/ the patch, e.g.:
{noformat}
ago 18, 2015 11:28:37 PM
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
uncaughtException
ADVERTENCIA: Uncaught exception in thread: Thread[T0,5,TGRP-TestGeo3DPointField]
java.lang.AssertionError: T0: iter=71 id=5758 docID=1056
lat=-0.7503052868590764 lon=0.03113194606309409 expected true but got: false
deleted?=false
point1=[X=0.731126293194162, Y=0.022768740606807995, Z=-0.6818621032520755],
iswithin=true
point2=[X=0.731126292820613, Y=0.0227687404615659, Z=-0.6818621031259476],
iswithin=true
query=PointInGeo3DShapeQuery: field=point:PlanetModel: PlanetModel.SPHERE
Shape: GeoCircle: {planetmodel=PlanetModel.SPHERE,
center=[X=0.22316407597143118, Y=0.8640521337091807, Z=-0.45123353757054624],
radius=1.0586809798482488(60.65795199607921)}
at __randomizedtesting.SeedInfo.seed([BE582B0DCB72C9AE]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.lucene.bkdtree3d.TestGeo3DPointField$4._run(TestGeo3DPointField.java:617)
at
org.apache.lucene.bkdtree3d.TestGeo3DPointField$4.run(TestGeo3DPointField.java:514)
NOTE: reproduce with: ant test -Dtestcase=TestGeo3DPointField
-Dtests.method=testRandomMedium -Dtests.seed=BE582B0DCB72C9AE -Dtests.slow=true
-Dtests.linedocsfile=/lucenedata/hudson.enwiki.random.lines.txt.fixed
-Dtests.locale=es_VE -Dtests.timezone=Africa/Algiers -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
.IENOTE: test params are:
codec=FastDecompressionCompressingStoredFields(storedFieldsFormat=CompressingStoredFieldsFormat(compressionMode=FAST_DECOMPRESSION,
chunkSize=13655, maxDocsPerChunk=627, blockSize=8),
termVectorsFormat=CompressingTermVectorsFormat(compressionMode=FAST_DECOMPRESSION,
chunkSize=13655, blockSize=8)), sim=DefaultSimilarity, locale=es_VE,
timezone=Africa/Algiers
NOTE: Linux 3.13.0-46-generic amd64/Oracle Corporation 1.8.0_40
(64-bit)/cpus=8,threads=1,free=428823904,total=514850816
NOTE: All tests run in this JVM: [TestGeo3DPointField]
NOTE: reproduce with: ant test -Dtestcase=TestGeo3DPointField
-Dtests.seed=BE582B0DCB72C9AE -Dtests.slow=true
-Dtests.linedocsfile=/lucenedata/hudson.enwiki.random.lines.txt.fixed
-Dtests.locale=es_VE -Dtests.timezone=Africa/Algiers -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
{noformat}
Integrate lat/lon BKD and spatial3d
---
Key: LUCENE-6699
URL: https://issues.apache.org/jira/browse/LUCENE-6699
Project: Lucene - Core
Issue Type: New Feature
Reporter: Michael McCandless
Assignee: Michael McCandless
Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch,
LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
LUCENE-6699.patch
I'm opening this for discussion, because I'm not yet sure how to do
this integration, because of my ignorance about spatial in general and
spatial3d in particular :)
Our BKD tree impl is very fast at doing lat/lon shape intersection
(bbox, polygon, soon distance: LUCENE-6698) against previously indexed
points.
I think to integrate with spatial3d, we would first need to record
lat/lon/z into doc values. Somewhere I saw discussion about how we
could stuff all 3 into a single long value with acceptable precision
loss? Or, we could use BinaryDocValues? We need all 3 dims available
to do the fast per-hit query time filtering.
But, second: what do we index into the BKD tree? Can we just index
earth surface lat/lon, and then at query time is spatial3d able to
give me an enclosing surface lat/lon bbox for a 3d shape? Or
... must we index all 3 dimensions into the BKD tree (seems like this
could be somewhat wasteful)?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b76) - Build # 13911 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13911/ Java: 32bit/jdk1.9.0-ea-b76 -server -XX:+UseSerialGC -Djava.locale.providers=JRE,SPI 177 tests failed. FAILED: org.apache.lucene.TestDemo.testDemo Error Message: expected:1 but was:0 Stack Trace: java.lang.AssertionError: expected:1 but was:0 at __randomizedtesting.SeedInfo.seed([37AED9B3EB35A2BD:48026506DAE888AD]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.lucene.TestDemo.testDemo(TestDemo.java:62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:504) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:746) FAILED: org.apache.lucene.TestExternalCodecs.testPerFieldCodec Error Message: expected:740 but was:79 Stack Trace: java.lang.AssertionError: expected:740 but was:79 at __randomizedtesting.SeedInfo.seed([37AED9B3EB35A2BD:9B8B46BF13E9B447]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456)
[jira] [Commented] (SOLR-7734) MapReduce Indexer can error when using collection
[
https://issues.apache.org/jira/browse/SOLR-7734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702146#comment-14702146
]
Gregory Chanan commented on SOLR-7734:
--
bq. 3) stopwords, synonyms, and protwords were all referenced from schema.xml
via the text_en type. I copied that from the other mr conf, though. Can look
into removing this if you think that's a worthwhile effort.
I saw stopwords_en.txt being referenced, not stopwords. But I just looked
quickly -- if you try to remove and it doesn't work just leave it in.
bq. 4) You lost some of the leading spaces when copying to JIRA, but it's 4
spaces for a continuation (the try resource declaration) and then 2 spaces for
the body of the try. What should it be?
My mistake.
MapReduce Indexer can error when using collection
-
Key: SOLR-7734
URL: https://issues.apache.org/jira/browse/SOLR-7734
Project: Solr
Issue Type: Bug
Components: contrib - MapReduce
Affects Versions: 5.2.1
Reporter: Mike Drob
Assignee: Gregory Chanan
Fix For: Trunk, 5.4
Attachments: SOLR-7734.patch, SOLR-7734.patch, SOLR-7734.patch,
SOLR-7734.patch, SOLR-7734.patch
When running the MapReduceIndexerTool, it will usually pull a
{{solrconfig.xml}} from ZK for the collection that it is running against.
This can be problematic for several reasons:
* Performance: The configuration in ZK will likely have several query
handlers, and lots of other components that don't make sense in an
indexing-only use of EmbeddedSolrServer (ESS).
* Classpath Resources: If the Solr services are using some kind of additional
service (such as Sentry for auth) then the indexer will not have access to
the necessary configurations without the user jumping through several hoops.
* Distinct Configuration Needs: Enabling Soft Commits on the ESS doesn't make
sense. There's other configurations that
* Update Chain Behaviours: I'm under the impression that UpdateChains may
behave differently in ESS than a SolrCloud cluster. Is it safe to depend on
consistent behaviour here?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b76) - Build # 13911 - Failure!
Hi Rory, hi Balchandra, Java 9 (now testing build 76) Hotspot implementation is still broken like hell (at least in the 32 bits Linux builds, 64 bits seems more stable - have not seen the same error)! We should really contact the hotspot people directly on the mailing list to get them on board, maybe they should have some test environment and run the tests of Lucene on their own machines. Just opening bug reports does not make sense here, because every failure looks different and we have no idea what's wrong. I will be on vacation the next days, so I cannot take care. I reverted back to build 60, so it does not fail all the time. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de] Sent: Wednesday, August 19, 2015 12:57 AM To: dev@lucene.apache.org Subject: [JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b76) - Build # 13911 - Failure! Importance: Low Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13911/ Java: 32bit/jdk1.9.0-ea-b76 -server -XX:+UseSerialGC - Djava.locale.providers=JRE,SPI 177 tests failed. FAILED: org.apache.lucene.TestDemo.testDemo Error Message: expected:1 but was:0 Stack Trace: java.lang.AssertionError: expected:1 but was:0 at __randomizedtesting.SeedInfo.seed([37AED9B3EB35A2BD:48026506DAE888 AD]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.lucene.TestDemo.testDemo(TestDemo.java:62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j ava:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:504) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize dRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando mizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando mizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando mizedRunner.java:886) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule SetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA fterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleTh readAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRule IgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure .java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat ementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner. run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask (ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL eakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran domizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(Rando mizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(Rando mizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando mizedRunner.java:792) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA fterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat ementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCl assName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat ementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat ementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat ementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAss ertionsRequired.java:54) at
[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702136#comment-14702136 ] Michael McCandless commented on LUCENE-6699: [~daddywri] I committed a renaming of the relations: I was driving myself insane trying to reason about them. I also added a new relation, for when the cell fully contains the shape, and a new assertion which now trips. I didn't commit the fudge factors yet ... if you find they are needed I can ... but I'm still not sure where the bug is :) Integrate lat/lon BKD and spatial3d --- Key: LUCENE-6699 URL: https://issues.apache.org/jira/browse/LUCENE-6699 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Assignee: Michael McCandless Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch I'm opening this for discussion, because I'm not yet sure how to do this integration, because of my ignorance about spatial in general and spatial3d in particular :) Our BKD tree impl is very fast at doing lat/lon shape intersection (bbox, polygon, soon distance: LUCENE-6698) against previously indexed points. I think to integrate with spatial3d, we would first need to record lat/lon/z into doc values. Somewhere I saw discussion about how we could stuff all 3 into a single long value with acceptable precision loss? Or, we could use BinaryDocValues? We need all 3 dims available to do the fast per-hit query time filtering. But, second: what do we index into the BKD tree? Can we just index earth surface lat/lon, and then at query time is spatial3d able to give me an enclosing surface lat/lon bbox for a 3d shape? Or ... must we index all 3 dimensions into the BKD tree (seems like this could be somewhat wasteful)? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702132#comment-14702132 ] ASF subversion and git services commented on LUCENE-6699: - Commit 1696511 from [~mikemccand] in branch 'dev/branches/lucene6699' [ https://svn.apache.org/r1696511 ] LUCENE-6699: rename relations Integrate lat/lon BKD and spatial3d --- Key: LUCENE-6699 URL: https://issues.apache.org/jira/browse/LUCENE-6699 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Assignee: Michael McCandless Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch I'm opening this for discussion, because I'm not yet sure how to do this integration, because of my ignorance about spatial in general and spatial3d in particular :) Our BKD tree impl is very fast at doing lat/lon shape intersection (bbox, polygon, soon distance: LUCENE-6698) against previously indexed points. I think to integrate with spatial3d, we would first need to record lat/lon/z into doc values. Somewhere I saw discussion about how we could stuff all 3 into a single long value with acceptable precision loss? Or, we could use BinaryDocValues? We need all 3 dims available to do the fast per-hit query time filtering. But, second: what do we index into the BKD tree? Can we just index earth surface lat/lon, and then at query time is spatial3d able to give me an enclosing surface lat/lon bbox for a 3d shape? Or ... must we index all 3 dimensions into the BKD tree (seems like this could be somewhat wasteful)? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702163#comment-14702163
]
Karl Wright commented on LUCENE-6699:
-
[~mikemccand]: This has GOT to be wrong:
{code}
if (cellXMin = state.xMin ||
cellXMax = state.xMax ||
cellYMin = state.yMin ||
cellYMin = state.yMin ||
cellZMin = state.zMin ||
cellZMax = state.zMax) {
{code}
... if for no other reason than you have two identical clauses...
Integrate lat/lon BKD and spatial3d
---
Key: LUCENE-6699
URL: https://issues.apache.org/jira/browse/LUCENE-6699
Project: Lucene - Core
Issue Type: New Feature
Reporter: Michael McCandless
Assignee: Michael McCandless
Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch,
LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
LUCENE-6699.patch
I'm opening this for discussion, because I'm not yet sure how to do
this integration, because of my ignorance about spatial in general and
spatial3d in particular :)
Our BKD tree impl is very fast at doing lat/lon shape intersection
(bbox, polygon, soon distance: LUCENE-6698) against previously indexed
points.
I think to integrate with spatial3d, we would first need to record
lat/lon/z into doc values. Somewhere I saw discussion about how we
could stuff all 3 into a single long value with acceptable precision
loss? Or, we could use BinaryDocValues? We need all 3 dims available
to do the fast per-hit query time filtering.
But, second: what do we index into the BKD tree? Can we just index
earth surface lat/lon, and then at query time is spatial3d able to
give me an enclosing surface lat/lon bbox for a 3d shape? Or
... must we index all 3 dimensions into the BKD tree (seems like this
could be somewhat wasteful)?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702174#comment-14702174 ] Michael McCandless commented on LUCENE-6699: You're right! Two silly bugs in that multi-line if statement :) I committed a fix ... but test is still angry. Integrate lat/lon BKD and spatial3d --- Key: LUCENE-6699 URL: https://issues.apache.org/jira/browse/LUCENE-6699 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Assignee: Michael McCandless Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch I'm opening this for discussion, because I'm not yet sure how to do this integration, because of my ignorance about spatial in general and spatial3d in particular :) Our BKD tree impl is very fast at doing lat/lon shape intersection (bbox, polygon, soon distance: LUCENE-6698) against previously indexed points. I think to integrate with spatial3d, we would first need to record lat/lon/z into doc values. Somewhere I saw discussion about how we could stuff all 3 into a single long value with acceptable precision loss? Or, we could use BinaryDocValues? We need all 3 dims available to do the fast per-hit query time filtering. But, second: what do we index into the BKD tree? Can we just index earth surface lat/lon, and then at query time is spatial3d able to give me an enclosing surface lat/lon bbox for a 3d shape? Or ... must we index all 3 dimensions into the BKD tree (seems like this could be somewhat wasteful)? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702172#comment-14702172 ] ASF subversion and git services commented on LUCENE-6699: - Commit 1696512 from [~mikemccand] in branch 'dev/branches/lucene6699' [ https://svn.apache.org/r1696512 ] LUCENE-6699: fix wrong cell/bbox check Integrate lat/lon BKD and spatial3d --- Key: LUCENE-6699 URL: https://issues.apache.org/jira/browse/LUCENE-6699 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Assignee: Michael McCandless Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch I'm opening this for discussion, because I'm not yet sure how to do this integration, because of my ignorance about spatial in general and spatial3d in particular :) Our BKD tree impl is very fast at doing lat/lon shape intersection (bbox, polygon, soon distance: LUCENE-6698) against previously indexed points. I think to integrate with spatial3d, we would first need to record lat/lon/z into doc values. Somewhere I saw discussion about how we could stuff all 3 into a single long value with acceptable precision loss? Or, we could use BinaryDocValues? We need all 3 dims available to do the fast per-hit query time filtering. But, second: what do we index into the BKD tree? Can we just index earth surface lat/lon, and then at query time is spatial3d able to give me an enclosing surface lat/lon bbox for a 3d shape? Or ... must we index all 3 dimensions into the BKD tree (seems like this could be somewhat wasteful)? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.3-Linux (64bit/jdk1.7.0_80) - Build # 93 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.3-Linux/93/ Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseParallelGC No tests ran. Build Log: [...truncated 304 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_3 org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/lucene_solr_5_3': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:759) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:371) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:359) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:710) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1032) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:143) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.createRepository(SvnRepositoryAccess.java:110) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepository(SvnNgRepositoryAccess.java:210) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:156) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:72) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:38) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:18) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:158) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:991) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948) at hudson.FilePath.act(FilePath.java:991) at hudson.FilePath.act(FilePath.java:969) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:833) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1277) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532) at hudson.model.Run.execute(Run.java:1741) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:381) ERROR: Subversion update failed java.io.IOException at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:212) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:991) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948) at hudson.FilePath.act(FilePath.java:991) at hudson.FilePath.act(FilePath.java:969) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:833) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1277) at
[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60-ea-b25) - Build # 13913 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13913/ Java: 64bit/jdk1.8.0_60-ea-b25 -XX:+UseCompressedOops -XX:+UseG1GC No tests ran. Build Log: [...truncated 307 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/trunk org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: OPTIONS of '/repos/asf/lucene/dev/trunk': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:759) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:371) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:359) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:710) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1032) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:143) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.createRepository(SvnRepositoryAccess.java:110) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepository(SvnNgRepositoryAccess.java:210) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:156) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:72) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:38) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:18) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:158) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:991) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948) at hudson.FilePath.act(FilePath.java:991) at hudson.FilePath.act(FilePath.java:969) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:833) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1277) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532) at hudson.model.Run.execute(Run.java:1741) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:381) ERROR: Subversion update failed java.io.IOException at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:212) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:991) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948) at hudson.FilePath.act(FilePath.java:991) at hudson.FilePath.act(FilePath.java:969) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:833) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1277) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610) at
[jira] [Commented] (SOLR-7746) Ping requests stopped working with distrib=true in Solr 5.2.1
[
https://issues.apache.org/jira/browse/SOLR-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702234#comment-14702234
]
Gregory Chanan commented on SOLR-7746:
--
Can we put the complexity in the PingRequestHandler instead of the
SearchHandler? Localizing the complexity seems like the best long term
approach here.
Ping requests stopped working with distrib=true in Solr 5.2.1
-
Key: SOLR-7746
URL: https://issues.apache.org/jira/browse/SOLR-7746
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 5.2.1
Reporter: Alexey Serba
Attachments: SOLR-7746.patch
{noformat:title=steps to reproduce}
# start 1 node SolrCloud cluster
sh ./bin/solr -c -p
# create a test collection (we won’t use it, but I just want to it to load
solr configs to Zk)
./bin/solr create_collection -c test -d sample_techproducts_configs -p
# create another test collection with 2 shards
curl
'http://localhost:/solr/admin/collections?action=CREATEname=test2numShards=2replicationFactor=1maxShardsPerNode=2collection.configName=test'
# try distrib ping request
curl
'http://localhost:/solr/test2/admin/ping?wt=jsondistrib=trueindent=true'
...
error:{
msg:Ping query caused exception: Error from server at
http://192.168.59.3:/solr/test2_shard2_replica1: Cannot execute the
PingRequestHandler recursively
...
{noformat}
{noformat:title=Exception}
2116962 [qtp599601600-13] ERROR org.apache.solr.core.SolrCore [test2 shard2
core_node1 test2_shard2_replica1] – org.apache.solr.common.SolrException:
Cannot execute the PingRequestHandler recursively
at
org.apache.solr.handler.PingRequestHandler.handlePing(PingRequestHandler.java:246)
at
org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:211)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-5.x-Linux (32bit/jdk1.8.0_60-ea-b25) - Build # 13651 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13651/ Java: 32bit/jdk1.8.0_60-ea-b25 -client -XX:+UseParallelGC No tests ran. Build Log: [...truncated 14 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/branch_5x': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:759) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:371) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:359) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:710) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1032) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:143) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.createRepository(SvnRepositoryAccess.java:110) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepository(SvnNgRepositoryAccess.java:210) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:156) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:72) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:38) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:18) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:158) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:991) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948) at hudson.FilePath.act(FilePath.java:991) at hudson.FilePath.act(FilePath.java:969) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:833) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1277) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532) at hudson.model.Run.execute(Run.java:1741) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:381) ERROR: Subversion update failed java.io.IOException at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:212) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:991) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948) at hudson.FilePath.act(FilePath.java:991) at hudson.FilePath.act(FilePath.java:969) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:833) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1277) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610)
[jira] [Comment Edited] (SOLR-7888) Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a BooleanQuery filter parameter available in Solr
[
https://issues.apache.org/jira/browse/SOLR-7888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701722#comment-14701722
]
Arcadius Ahouansou edited comment on SOLR-7888 at 8/19/15 1:41 AM:
---
Hello [~janhoy].
Sorry I have been away for quite a while.
I have just uploaded an updated version of the patch.
Changes dones are as follow:
- No need to pass the query field anymore. the internal
{{AnalyzingInfixSuggester.CONTEXTS_FIELD_NAME}} is used as query field i.e. the
recommended way to filter is just {{ctx2 AND ctx3}} instead of the old way
{{contexts:ctx2 AND contexts:ctx3}}
- Most of the logic for parsing queries has been moved from
{{SuggestComponent.java}} into {{SolrSuggester.java}}
- Multiple suggester can be configured, each one having a different analyzer
for the context field as the query parsing in now done in the SolrSuggester.
- The {{contextAnalyzerFieldType}} config is optional and by default, the
analyzer of the context field will be used
- There is a test
{{testContextFilterParamIsIgnoredWhenContextIsNotImplemented()}} to test that
if you send context filtering query to a suggester that does not support
context, the filtering is just ignored and suggest return result.
Along the same line, there is also a test
{{testContextFilteringIsIgnoredWhenContextIsImplementedButNotConfigured()}}
So, the implementation is more friendly now.
- Suggester build will throw exception only if you configure context in
solrconfig.xml on a suggester that does not support context. But queries still
return normally, just the build operation for the concerned suggester fails.
There is a test
{{testBuildThrowsIllegalArgumentExceptionWhenContextIsConfiguredButNotImplemented()}}
to cover that
- buildAll will fail for all (not just the concerned suggester) if you
configure context in solrconfig.xml on a suggester that does not support context
- Regarding the parameter name. The initial implementation if did used the name
{{suggest.cfq}} for ContextFilterQuery. Then I looked at
{{suggest.dictionary}}, {{suggest.reloadAll}} etc which are plain English. For
now, I have not yet changed the name. I will change it as soon as we agreed on
that.
Please let me know in case I have missed anything you mentioned.
Thank you very much.
Arcadius
was (Author: arcadius):
Hello [~janhoy].
Sorry I have been away for quite a while.
I have just uploaded an updated version of the patch.
Changes dones are as follow:
- No need to pass the query field anymore. the internal
{{AnalyzingInfixSuggester.CONTEXTS_FIELD_NAME}} is used as query field i.e. the
recommended way to filter is just {{ctx2 AND ctx3}} instead of the old way
{{contexts:ctx2 AND contexts:ctx3}}
- Most of the logic for parsing queries has been moved into
{{SuggestComponent.java}} to {{SolrSuggester.java}}
- Multiple suggester can be configured, each one having a different analyzer
for the context field.
- The {{contextAnalyzerFieldType}} config is optional and by default, the
analyzer of the context field will be used
- There is a test
{{testContextFilterParamIsIgnoredWhenContextIsNotImplemented()}} to test that
if you send context filtering query to a suggester that does not support
context, the filtering is just ignored and suggest return result.
Along the same line, there is also a test
{{testContextFilteringIsIgnoredWhenContextIsImplementedButNotConfigured()}}
So, the implementation is more friendly now.
- Suggester build will throw exception only if you configure context in
solrconfig.xml on a suggester that does not support context. But queries still
return normally, just the build operation for the concerned suggester fails.
There is a test
{{testBuildThrowsIllegalArgumentExceptionWhenContextIsConfiguredButNotImplemented()}}
to cover that
- buildAll will fail for all (not just the concerned suggester) if you
configure context in solrconfig.xml on a suggester that does not support context
- Regarding the parameter name. The initial implementation if did used the name
{{suggest.cfq}} for ContextFilterQuery. Then I looked at
{{suggest.dictionary}}, {{suggest.reloadAll}} etc which are plain English. For
now, I have not yet changed the name. I will change it as soon as we agreed on
that.
Please let me know in case I have missed anything you mentioned.
Thank you very much.
Arcadius
Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a
BooleanQuery filter parameter available in Solr
--
Key: SOLR-7888
URL: https://issues.apache.org/jira/browse/SOLR-7888
Project: Solr
Issue Type: New Feature
Components: Suggester
Affects Versions: 5.2.1
Reporter: Arcadius Ahouansou
Assignee: Jan
[jira] [Commented] (SOLR-7734) MapReduce Indexer can error when using collection
[
https://issues.apache.org/jira/browse/SOLR-7734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702126#comment-14702126
]
Mike Drob commented on SOLR-7734:
-
1) Renamed to {{MiniMRBase.java}}
2) Fixed.
3) {{stopwords}}, {{synonyms}}, and {{protwords}} were all referenced from
{{schema.xml}} via the {{text_en}} type. I copied that from the other mr conf,
though. Can look into removing this if you think that's a worthwhile effort.
4) You lost some of the leading spaces when copying to JIRA, but it's 4 spaces
for a continuation (the try resource declaration) and then 2 spaces for the
body of the try. What should it be?
5) Fixed.
Will upload a new patch once I finish re-running tests with these changes.
MapReduce Indexer can error when using collection
-
Key: SOLR-7734
URL: https://issues.apache.org/jira/browse/SOLR-7734
Project: Solr
Issue Type: Bug
Components: contrib - MapReduce
Affects Versions: 5.2.1
Reporter: Mike Drob
Assignee: Gregory Chanan
Fix For: Trunk, 5.4
Attachments: SOLR-7734.patch, SOLR-7734.patch, SOLR-7734.patch,
SOLR-7734.patch, SOLR-7734.patch
When running the MapReduceIndexerTool, it will usually pull a
{{solrconfig.xml}} from ZK for the collection that it is running against.
This can be problematic for several reasons:
* Performance: The configuration in ZK will likely have several query
handlers, and lots of other components that don't make sense in an
indexing-only use of EmbeddedSolrServer (ESS).
* Classpath Resources: If the Solr services are using some kind of additional
service (such as Sentry for auth) then the indexer will not have access to
the necessary configurations without the user jumping through several hoops.
* Distinct Configuration Needs: Enabling Soft Commits on the ESS doesn't make
sense. There's other configurations that
* Update Chain Behaviours: I'm under the impression that UpdateChains may
behave differently in ESS than a SolrCloud cluster. Is it safe to depend on
consistent behaviour here?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6629) Watch /collections zk node on all nodes
[ https://issues.apache.org/jira/browse/SOLR-6629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702178#comment-14702178 ] Scott Blum commented on SOLR-6629: -- [~shalinmangar] ping for review Watch /collections zk node on all nodes --- Key: SOLR-6629 URL: https://issues.apache.org/jira/browse/SOLR-6629 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Shalin Shekhar Mangar Assignee: Noble Paul Fix For: Trunk Attachments: SOLR-6629.patch The main clusterstate.json is refreshed/used as a poor substitute for informing all nodes about new or deleted collections even when the collection being created or deleted has state format 1. When we move away from state format 1 then we should do away with this workaround and start watching the /collections zk node on all nodes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6760) New optimized DistributedQueue implementation for overseer
[ https://issues.apache.org/jira/browse/SOLR-6760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702177#comment-14702177 ] Scott Blum commented on SOLR-6760: -- [~shalinmangar] ping for review New optimized DistributedQueue implementation for overseer -- Key: SOLR-6760 URL: https://issues.apache.org/jira/browse/SOLR-6760 Project: Solr Issue Type: Bug Reporter: Noble Paul Assignee: Noble Paul Attachments: SOLR-6760.patch, SOLR-6760.patch, deadlock.patch Currently the DQ works as follows * read all items in the directory * sort them all * take the head and return it and discard everything else * rinse and repeat This works well when we have only a handful of items in the Queue. If the items in the queue is much larger (in tens of thousands) , this is counterproductive As the overseer queue is a multiple producers + single consumer queue, We can read them all in bulk and before processing each item , just do a zk.exists(itemname) and if all is well we don't need to do the fetch all + sort thing again -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7734) MapReduce Indexer can error when using collection
[
https://issues.apache.org/jira/browse/SOLR-7734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob updated SOLR-7734:
Attachment: SOLR-7734.patch
Attaching a new patch that addresses the issues. I was able to reduce the
number of conf files a bit too.
MapReduce Indexer can error when using collection
-
Key: SOLR-7734
URL: https://issues.apache.org/jira/browse/SOLR-7734
Project: Solr
Issue Type: Bug
Components: contrib - MapReduce
Affects Versions: 5.2.1
Reporter: Mike Drob
Assignee: Gregory Chanan
Fix For: Trunk, 5.4
Attachments: SOLR-7734.patch, SOLR-7734.patch, SOLR-7734.patch,
SOLR-7734.patch, SOLR-7734.patch, SOLR-7734.patch
When running the MapReduceIndexerTool, it will usually pull a
{{solrconfig.xml}} from ZK for the collection that it is running against.
This can be problematic for several reasons:
* Performance: The configuration in ZK will likely have several query
handlers, and lots of other components that don't make sense in an
indexing-only use of EmbeddedSolrServer (ESS).
* Classpath Resources: If the Solr services are using some kind of additional
service (such as Sentry for auth) then the indexer will not have access to
the necessary configurations without the user jumping through several hoops.
* Distinct Configuration Needs: Enabling Soft Commits on the ESS doesn't make
sense. There's other configurations that
* Update Chain Behaviours: I'm under the impression that UpdateChains may
behave differently in ESS than a SolrCloud cluster. Is it safe to depend on
consistent behaviour here?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60-ea-b25) - Build # 13650 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13650/ Java: 64bit/jdk1.8.0_60-ea-b25 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC No tests ran. Build Log: [...truncated 305 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/branch_5x': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:759) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:371) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:359) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:710) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1032) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:143) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.createRepository(SvnRepositoryAccess.java:110) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepository(SvnNgRepositoryAccess.java:210) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:156) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:72) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:38) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:18) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:158) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:991) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948) at hudson.FilePath.act(FilePath.java:991) at hudson.FilePath.act(FilePath.java:969) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:833) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1277) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532) at hudson.model.Run.execute(Run.java:1741) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:381) ERROR: Subversion update failed java.io.IOException at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:212) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:991) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948) at hudson.FilePath.act(FilePath.java:991) at hudson.FilePath.act(FilePath.java:969) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:833) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1277) at
[JENKINS] Lucene-Solr-5.3-Linux (64bit/jdk1.8.0_51) - Build # 94 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.3-Linux/94/ Java: 64bit/jdk1.8.0_51 -XX:-UseCompressedOops -XX:+UseG1GC No tests ran. Build Log: [...truncated 14 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_3 org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: OPTIONS of '/repos/asf/lucene/dev/branches/lucene_solr_5_3': 403 Forbidden (http://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:759) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:371) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:359) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:710) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1032) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:143) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.createRepository(SvnRepositoryAccess.java:110) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepository(SvnNgRepositoryAccess.java:210) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:156) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:72) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:38) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:18) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:158) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:991) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948) at hudson.FilePath.act(FilePath.java:991) at hudson.FilePath.act(FilePath.java:969) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:833) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1277) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532) at hudson.model.Run.execute(Run.java:1741) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:381) ERROR: Subversion update failed java.io.IOException at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:212) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:991) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948) at hudson.FilePath.act(FilePath.java:991) at hudson.FilePath.act(FilePath.java:969) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:833) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1277) at
[jira] [Created] (SOLR-7943) Upgrade Jetty to 9.2.13
Bill Bell created SOLR-7943: --- Summary: Upgrade Jetty to 9.2.13 Key: SOLR-7943 URL: https://issues.apache.org/jira/browse/SOLR-7943 Project: Solr Issue Type: Bug Reporter: Bill Bell Let's patch Jetty to 9.2.13 http://repo1.maven.org/maven2/org/eclipse/jetty/jetty-distribution/9.2.13.v20150730/ -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7569) Create an API to force a leader election between nodes
[ https://issues.apache.org/jira/browse/SOLR-7569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701387#comment-14701387 ] Ishan Chattopadhyaya commented on SOLR-7569: Thanks [~markrmil...@gmail.com] for the pointer to the issues. I agree this is a sledge hammer to undo the effects of bugs, which shouldn't be needed if we go by an improved design. We have observed the effects of these bugs in production clusters of our clients, and this is to help them in such a scenario. Do you think we should continue down this sledge hammer path, parallel to fixing the bugs? Create an API to force a leader election between nodes -- Key: SOLR-7569 URL: https://issues.apache.org/jira/browse/SOLR-7569 Project: Solr Issue Type: New Feature Components: SolrCloud Reporter: Shalin Shekhar Mangar Labels: difficulty-medium, impact-high Attachments: SOLR-7569.patch There are many reasons why Solr will not elect a leader for a shard e.g. all replicas' last published state was recovery or due to bugs which cause a leader to be marked as 'down'. While the best solution is that they never get into this state, we need a manual way to fix this when it does get into this state. Right now we can do a series of dance involving bouncing the node (since recovery paths between bouncing and REQUESTRECOVERY are different), but that is difficult when running a large cluster. Although it is possible that such a manual API may lead to some data loss but in some cases, it is the only possible option to restore availability. This issue proposes to build a new collection API which can be used to force replicas into recovering a leader while avoiding data loss on a best effort basis. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7569) Create an API to force a leader election between nodes
[ https://issues.apache.org/jira/browse/SOLR-7569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701392#comment-14701392 ] Mark Miller commented on SOLR-7569: --- Yes, I think having this option is useful in the short term and in the longer term. The system will generally refuse to continue on if it thinks it may have data loss and stopping could allow a user to possibly recover that data. This could act as a way for a user to override that. Create an API to force a leader election between nodes -- Key: SOLR-7569 URL: https://issues.apache.org/jira/browse/SOLR-7569 Project: Solr Issue Type: New Feature Components: SolrCloud Reporter: Shalin Shekhar Mangar Labels: difficulty-medium, impact-high Attachments: SOLR-7569.patch There are many reasons why Solr will not elect a leader for a shard e.g. all replicas' last published state was recovery or due to bugs which cause a leader to be marked as 'down'. While the best solution is that they never get into this state, we need a manual way to fix this when it does get into this state. Right now we can do a series of dance involving bouncing the node (since recovery paths between bouncing and REQUESTRECOVERY are different), but that is difficult when running a large cluster. Although it is possible that such a manual API may lead to some data loss but in some cases, it is the only possible option to restore availability. This issue proposes to build a new collection API which can be used to force replicas into recovering a leader while avoiding data loss on a best effort basis. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
