[jira] [Created] (SOLR-6818) Delegating collector in Analytics API returns not right docNum in collect method
Daulet Kadirbekov created SOLR-6818: --- Summary: Delegating collector in Analytics API returns not right docNum in collect method Key: SOLR-6818 URL: https://issues.apache.org/jira/browse/SOLR-6818 Project: Solr Issue Type: Bug Affects Versions: 4.10.2 Reporter: Daulet Kadirbekov Delegating collector in Analytics API returns not right docNum in collect method. I have used Analytics API in my solr. I created ResourceAnalyticsCollector which extends DelegatingCollector class. In that class there is collect(int docNum) method. This is the continue of https://issues.apache.org/jira/browse/SOLR-6802 issue. The problem that I found that the docNum value is repeated in collect method of DelegatingCollector. -- 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-6802) Solr AnalyticsQuery API returns analytics by documents that don't match query
[ https://issues.apache.org/jira/browse/SOLR-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daulet Kadirbekov updated SOLR-6802: Attachment: Analytics_API_problem.rar Solr AnalyticsQuery API returns analytics by documents that don't match query - Key: SOLR-6802 URL: https://issues.apache.org/jira/browse/SOLR-6802 Project: Solr Issue Type: Bug Components: query parsers Affects Versions: 4.10.2 Reporter: Daulet Kadirbekov Priority: Critical Attachments: Analytics_API_problem.rar Solr AnalyticsQuery API returns analytics by documents that don't match query. Example: Solr query: domain:example.com I looked for all documents by /select search handler and all of this documents was belonged to example.com domain. But when I looked in analytics for documents, I have found that there are many documents which don't match query. But number of documents is the same. -- 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-6802) Solr AnalyticsQuery API returns analytics by documents that don't match query
[ https://issues.apache.org/jira/browse/SOLR-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14233997#comment-14233997 ] Daulet Kadirbekov commented on SOLR-6802: - I have found that the docNum value is repeated in collect method of DelegatingCollector. https://issues.apache.org/jira/browse/SOLR-6818 Solr AnalyticsQuery API returns analytics by documents that don't match query - Key: SOLR-6802 URL: https://issues.apache.org/jira/browse/SOLR-6802 Project: Solr Issue Type: Bug Components: query parsers Affects Versions: 4.10.2 Reporter: Daulet Kadirbekov Priority: Critical Attachments: Analytics_API_problem.rar Solr AnalyticsQuery API returns analytics by documents that don't match query. Example: Solr query: domain:example.com I looked for all documents by /select search handler and all of this documents was belonged to example.com domain. But when I looked in analytics for documents, I have found that there are many documents which don't match query. But number of documents is the same. -- 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-6675) Solr webapp deployment is very slow with jmx/ in solrconfig.xml
[ https://issues.apache.org/jira/browse/SOLR-6675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234034#comment-14234034 ] Forest Soup commented on SOLR-6675: --- This is our JVM. And we have never tried the latest Solr 4.10.x. Any idea on how to resolve or workaround it? Thanks! java version 1.7.0 Java(TM) SE Runtime Environment (build pxa6470sr6-20131015_01(SR6)) IBM J9 VM (build 2.6, JRE 1.7.0 Linux amd64-64 Compressed References 20131013_170512 (JIT enabled, AOT enabled) J9VM - R26_Java726_SR6_20131013_1510_B170512 JIT - r11.b05_20131003_47443 GC - R26_Java726_SR6_20131013_1510_B170512_CMPRSS J9CL - 20131013_170512) JCL - 20131011_01 based on Oracle 7u45-b18 Solr webapp deployment is very slow with jmx/ in solrconfig.xml - Key: SOLR-6675 URL: https://issues.apache.org/jira/browse/SOLR-6675 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.7 Environment: Linux Redhat 64bit Reporter: Forest Soup Priority: Critical Labels: performance Attachments: callstack.png We have a SolrCloud with Solr version 4.7 with Tomcat 7. And our solr index(cores) are big(50~100G) each core. When we start up tomcat, the solr webapp deployment is very slow. From tomcat's catalina log, every time it takes about 10 minutes to get deployed. After we analyzing java core dump, we notice it's because the loading process cannot finish until the MBean calculation for large index is done. So we tried to remove the jmx/ from solrconfig.xml, after that, the loading of solr webapp only take about 1 minute. So we can sure the MBean calculation for large index is the root cause. Could you please point me if there is any async way to do statistic monitoring without jmx/ in solrconfig.xml, or let it do calculation after the deployment? Thanks! The callstack.png file in the attachment is the call stack of the long blocking thread which is doing statistics calculation. The catalina log of tomcat: INFO: Starting Servlet Engine: Apache Tomcat/7.0.54 Oct 13, 2014 2:00:29 AM org.apache.catalina.startup.HostConfig deployWAR INFO: Deploying web application archive /opt/ibm/solrsearch/tomcat/webapps/solr.war Oct 13, 2014 2:10:23 AM org.apache.catalina.startup.HostConfig deployWAR INFO: Deployment of web application archive /opt/ibm/solrsearch/tomcat/webapps/solr.war has finished in 594,325 ms Time taken for solr app Deployment is about 10 minutes --- Oct 13, 2014 2:10:23 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory /opt/ibm/solrsearch/tomcat/webapps/manager Oct 13, 2014 2:10:26 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deployment of web application directory /opt/ibm/solrsearch/tomcat/webapps/manager has finished in 2,035 ms Oct 13, 2014 2:10:26 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory /opt/ibm/solrsearch/tomcat/webapps/examples Oct 13, 2014 2:10:27 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deployment of web application directory /opt/ibm/solrsearch/tomcat/webapps/examples has finished in 1,789 ms Oct 13, 2014 2:10:27 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory /opt/ibm/solrsearch/tomcat/webapps/docs Oct 13, 2014 2:10:28 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deployment of web application directory /opt/ibm/solrsearch/tomcat/webapps/docs has finished in 1,037 ms Oct 13, 2014 2:10:28 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory /opt/ibm/solrsearch/tomcat/webapps/ROOT Oct 13, 2014 2:10:29 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deployment of web application directory /opt/ibm/solrsearch/tomcat/webapps/ROOT has finished in 948 ms Oct 13, 2014 2:10:29 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory /opt/ibm/solrsearch/tomcat/webapps/host-manager Oct 13, 2014 2:10:30 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deployment of web application directory /opt/ibm/solrsearch/tomcat/webapps/host-manager has finished in 951 ms Oct 13, 2014 2:10:31 AM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler [http-bio-8080] Oct 13, 2014 2:10:31 AM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler [ajp-bio-8009] Oct 13, 2014 2:10:31 AM org.apache.catalina.startup.Catalina start INFO: Server startup in 601506 ms -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SOLR-4470) Support for basic http auth in internal solr requests
[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234046#comment-14234046 ] Forest Soup commented on SOLR-4470: --- Does anyone have an idea when this will be released? Thanks! Support for basic http auth in internal solr requests - Key: SOLR-4470 URL: https://issues.apache.org/jira/browse/SOLR-4470 Project: Solr Issue Type: New Feature Components: clients - java, multicore, replication (java), SolrCloud Affects Versions: 4.0 Reporter: Per Steffensen Assignee: Jan Høydahl Labels: authentication, https, solrclient, solrcloud, ssl Fix For: Trunk Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch, SOLR-4470_trunk_r1568857.patch We want to protect any HTTP-resource (url). We want to require credentials no matter what kind of HTTP-request you make to a Solr-node. It can faily easy be acheived as described on http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes also make internal request to other Solr-nodes, and for it to work credentials need to be provided here also. Ideally we would like to forward credentials from a particular request to all the internal sub-requests it triggers. E.g. for search and update request. But there are also internal requests * that only indirectly/asynchronously triggered from outside requests (e.g. shard creation/deletion/etc based on calls to the Collection API) * that do not in any way have relation to an outside super-request (e.g. replica synching stuff) We would like to aim at a solution where original credentials are forwarded when a request directly/synchronously trigger a subrequest, and fallback to a configured internal credentials for the asynchronous/non-rooted requests. In our solution we would aim at only supporting basic http auth, but we would like to make a framework around it, so that not to much refactoring is needed if you later want to make support for other kinds of auth (e.g. digest) We will work at a solution but create this JIRA issue early in order to get input/comments from the community as early as possible. -- This message was sent by Atlassian JIRA (v6.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-6683) Need a configurable parameter to control the doc number between peersync and the snapshot pull recovery
[ https://issues.apache.org/jira/browse/SOLR-6683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234052#comment-14234052 ] Forest Soup commented on SOLR-6683: --- Thanks, Ramkumar. We will try it. Thanks! Need a configurable parameter to control the doc number between peersync and the snapshot pull recovery --- Key: SOLR-6683 URL: https://issues.apache.org/jira/browse/SOLR-6683 Project: Solr Issue Type: Bug Components: replication (java) Affects Versions: 4.7 Environment: Redhat Linux 64bit Reporter: Forest Soup Priority: Critical Labels: performance If there are 100 docs gap between the recovering node and the good node, the solr will do snap pull recovery instead of peersync. Can the 100 docs be configurable? For example, there can be 1, 1000, or 10 docs gap between the good node and the node to recover. For 100 doc, a regular restart of a solr node will trigger a full recovery, which is a huge impact to the performance of the running systems Thanks! -- 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-5914) More options for stored fields compression
[ https://issues.apache.org/jira/browse/LUCENE-5914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234059#comment-14234059 ] Adrien Grand commented on LUCENE-5914: -- +1 thanks Robert. I am good with a constructor argument, the only reason why I initially added it as a protected method was to be consistent with postings and doc values formats. Regarding the patch, it just feels weird to me to have this {{Objects.requireNonNull(mode)}} validation in the {{Lucene50Codec(Mode)}} constructor, I would have expeced it to be solely the responsibility of the Lucene50StoredFieldsFormat constructor? More options for stored fields compression -- Key: LUCENE-5914 URL: https://issues.apache.org/jira/browse/LUCENE-5914 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Fix For: 5.0 Attachments: LUCENE-5914.patch, LUCENE-5914.patch, LUCENE-5914.patch, LUCENE-5914.patch, LUCENE-5914.patch, LUCENE-5914.patch, LUCENE-5914.patch Since we added codec-level compression in Lucene 4.1 I think I got about the same amount of users complaining that compression was too aggressive and that compression was too light. I think it is due to the fact that we have users that are doing very different things with Lucene. For example if you have a small index that fits in the filesystem cache (or is close to), then you might never pay for actual disk seeks and in such a case the fact that the current stored fields format needs to over-decompress data can sensibly slow search down on cheap queries. On the other hand, it is more and more common to use Lucene for things like log analytics, and in that case you have huge amounts of data for which you don't care much about stored fields performance. However it is very frustrating to notice that the data that you store takes several times less space when you gzip it compared to your index although Lucene claims to compress stored fields. For that reason, I think it would be nice to have some kind of options that would allow to trade speed for compression in the default codec. -- 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-6818) Delegating collector in Analytics API returns not right docNum in collect method
[ https://issues.apache.org/jira/browse/SOLR-6818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234064#comment-14234064 ] Alan Woodward commented on SOLR-6818: - docNum is per-segment. If you want to get a global value, you need to add this.docBase. Delegating collector in Analytics API returns not right docNum in collect method Key: SOLR-6818 URL: https://issues.apache.org/jira/browse/SOLR-6818 Project: Solr Issue Type: Bug Affects Versions: 4.10.2 Reporter: Daulet Kadirbekov Delegating collector in Analytics API returns not right docNum in collect method. I have used Analytics API in my solr. I created ResourceAnalyticsCollector which extends DelegatingCollector class. In that class there is collect(int docNum) method. This is the continue of https://issues.apache.org/jira/browse/SOLR-6802 issue. The problem that I found that the docNum value is repeated in collect method of DelegatingCollector. -- 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-4470) Support for basic http auth in internal solr requests
[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234089#comment-14234089 ] Per Steffensen commented on SOLR-4470: -- bq. Does anyone have an idea when this will be released? Thanks! My best guess is never, unfortunately. But you can build your own version of Solr including it. We do that. I can give you a few hints on how to build your own Solr, if you want. Do not have the time to give you a thorough description. But a few hints I will manage. Let me know. Do not know if it is actually described in details somewhere? Support for basic http auth in internal solr requests - Key: SOLR-4470 URL: https://issues.apache.org/jira/browse/SOLR-4470 Project: Solr Issue Type: New Feature Components: clients - java, multicore, replication (java), SolrCloud Affects Versions: 4.0 Reporter: Per Steffensen Assignee: Jan Høydahl Labels: authentication, https, solrclient, solrcloud, ssl Fix For: Trunk Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch, SOLR-4470_trunk_r1568857.patch We want to protect any HTTP-resource (url). We want to require credentials no matter what kind of HTTP-request you make to a Solr-node. It can faily easy be acheived as described on http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes also make internal request to other Solr-nodes, and for it to work credentials need to be provided here also. Ideally we would like to forward credentials from a particular request to all the internal sub-requests it triggers. E.g. for search and update request. But there are also internal requests * that only indirectly/asynchronously triggered from outside requests (e.g. shard creation/deletion/etc based on calls to the Collection API) * that do not in any way have relation to an outside super-request (e.g. replica synching stuff) We would like to aim at a solution where original credentials are forwarded when a request directly/synchronously trigger a subrequest, and fallback to a configured internal credentials for the asynchronous/non-rooted requests. In our solution we would aim at only supporting basic http auth, but we would like to make a framework around it, so that not to much refactoring is needed if you later want to make support for other kinds of auth (e.g. digest) We will work at a solution but create this JIRA issue early in order to get input/comments from the community as early as possible. -- This message was sent by Atlassian JIRA (v6.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-4470) Support for basic http auth in internal solr requests
[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234103#comment-14234103 ] Per Steffensen commented on SOLR-4470: -- But voting for it might help :-) Support for basic http auth in internal solr requests - Key: SOLR-4470 URL: https://issues.apache.org/jira/browse/SOLR-4470 Project: Solr Issue Type: New Feature Components: clients - java, multicore, replication (java), SolrCloud Affects Versions: 4.0 Reporter: Per Steffensen Assignee: Jan Høydahl Labels: authentication, https, solrclient, solrcloud, ssl Fix For: Trunk Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch, SOLR-4470_trunk_r1568857.patch We want to protect any HTTP-resource (url). We want to require credentials no matter what kind of HTTP-request you make to a Solr-node. It can faily easy be acheived as described on http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes also make internal request to other Solr-nodes, and for it to work credentials need to be provided here also. Ideally we would like to forward credentials from a particular request to all the internal sub-requests it triggers. E.g. for search and update request. But there are also internal requests * that only indirectly/asynchronously triggered from outside requests (e.g. shard creation/deletion/etc based on calls to the Collection API) * that do not in any way have relation to an outside super-request (e.g. replica synching stuff) We would like to aim at a solution where original credentials are forwarded when a request directly/synchronously trigger a subrequest, and fallback to a configured internal credentials for the asynchronous/non-rooted requests. In our solution we would aim at only supporting basic http auth, but we would like to make a framework around it, so that not to much refactoring is needed if you later want to make support for other kinds of auth (e.g. digest) We will work at a solution but create this JIRA issue early in order to get input/comments from the community as early as possible. -- This message was sent by Atlassian JIRA (v6.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-5987) Make indexwriter a mere mortal when exceptions strike
[ https://issues.apache.org/jira/browse/LUCENE-5987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-5987: --- Attachment: LUCENE-5987.patch Patch. I added new AbortIndexWriterException; it is package private, and is only used to communicate internally in IndexWriter (other approaches I tried kept leading to deadlock). I removed the andReset from DocumentsWriterPerThread.checkAndResetHasAborted: I think it's dangerous to ever set hasAborted back to false. It's like unplugging your carbon monoxide detector because it's making too much noise. This is an important behavior change. First off, an aborting exception, which is an exception that strikes at a bad time (e.g. when appending to stored fields or term vector files) such that the entire segment is now unusable, will now forcefully close the IndexWriter. This is so you know you lost any uncommitted data. Second off, when this happens, I don't think IndexWriter should try to be so crazy about deleting every last unref'd file when disaster strikes: if your house is burning down, you don't worry about washing the dirty dishes. This change made a number of tests angry (IW suddenly closing, and also leaving unref'd files), and I did distributed beasting to try to ferret them out, but I expect we'll have a long tail of Jenkins failures after committing this. Make indexwriter a mere mortal when exceptions strike - Key: LUCENE-5987 URL: https://issues.apache.org/jira/browse/LUCENE-5987 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Assignee: Michael McCandless Attachments: LUCENE-5987.patch IndexWriter's exception handling is overly complicated. Every method in general reads like this: {code} try { try { try { ... // lock order: COMPLICATED synchronized(this or that) { } ... } finally { if (!success5) { deleter.deleteThisFileOrThat(); } ... } } {code} Part of the problem is it acts like its an invincible superhero, e.g. can take a disk full on merge or flush to the face and just keep on trucking, and you can somehow fix the root cause and then just go about making commits on the same instance. But we have a hard enough time ensuring exceptions dont do the wrong thing (e.g. cause corruption), and I don't think we really test this crazy behavior anywhere: e.g. making commits AFTER hitting disk full and so on. It would probably be simpler if when such things happen, IW just considered them tragic just like OOM and rolled itself back, instead of doing all kinds of really scary stuff to try to keep itself healthy (like the little dance it plays with IFD in mergeMiddle manually deleting CFS files). Besides, without something like a WAL, Indexwriter isn't really fit to be a superhero anyway: it can't prevent you from losing data in such situations. It just doesn't have the right tools for the job. edit: just to be clear I am referring to abort (low level exception during flush) and exceptions during merge. For simple non-aborting cases like analyzer errors, of course we can deal with this. We already made great progress on turning a lot of BS exceptions that would cause aborts into non-aborting ones recently. -- 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-6810) Faster searching limited but high rows across many shards all with many hits
[ https://issues.apache.org/jira/browse/SOLR-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Per Steffensen updated SOLR-6810: - Attachment: branch_5x_rev1642874.patch Got in doubt how exactly the store-read-improvements would be when start-param is 0. Now {{TestDistributedQueryAlgorithm.testDocReads}} clearly show that. Besides that improved test-coverage for sort + start 0 queries in {{TestDistributedQueryAlgorithm}}. And better assert messages. Faster searching limited but high rows across many shards all with many hits Key: SOLR-6810 URL: https://issues.apache.org/jira/browse/SOLR-6810 Project: Solr Issue Type: Improvement Components: search Reporter: Per Steffensen Labels: distributed_search, performance Attachments: branch_5x_rev1642874.patch, branch_5x_rev1642874.patch Searching limited but high rows across many shards all with many hits is slow E.g. * Query from outside client: q=somethingrows=1000 * Resulting in sub-requests to each shard something a-la this ** 1) q=somethingrows=1000fl=id,score ** 2) Request the full documents with ids in the global-top-1000 found among the top-1000 from each shard What does the subject mean * limited but high rows means 1000 in the example above * many shards means 200-1000 in our case * all with many hits means that each of the shards have a significant number of hits on the query The problem grows on all three factors above Doing such a query on our system takes between 5 min to 1 hour - depending on a lot of things. It ought to be much faster, so lets make it. Profiling show that the problem is that it takes lots of time to access the store to get id’s for (up to) 1000 docs (value of rows parameter) per shard. Having 1000 shards its up to 1 mio ids that has to be fetched. There is really no good reason to ever read information from store for more than the overall top-1000 documents, that has to be returned to the client. For further detail see mail-thread Slow searching limited but high rows across many shards all with high hits started 13/11-2014 on dev@lucene.apache.org -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-6810) Faster searching limited but high rows across many shards all with many hits
[ https://issues.apache.org/jira/browse/SOLR-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14232772#comment-14232772 ] Per Steffensen edited comment on SOLR-6810 at 12/4/14 10:59 AM: We have solved the problem (reducing response-time by a factor of 60 on our particular system/data/distribution) the following way Introduced the concept of distributed query algorithm (DQA) controlled by request parameter {{dqa}}. Naming the existing (default) distributed query algorithm {{find-id-relevance_fetch-by-ids}} (short-alias {{firfbi}}) and introducing a new alternative distributed query algorithm called {{find-relevance_find-ids-limited-rows_fetch-by-ids}} (short-alias {{frfilrfbi}}) * {{find-id-relevance_fetch-by-ids}} does as always - see JavaDoc of {{ShardParams.FIND_ID_RELEVANCE_FETCH_BY_IDS}} * {{find-relevance_find-ids-limited-rows_fetch-by-ids}} does it in a different way - see JavaDoc of {{ShardParams.FIND_RELEVANCE_FIND_IDS_LIMITED_ROWS_FETCH_BY_IDS}} Believe “distributed query algorithm” is a pendant to elasticsearch's “search type”, but just with much better naming that say something about what it is actually controlling :-) Both DQAs support the {{disturb.singlePass}} flag. I have *renamed* it to {{dqa.forceSkipGetIds}} because it is only {{find-id-relevance_fetch-by-ids}} that becomes single-pass (going from 2 to 1 pass) with this flag. {{find-relevance_find-ids-limited-rows_fetch-by-ids}} goes from 3 to 2 passes. {{dqa.forceSkipGetIds=true}} is default for {{find-relevance_find-ids-limited-rows_fetch-by-ids}}. Attaching patch corresponding to our solution - going into production as we speak to reduce our response-times by a factor of 60. You do not necessarily need to just adopt it. But lets at least consider it a starting-point for a discussion. Details about the patch * {{ShardParams.DQA}}: Enum of the DQA’s, including different helper methods that IMHO belongs here * {{QueryComponent}}/{{ResponseBuilder}}: Changed to implement both DQA’s now * {{SolrIndexSearcher.doc}}: Does not go to store, if only asking for score. This is important for the optimization * {{TestIndexSearcher}}: Added a test to test this particular new aspect of {{SolrIndexSearcher}} * {{TestDistributedQueryAlgorithm}}: A new test-class dedicated tests of DQA’s. {{testDocReads}}-test really shows exactly what this new DQA does for you. Test asserts that you only go to store X times across the cluster and not (up to) #shards * X times (X = rows in outer query) * {{LeafReaderTestWrappers}}: Test-wrappers for {{LeafReader}} s. Can help collecting information about how {{LeafReader}} s are used in different test-scenarios. Used by {{TestIndexSearcher}}. Can be extended with other kinds of wrappers that collect different kinds of information. * {{SolrIndexSearcherTestWrapper}} and {{SolrCoreTestWrapper}}. Generic classes that can help wrapping all {{LeafReader}} s under a {{SolrIndexSearcher}} or a {{SolrCore}} respectively. Used by {{TestDistributedQueryAlgorithm}} * {{DistributedQueryComponentOptimizationTest}}: Updated with new tests around DQA’s. And made more systematic in the way the tests are performed. Do not want to add hundreds of almost similar code-lines * {{ShardRoutingTest}}: Same comments as for {{DistributedQueryComponentOptimizationTest}} above * {{SolrTestCaseJ4}}: Randomly selecting a DQA for each individual query fired running the test-suite - when you do not specify which DQA you want explicitly in the request. With helper-methods for fixing the DQA for tests that focus on DQA testing * Fix for SOLR-6812 is included in the patch because it is need to keep the test-suite green. But should probably be committed as part of SOLR-6812, and left out of this SOLR-6810. New DQA ({{find-relevance_find-ids-limited-rows_fetch-by-ids}}) has {{dqa.forceSkipGetIds}} (old {{disturb.singlePass}}) set to true by default. And since we run tests randomly selecting the DQA for every query, we are also indirectly randoming {{dqa.forceSkipGetIds}}. Therefore the test-suite will likely fail if skip-get-ids does not work for all kinds of requests. This is actually also a good way to have {{dqa.forceSkipGetIds}} (old {{distrib.singlePass}}) tested, so that we will not have a partially-working feature (as before SOLR-6795/SOLR-6796/SOLR-6812/SOLR-6813). The tests added to {{DistributedQueryComponentOptimizationTest}} in SOLR-6795 and SOLR-6796 have been removed again, because the problems (along with any other problems with {{dqa.forceSkipGetIds}}) will now (potentially) be revealed anyway because of indirect randomized testing of {{dqa.forceSkipGetIds}} * I do not have a solution to SOLR-6813, so temporarily making sure that it will not make the test-suite fail, by forcing the particular query in {{DistributedExpandComponentTest}} to use
[jira] [Commented] (SOLR-4470) Support for basic http auth in internal solr requests
[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234132#comment-14234132 ] Shai Erera commented on SOLR-4470: -- Hi Per. I've skimmed briefly through the history of this issue, but didn't read it thoroughly. I noticed that some of the comments were around the size of the patch. I tend to agree with such comments in general, although sometimes a patch just needs to be big. Reviewing the patch _very_ briefly, I noticed that there are many changes due to the addition of authCredentials to SolrServer API methods (I counted around 600+ lines in the patch, which is ~10%). I have few questions about that: * Is it correct that every SolrServer can handle authCredentials? And not e.g. only HttpSolrServer. * Is it mandatory to nearly double the API with this extra parameter? I guess this is a general question about usability of the update API. We could probably refactor things to look more friendly, e.g. introduce an UpdateRequest with fluid interface, something like: {{UpdateRequest.add().doc(doc).commitWithin(-1).authCredentials(creds)}}. Then SolrServer would just have a single .execute() method which takes an UpdateRequest and processes it. ** This change is unrelated to this issue, but if we do this separately, it might simplify this patch a bit. ** Even without refactoring though, I wonder if we cannot just tell people who need to set authCredentials to build and UpdateRequest themselves, since I assume this code path won't be that common among our users. Then we don't put the authCredentials in the face of all users. On a personal note, even if I wanted to help you get this committed, it's impossible for me to digest and decently review a 6300 lines patch. I think we ought to be able to break it down into smaller manageable commits. For example, can we add basicAuth to Solr/Cloud separately from Solrj? Yes, perhaps it will be more usable for Solrj users, but it doesn't mean it has to go in the same commit. And on another note, I share your view about the need to modernize (pretty word for 'refactoring') the Solr API, but I think it will be accepted better if we do this piecemeal. For instance, if we want to improve SolrServer API (by adding this fluid UpdateRequest), we can start with writing UpdateRequest2 with the fluid API that we think it should have. We should even be able to commit it (gradually), since at first it won't be used by the server. We then make a series of commits (this is just an example): # Add UpdateRequest2 with addDocuments support # Add rollback to UpdateRequest2 # Add AuthCredentials # Add # Add SolrServer.execute(UpdateRequest2) After everything works well and is properly tested, and especially after that last commit, we can rip out UpdateRequest in exchange for UpdateRequest2. I personally wish we didn't need to do all the API back-compat, but this should be an easy change -- deprecate everything on 5x, remove on trunk and delegate all 5x deprecated APIs to UpdateRequest2. BTW, I don't propose to stick w/ UpdateRequest2, it's just an example :). Not that I expect you to do all this, but I think if e.g. the API looked like that, then adding authCredentials to Solrj would be much easier, and looked 'cleaner'. Support for basic http auth in internal solr requests - Key: SOLR-4470 URL: https://issues.apache.org/jira/browse/SOLR-4470 Project: Solr Issue Type: New Feature Components: clients - java, multicore, replication (java), SolrCloud Affects Versions: 4.0 Reporter: Per Steffensen Assignee: Jan Høydahl Labels: authentication, https, solrclient, solrcloud, ssl Fix For: Trunk Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch, SOLR-4470_trunk_r1568857.patch We want to protect any HTTP-resource (url). We want to require credentials no matter what kind of HTTP-request you make to a Solr-node. It can faily easy be acheived as described on http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes also make internal request to other Solr-nodes, and for it to work credentials need to be provided here also. Ideally we would like to forward credentials from a particular request to all the internal sub-requests it triggers. E.g. for search and update request. But there are also internal requests * that only indirectly/asynchronously triggered from outside requests (e.g. shard creation/deletion/etc based on calls to the
[jira] [Resolved] (SOLR-6818) Delegating collector in Analytics API returns not right docNum in collect method
[ https://issues.apache.org/jira/browse/SOLR-6818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daulet Kadirbekov resolved SOLR-6818. - Resolution: Fixed docNum is per-segment. If you want to get a global value, you need to add this.docBase. Delegating collector in Analytics API returns not right docNum in collect method Key: SOLR-6818 URL: https://issues.apache.org/jira/browse/SOLR-6818 Project: Solr Issue Type: Bug Affects Versions: 4.10.2 Reporter: Daulet Kadirbekov Delegating collector in Analytics API returns not right docNum in collect method. I have used Analytics API in my solr. I created ResourceAnalyticsCollector which extends DelegatingCollector class. In that class there is collect(int docNum) method. This is the continue of https://issues.apache.org/jira/browse/SOLR-6802 issue. The problem that I found that the docNum value is repeated in collect method of DelegatingCollector. -- 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-6818) Delegating collector in Analytics API returns not right docNum in collect method
[ https://issues.apache.org/jira/browse/SOLR-6818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daulet Kadirbekov closed SOLR-6818. --- Delegating collector in Analytics API returns not right docNum in collect method Key: SOLR-6818 URL: https://issues.apache.org/jira/browse/SOLR-6818 Project: Solr Issue Type: Bug Affects Versions: 4.10.2 Reporter: Daulet Kadirbekov Delegating collector in Analytics API returns not right docNum in collect method. I have used Analytics API in my solr. I created ResourceAnalyticsCollector which extends DelegatingCollector class. In that class there is collect(int docNum) method. This is the continue of https://issues.apache.org/jira/browse/SOLR-6802 issue. The problem that I found that the docNum value is repeated in collect method of DelegatingCollector. -- 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-6802) Solr AnalyticsQuery API returns analytics by documents that don't match query
[ https://issues.apache.org/jira/browse/SOLR-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daulet Kadirbekov closed SOLR-6802. --- In DelegateCollector class in method collect docNum value is per-segment. If you want to get a global value, you need to add this.docBase. Document doc = indexSearcher.doc(docNum + this.docBase) Solr AnalyticsQuery API returns analytics by documents that don't match query - Key: SOLR-6802 URL: https://issues.apache.org/jira/browse/SOLR-6802 Project: Solr Issue Type: Bug Components: query parsers Affects Versions: 4.10.2 Reporter: Daulet Kadirbekov Priority: Critical Attachments: Analytics_API_problem.rar Solr AnalyticsQuery API returns analytics by documents that don't match query. Example: Solr query: domain:example.com I looked for all documents by /select search handler and all of this documents was belonged to example.com domain. But when I looked in analytics for documents, I have found that there are many documents which don't match query. But number of documents is the same. -- 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] [Resolved] (SOLR-6802) Solr AnalyticsQuery API returns analytics by documents that don't match query
[ https://issues.apache.org/jira/browse/SOLR-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daulet Kadirbekov resolved SOLR-6802. - Resolution: Fixed In DelegateCollector class in method collect docNum value is per-segment. If you want to get a global value, you need to add this.docBase. Document doc = indexSearcher.doc(docNum + this.docBase) Solr AnalyticsQuery API returns analytics by documents that don't match query - Key: SOLR-6802 URL: https://issues.apache.org/jira/browse/SOLR-6802 Project: Solr Issue Type: Bug Components: query parsers Affects Versions: 4.10.2 Reporter: Daulet Kadirbekov Priority: Critical Attachments: Analytics_API_problem.rar Solr AnalyticsQuery API returns analytics by documents that don't match query. Example: Solr query: domain:example.com I looked for all documents by /select search handler and all of this documents was belonged to example.com domain. But when I looked in analytics for documents, I have found that there are many documents which don't match query. But number of documents is the same. -- 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-6819) Being able to configure the updates log implementation from solrconfig.xml
Renaud Delbru created SOLR-6819: --- Summary: Being able to configure the updates log implementation from solrconfig.xml Key: SOLR-6819 URL: https://issues.apache.org/jira/browse/SOLR-6819 Project: Solr Issue Type: Improvement Components: SolrCloud, update Affects Versions: Trunk Reporter: Renaud Delbru CDCR requires its own implementation of the updates log. At the moment, there is no way to configure the class to use when instantiating the updates log. The UpdateHandler is deciding to instantiate the base class UpdateLog or its hdfs version HdfsUpdateLog based on the directory path prefix. We can extend the UpdateHandler to allow for a class parameter to be defined for the updateLog section of the solrconfig.xml. For example, the relevant part of the solrconfig,xml will look like: {code:xml} updateHandler class=solr.DirectUpdateHandler2 updateLog class=solr.CdcrUpdateLog str name=dir${solr.ulog.dir:}/str /updateLog /updateHandler {code} where the updateLog entry has a parameter class that indicates that the CdcrUpdateLog implementation must be used. -- 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-5987) Make indexwriter a mere mortal when exceptions strike
[ https://issues.apache.org/jira/browse/LUCENE-5987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234137#comment-14234137 ] Robert Muir commented on LUCENE-5987: - awesome! Can we shorten the name of the exception? I don't like AbortIndexWriterException for an internal one, i think its too complicated. Can it either be AbortingException or IndexWriter.AbortingException? Can we use try-multi-catch instead of java 1.6-style? I will take a deeper look after coffee. Make indexwriter a mere mortal when exceptions strike - Key: LUCENE-5987 URL: https://issues.apache.org/jira/browse/LUCENE-5987 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Assignee: Michael McCandless Attachments: LUCENE-5987.patch IndexWriter's exception handling is overly complicated. Every method in general reads like this: {code} try { try { try { ... // lock order: COMPLICATED synchronized(this or that) { } ... } finally { if (!success5) { deleter.deleteThisFileOrThat(); } ... } } {code} Part of the problem is it acts like its an invincible superhero, e.g. can take a disk full on merge or flush to the face and just keep on trucking, and you can somehow fix the root cause and then just go about making commits on the same instance. But we have a hard enough time ensuring exceptions dont do the wrong thing (e.g. cause corruption), and I don't think we really test this crazy behavior anywhere: e.g. making commits AFTER hitting disk full and so on. It would probably be simpler if when such things happen, IW just considered them tragic just like OOM and rolled itself back, instead of doing all kinds of really scary stuff to try to keep itself healthy (like the little dance it plays with IFD in mergeMiddle manually deleting CFS files). Besides, without something like a WAL, Indexwriter isn't really fit to be a superhero anyway: it can't prevent you from losing data in such situations. It just doesn't have the right tools for the job. edit: just to be clear I am referring to abort (low level exception during flush) and exceptions during merge. For simple non-aborting cases like analyzer errors, of course we can deal with this. We already made great progress on turning a lot of BS exceptions that would cause aborts into non-aborting ones recently. -- 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-5914) More options for stored fields compression
[ https://issues.apache.org/jira/browse/LUCENE-5914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234141#comment-14234141 ] Robert Muir commented on LUCENE-5914: - I want the null check robust to code changes. Both classes are public. I am afraid someone will remove them thinking it makes something faster. We should add tests for this too. More options for stored fields compression -- Key: LUCENE-5914 URL: https://issues.apache.org/jira/browse/LUCENE-5914 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Fix For: 5.0 Attachments: LUCENE-5914.patch, LUCENE-5914.patch, LUCENE-5914.patch, LUCENE-5914.patch, LUCENE-5914.patch, LUCENE-5914.patch, LUCENE-5914.patch Since we added codec-level compression in Lucene 4.1 I think I got about the same amount of users complaining that compression was too aggressive and that compression was too light. I think it is due to the fact that we have users that are doing very different things with Lucene. For example if you have a small index that fits in the filesystem cache (or is close to), then you might never pay for actual disk seeks and in such a case the fact that the current stored fields format needs to over-decompress data can sensibly slow search down on cheap queries. On the other hand, it is more and more common to use Lucene for things like log analytics, and in that case you have huge amounts of data for which you don't care much about stored fields performance. However it is very frustrating to notice that the data that you store takes several times less space when you gzip it compared to your index although Lucene claims to compress stored fields. For that reason, I think it would be nice to have some kind of options that would allow to trade speed for compression in the default codec. -- 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-6816) Review SolrCloud Indexing Performance.
[ https://issues.apache.org/jira/browse/SOLR-6816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234145#comment-14234145 ] Per Steffensen commented on SOLR-6816: -- Just want to add my 5 cents on this one. It is only regarding indexing when you do version-check/optimistic-locking (SOLR-3178). We have a very different implementation of SOLR-3178, but the performance problems will be the same for your implementation. Doing optimistic-locking you typically do a lot of this * 1) real-time-get document D from Solr * 2) update D to D' locally on client * 3) try to replace D with D' in Solr. In case of version-conflict-error go to 1) In step 1) you get-by-id document D, and I step 3) you UpdateLog.lookupVersion on the same id. In our system it is most likely that two processes, both wanting to update document D, run at the same time or fairly shortly after each other. It is rare that the same document gets updated a long time apart. In order to speed up on those aspects, we have introduced a recently looked-up or updated cache, where we store documents that has recently been fetch by real-time-get or updated. It has improved our indexing speed significantly. We have a mature solution that is running in production. In the scenarios above you most often discover that the document you try to real-time-get or lookup-version for does NOT exist, but it is relatively time-consuming to realize that (looking in index). We have a PoC of introducing a bloom-filter that can help say one of document definitely does not exist (you do not have to search the index) or document may exist (you will have to search the index to see if it exists). Our PoC shows that this will speed up our indexing-speed tremendously (like 60-80% reduction), but we havnt prioritized to mature and put it into production yet. The PoC was using a modified version of Guava bloom-filter - modified to be able work in a memory-mapped file, so that we do not lose bloom-filter information when shutting down Solr (it will take some time building it from scratch every time you start Solr). Guava bloom-filter currently is memory only - you can save it to file and load it again, but it will not go on continuously, and it is not efficient to store it completely to disk at every update :-) Hence the work in memory-mapped file modification. Review SolrCloud Indexing Performance. -- Key: SOLR-6816 URL: https://issues.apache.org/jira/browse/SOLR-6816 Project: Solr Issue Type: Task Components: SolrCloud Reporter: Mark Miller Priority: Critical Attachments: SolrBench.pdf We have never really focused on indexing performance, just correctness and low hanging fruit. We need to vet the performance and try to address any holes. Note: A common report is that adding any replication is very slow. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-6816) Review SolrCloud Indexing Performance.
[ https://issues.apache.org/jira/browse/SOLR-6816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234145#comment-14234145 ] Per Steffensen edited comment on SOLR-6816 at 12/4/14 12:11 PM: Just want to add my 5 cents on this one. It is only regarding indexing when you do version-check/optimistic-locking (SOLR-3178). We have a very different implementation of SOLR-3178, but the performance problems will be the same for your implementation. Doing optimistic-locking you typically do a lot of this * 1) real-time-get document D from Solr * 2) update D to D' locally on client * 3) try to replace D with D' in Solr. In case of version-conflict-error go to 1) In step 1) you get-by-id document D, and I step 3) you UpdateLog.lookupVersion on the same id. In our system it is most likely that two processes, both wanting to update document D, run at the same time or fairly shortly after each other. It is rare that the same document gets updated a long time apart. In order to speed up on those aspects, we have introduced a recently looked-up or updated cache, where we store documents that has recently been fetch by real-time-get or updated. It has improved our indexing speed significantly. We have a mature solution that is running in production. In the scenarios above you most often discover that the document you try to real-time-get or lookup-version for does NOT exist, but it is relatively time-consuming to realize that (looking in index). We have a PoC of introducing a bloom-filter that can help say one of document definitely does not exist (you do not have to search the index) or document may exist (you will have to search the index to see if it exists). Our PoC shows that this will speed up our indexing-speed tremendously (like 60-80% reduction), but we havnt prioritized to mature and put it into production yet. The PoC was using a modified version of Guava bloom-filter - modified to be able work in a memory-mapped file, so that we do not lose bloom-filter information when shutting down Solr (it will take some time building it from scratch every time you start Solr). Guava bloom-filter currently is memory only - you can save it to file and load it again, but it will not go on continuously, and it is not efficient to store it completely to disk at every update :-) Hence the work in memory-mapped file modification. Of course, let me know if any of this sounds interesting to you. was (Author: steff1193): Just want to add my 5 cents on this one. It is only regarding indexing when you do version-check/optimistic-locking (SOLR-3178). We have a very different implementation of SOLR-3178, but the performance problems will be the same for your implementation. Doing optimistic-locking you typically do a lot of this * 1) real-time-get document D from Solr * 2) update D to D' locally on client * 3) try to replace D with D' in Solr. In case of version-conflict-error go to 1) In step 1) you get-by-id document D, and I step 3) you UpdateLog.lookupVersion on the same id. In our system it is most likely that two processes, both wanting to update document D, run at the same time or fairly shortly after each other. It is rare that the same document gets updated a long time apart. In order to speed up on those aspects, we have introduced a recently looked-up or updated cache, where we store documents that has recently been fetch by real-time-get or updated. It has improved our indexing speed significantly. We have a mature solution that is running in production. In the scenarios above you most often discover that the document you try to real-time-get or lookup-version for does NOT exist, but it is relatively time-consuming to realize that (looking in index). We have a PoC of introducing a bloom-filter that can help say one of document definitely does not exist (you do not have to search the index) or document may exist (you will have to search the index to see if it exists). Our PoC shows that this will speed up our indexing-speed tremendously (like 60-80% reduction), but we havnt prioritized to mature and put it into production yet. The PoC was using a modified version of Guava bloom-filter - modified to be able work in a memory-mapped file, so that we do not lose bloom-filter information when shutting down Solr (it will take some time building it from scratch every time you start Solr). Guava bloom-filter currently is memory only - you can save it to file and load it again, but it will not go on continuously, and it is not efficient to store it completely to disk at every update :-) Hence the work in memory-mapped file modification. Review SolrCloud Indexing Performance. -- Key: SOLR-6816 URL: https://issues.apache.org/jira/browse/SOLR-6816 Project: Solr Issue Type:
[JENKINS-MAVEN] Lucene-Solr-Maven-5.x #777: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-5.x/777/ No tests ran. Build Log: [...truncated 249 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.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) 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:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_20) - Build # 11546 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11546/ Java: 64bit/jdk1.8.0_20 -XX:+UseCompressedOops -XX:+UseSerialGC (asserts: false) All tests passed Build Log: [...truncated 4094 lines...] [javac] Compiling 67 source files to /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/queries/classes/java [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/FunctionQuery.java:66: warning: [rawtypes] found raw type: Map [javac] protected final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:43: warning: [rawtypes] found raw type: Map [javac] public abstract FunctionValues getValues(Map context, LeafReaderContext readerContext) throws IOException; [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:67: warning: [rawtypes] found raw type: Map [javac] public void createWeight(Map context, IndexSearcher searcher) throws IOException { [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:73: warning: [rawtypes] found raw type: Map [javac] public static Map newContext(IndexSearcher searcher) { [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: Map [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: IdentityHashMap [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class IdentityHashMapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in class IdentityHashMap [javac] V extends Object declared in class IdentityHashMap [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:75: warning: [unchecked] unchecked call to put(K,V) as a member of the raw type Map [javac] context.put(searcher, searcher); [javac]^ [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:104: warning: [rawtypes] found raw type: Map [javac] Map context = newContext(searcher); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:111: warning: [rawtypes] found raw type: Map [javac] private final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac]
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2278 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2278/ No tests ran. Build Log: [...truncated 3 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.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) 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:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2276 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2276/ No tests ran. Build Log: [...truncated 3 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.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) 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:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2274 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2274/ No tests ran. Build Log: [...truncated 3 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.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) 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:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:514)
[JENKINS-MAVEN] Lucene-Solr-Maven-5.x #776: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-5.x/776/ 3 tests failed. FAILED: org.apache.solr.hadoop.MorphlineGoLiveMiniMRTest.org.apache.solr.hadoop.MorphlineGoLiveMiniMRTest Error Message: null Stack Trace: java.lang.AssertionError: null at __randomizedtesting.SeedInfo.seed([99CB6F9371CAC879]:0) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.before(TestRuleTemporaryFilesCleanup.java:105) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.before(TestRuleAdapter.java:26) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:35) 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.hadoop.MorphlineBasicMiniMRTest.testPathParts Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([E39FDBC09D1F3032]:0) FAILED: org.apache.solr.hadoop.MorphlineBasicMiniMRTest.org.apache.solr.hadoop.MorphlineBasicMiniMRTest Error Message: Suite timeout exceeded (= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (= 720 msec). at __randomizedtesting.SeedInfo.seed([E39FDBC09D1F3032]:0) Build Log: [...truncated 53834 lines...] BUILD FAILED /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:552: The following error occurred while executing this line: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:204: The following error occurred while executing this line: : Java returned: 1 Total time: 360 minutes 54 seconds Build step 'Invoke Ant' marked build as failure Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 1974 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1974/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC (asserts: true) All tests passed Build Log: [...truncated 58435 lines...] -documentation-lint: [jtidy] Checking for broken html (such as invalid tags)... [delete] Deleting directory /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/jtidy_tmp [echo] Checking for broken links... [exec] [exec] Crawl/parse... [exec] [exec] Verify... [exec] [exec] file:///Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/docs/solr-dataimporthandler/org/apache/solr/handler/dataimport/EntityProcessorBase.html [exec] BROKEN LINK: file:///Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/docs/solr-core/org/apache/solr/handler/dataimport.Zipper.html [exec] BROKEN LINK: file:///Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/docs/solr-core/org/apache/solr/handler/dataimport.Zipper.html [exec] [exec] Broken javadocs links were found! BUILD FAILED /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/build.xml:519: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/build.xml:83: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build.xml:554: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build.xml:567: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/common-build.xml:2388: exec returned: 1 Total time: 208 minutes 31 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC (asserts: true) Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Running tests incrementally based on changed files
that is a great suggestion. Maybe the following failure of today http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1927/ and in particular http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1927/testReport/junit/org.apache.solr.cloud/OverseerStatusTest/testDistribSearch/ illustrates better why I think that we could be more efficient detecting issues and how this relates to your suggestion. IIUC the build took 3 hours and 11 minutes on Mac OS X virtual box and then the failure happened. If we would have the association between the file changes and the tests, then we quite probably could detect such failures much quicker and hence get it fixed much quicker. If there is no failure for such associated tests, then we could still run the whole test suite, to make sure that we have not missed any dependencies for whatever reason. I will try to get some prototype running, please apologize if I might ask stupid questions on my way. Thanks Michael Am 03.12.14 um 15:08 schrieb Alexandre Rafalovitch: On 2 December 2014 at 18:10, Shawn Heisey apa...@elyograg.org wrote: The test dependency tree for this particular class is *EXTENSIVE* and not very easy to track down. How about a black box approach? Run each test individually once with a debugging interface enabled and the code that records every class load and every file system access. That's very similar to what JRebel does. Each test run is a Solr document. The loaded classes/files are multivalued fields. Dump into standalone Solr. Then, when the file changes, search by it's name/location and get back the list of tests that ever touched it. There are some complications due to randomised tests and also due to changed code possibly invoking new code path, but the core idea could probably be prototyped in a day or so to see if it has legts. Regards, Alex. Personal: http://www.outerthoughts.com/ and @arafalov Solr resources and newsletter: http://www.solr-start.com/ and @solrstart Solr popularizers community: https://www.linkedin.com/groups?gid=6713853 - 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
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2272 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2272/ No tests ran. Build Log: [...truncated 3 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.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) 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:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:514)
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2275 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2275/ No tests ran. Build Log: [...truncated 3 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.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) 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:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at
[jira] [Updated] (LUCENE-5987) Make indexwriter a mere mortal when exceptions strike
[ https://issues.apache.org/jira/browse/LUCENE-5987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-5987: Attachment: LUCENE-5987.patch Here is patch with my suggestions. I didn't like having two tragicEvent methods on IndexWriter, to me thats confusing. so the single one just unboxes AbortingException and there is one codepath to worry about there, and for each case. I am still confused about the logic in various places in DocumentsWriter (I didnt try to tackle this here). It seems wierd we are both catching exception/handlign stuff in finally block but then asking the dwpt if it has aborted. Is there a cleaner way? I am happy AbortingException is a checked one, its a good use here. Its fine if it nests in IndexWriter.java to be clear too. But its already a terminology used in the codebase so i think its the right name. Make indexwriter a mere mortal when exceptions strike - Key: LUCENE-5987 URL: https://issues.apache.org/jira/browse/LUCENE-5987 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Assignee: Michael McCandless Attachments: LUCENE-5987.patch, LUCENE-5987.patch IndexWriter's exception handling is overly complicated. Every method in general reads like this: {code} try { try { try { ... // lock order: COMPLICATED synchronized(this or that) { } ... } finally { if (!success5) { deleter.deleteThisFileOrThat(); } ... } } {code} Part of the problem is it acts like its an invincible superhero, e.g. can take a disk full on merge or flush to the face and just keep on trucking, and you can somehow fix the root cause and then just go about making commits on the same instance. But we have a hard enough time ensuring exceptions dont do the wrong thing (e.g. cause corruption), and I don't think we really test this crazy behavior anywhere: e.g. making commits AFTER hitting disk full and so on. It would probably be simpler if when such things happen, IW just considered them tragic just like OOM and rolled itself back, instead of doing all kinds of really scary stuff to try to keep itself healthy (like the little dance it plays with IFD in mergeMiddle manually deleting CFS files). Besides, without something like a WAL, Indexwriter isn't really fit to be a superhero anyway: it can't prevent you from losing data in such situations. It just doesn't have the right tools for the job. edit: just to be clear I am referring to abort (low level exception during flush) and exceptions during merge. For simple non-aborting cases like analyzer errors, of course we can deal with this. We already made great progress on turning a lot of BS exceptions that would cause aborts into non-aborting ones recently. -- 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.9.0-ea-b34) - Build # 11541 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11541/ Java: 64bit/jdk1.9.0-ea-b34 -XX:+UseCompressedOops -XX:+UseG1GC (asserts: true) 1 tests failed. FAILED: org.apache.lucene.analysis.icu.TestICUNormalizer2CharFilter.testRandomStrings Error Message: startOffset 482 expected:3289 but was:3290 Stack Trace: java.lang.AssertionError: startOffset 482 expected:3289 but was:3290 at __randomizedtesting.SeedInfo.seed([95BDEACE4A225CB7:1D34EA70E9260B82]: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.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:182) at org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:295) at org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:299) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:815) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:614) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:512) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:436) at org.apache.lucene.analysis.icu.TestICUNormalizer2CharFilter.testRandomStrings(TestICUNormalizer2CharFilter.java:189) 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:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java: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:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at 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
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 1973 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1973/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC (asserts: true) All tests passed Build Log: [...truncated 58440 lines...] -documentation-lint: [jtidy] Checking for broken html (such as invalid tags)... [delete] Deleting directory /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/jtidy_tmp [echo] Checking for broken links... [exec] [exec] Crawl/parse... [exec] [exec] Verify... [exec] [exec] file:///Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/docs/solr-dataimporthandler/org/apache/solr/handler/dataimport/EntityProcessorBase.html [exec] BROKEN LINK: file:///Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/docs/solr-core/org/apache/solr/handler/dataimport.Zipper.html [exec] BROKEN LINK: file:///Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/docs/solr-core/org/apache/solr/handler/dataimport.Zipper.html [exec] [exec] Broken javadocs links were found! BUILD FAILED /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/build.xml:519: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/build.xml:83: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build.xml:554: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build.xml:567: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/common-build.xml:2388: exec returned: 1 Total time: 214 minutes 48 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC (asserts: true) Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 1972 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1972/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC (asserts: false) All tests passed Build Log: [...truncated 58454 lines...] -documentation-lint: [jtidy] Checking for broken html (such as invalid tags)... [delete] Deleting directory /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/jtidy_tmp [echo] Checking for broken links... [exec] [exec] Crawl/parse... [exec] [exec] Verify... [exec] [exec] file:///Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/docs/solr-dataimporthandler/org/apache/solr/handler/dataimport/EntityProcessorBase.html [exec] BROKEN LINK: file:///Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/docs/solr-core/org/apache/solr/handler/dataimport.Zipper.html [exec] BROKEN LINK: file:///Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/docs/solr-core/org/apache/solr/handler/dataimport.Zipper.html [exec] [exec] Broken javadocs links were found! BUILD FAILED /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/build.xml:519: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/build.xml:83: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build.xml:554: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build.xml:567: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/common-build.xml:2388: exec returned: 1 Total time: 212 minutes 16 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC (asserts: false) Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - 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_40-ea-b09) - Build # 11547 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11547/ Java: 64bit/jdk1.8.0_40-ea-b09 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC (asserts: false) All tests passed Build Log: [...truncated 4096 lines...] [javac] Compiling 67 source files to /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/queries/classes/java [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/FunctionQuery.java:66: warning: [rawtypes] found raw type: Map [javac] protected final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:43: warning: [rawtypes] found raw type: Map [javac] public abstract FunctionValues getValues(Map context, LeafReaderContext readerContext) throws IOException; [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:67: warning: [rawtypes] found raw type: Map [javac] public void createWeight(Map context, IndexSearcher searcher) throws IOException { [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:73: warning: [rawtypes] found raw type: Map [javac] public static Map newContext(IndexSearcher searcher) { [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: Map [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: IdentityHashMap [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class IdentityHashMapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in class IdentityHashMap [javac] V extends Object declared in class IdentityHashMap [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:75: warning: [unchecked] unchecked call to put(K,V) as a member of the raw type Map [javac] context.put(searcher, searcher); [javac]^ [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:104: warning: [rawtypes] found raw type: Map [javac] Map context = newContext(searcher); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:111: warning: [rawtypes] found raw type: Map [javac] private final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac]
[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.8.0_20) - Build # 11545 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11545/ Java: 32bit/jdk1.8.0_20 -server -XX:+UseG1GC (asserts: true) All tests passed Build Log: [...truncated 4101 lines...] [javac] Compiling 67 source files to /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/queries/classes/java [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/FunctionQuery.java:66: warning: [rawtypes] found raw type: Map [javac] protected final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:43: warning: [rawtypes] found raw type: Map [javac] public abstract FunctionValues getValues(Map context, LeafReaderContext readerContext) throws IOException; [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:67: warning: [rawtypes] found raw type: Map [javac] public void createWeight(Map context, IndexSearcher searcher) throws IOException { [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:73: warning: [rawtypes] found raw type: Map [javac] public static Map newContext(IndexSearcher searcher) { [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: Map [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: IdentityHashMap [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class IdentityHashMapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in class IdentityHashMap [javac] V extends Object declared in class IdentityHashMap [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:75: warning: [unchecked] unchecked call to put(K,V) as a member of the raw type Map [javac] context.put(searcher, searcher); [javac]^ [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:104: warning: [rawtypes] found raw type: Map [javac] Map context = newContext(searcher); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:111: warning: [rawtypes] found raw type: Map [javac] private final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac]
[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 692 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/692/ No tests ran. Build Log: [...truncated 112 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.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) 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:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at
[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_40-ea-b09) - Build # 4467 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4467/ Java: 32bit/jdk1.8.0_40-ea-b09 -server -XX:+UseParallelGC (asserts: true) 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.embedded.LargeVolumeEmbeddedTest Error Message: Could not remove the following files (in the order of attempts): C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.embedded.LargeVolumeEmbeddedTest-54CFA8328E33D17-001\init-core-data-001\tlog\tlog.003: java.nio.file.FileSystemException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.embedded.LargeVolumeEmbeddedTest-54CFA8328E33D17-001\init-core-data-001\tlog\tlog.003: The process cannot access the file because it is being used by another process. C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.embedded.LargeVolumeEmbeddedTest-54CFA8328E33D17-001\init-core-data-001\tlog: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.embedded.LargeVolumeEmbeddedTest-54CFA8328E33D17-001\init-core-data-001\tlog C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.embedded.LargeVolumeEmbeddedTest-54CFA8328E33D17-001\init-core-data-001: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.embedded.LargeVolumeEmbeddedTest-54CFA8328E33D17-001\init-core-data-001 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.embedded.LargeVolumeEmbeddedTest-54CFA8328E33D17-001\init-core-data-001: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.embedded.LargeVolumeEmbeddedTest-54CFA8328E33D17-001\init-core-data-001 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.embedded.LargeVolumeEmbeddedTest-54CFA8328E33D17-001: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.embedded.LargeVolumeEmbeddedTest-54CFA8328E33D17-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.embedded.LargeVolumeEmbeddedTest-54CFA8328E33D17-001\init-core-data-001\tlog\tlog.003: java.nio.file.FileSystemException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.embedded.LargeVolumeEmbeddedTest-54CFA8328E33D17-001\init-core-data-001\tlog\tlog.003: The process cannot access the file because it is being used by another process. C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.embedded.LargeVolumeEmbeddedTest-54CFA8328E33D17-001\init-core-data-001\tlog: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.embedded.LargeVolumeEmbeddedTest-54CFA8328E33D17-001\init-core-data-001\tlog C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.embedded.LargeVolumeEmbeddedTest-54CFA8328E33D17-001\init-core-data-001: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.embedded.LargeVolumeEmbeddedTest-54CFA8328E33D17-001\init-core-data-001 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.embedded.LargeVolumeEmbeddedTest-54CFA8328E33D17-001\init-core-data-001: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.embedded.LargeVolumeEmbeddedTest-54CFA8328E33D17-001\init-core-data-001 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.embedded.LargeVolumeEmbeddedTest-54CFA8328E33D17-001: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-solrj\test\J0\temp\solr.client.solrj.embedded.LargeVolumeEmbeddedTest-54CFA8328E33D17-001 at __randomizedtesting.SeedInfo.seed([54CFA8328E33D17]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:281) at
Re: [JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.8.0_40-ea-b09) - Build # 11536 - Failure!
On 12/3/2014 9:07 AM, Adrien Grand wrote: It seems to be a known issue: http://status.apache.org/ On Wed, Dec 3, 2014 at 5:05 PM, Adrien Grand jpou...@gmail.com wrote: Can anyone commit on branch_5x? I've been trying to run svn ccommit for 30 minutes but the command just hangs while svn up works fine. A thread on infra says that people are seeing commits time out and toss an error, but that they ARE being successfully committed. It was talking about the EU mirror, and that status message is about the US master, so I don't know if it's the same thing. That thread on infra also mentions a separate problem with the mail server being way behind on things like the commit updates. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4470) Support for basic http auth in internal solr requests
[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234178#comment-14234178 ] Per Steffensen commented on SOLR-4470: -- bq. I noticed that some of the comments were around the size of the patch Yes, unfortunately I have provided a significant number of features/patches that are fairly big that never got committed. It is not that I really want to do it this way. I would much rather, as I sense its most often done, start out with rough half-working patches, and design the solution by adding to and discussing the patches as they evolve. Unfortunately that just does not fit very well with the way my customer expects me to work. He tells me (in this case) I want to protect my Solrs with username/password on HTTP level. You have two weeks to do it. I'd better get started. I make a solution the way I think it should be, and do not have the time to discuss it to much with the rest of you. When I have made a working solution to the customer, I feel obligated to at least try to give it back to Solr - if you want to use Open Source, make sure to (try to) give back whenever you can. This way I end up providing a fully functional complete solution. I understand that this is hard to grasp for you guys. But I also believe that I am often mistaken. I am not saying that you just have to commit this without any change, dialog or whatever. I just want you to pretend that we are in the beginning of solving this ticket, and just look at the full solution from me as a suggestion on how to solve it, that at least can be used starting point for a discussion and design process. After I have made the complete solution my customer is happy, and then I have the time to discuss/design the real solution with you guys. But it usually never gets that far - no committer really want to jump into it. Then I just say to myself that I did my duty and forwarded my solution to the community. If no one wants to participate I cannot do much more. The thing about the discussion/design process is that it is very CALENDAR-time consuming. It is not that I will spend that much actual time on it - usually you just add a few comments, change the patch a little and wait for comments, while you do other stuff (e.g. implementing the next feature for the customer :-) ). So I will have the time to participate in this after full solution-phase of making the right solution for Solr. bq. Is it correct that every SolrServer can handle authCredentials? And not e.g. only HttpSolrServer Yes bq. Is it mandatory to nearly double the API with this extra parameter? No. Actually I thought [~janhoy] removed the added API methods bq. UpdateRequest.add().doc(doc).commitWithin(-1).authCredentials(creds) Yes the builder-approach is IMHO in general a much better approach compared to having numerous methods with all combinations of parameters or having one methods taking all parameters where special values (like null, -1 or something) means that you just want default on that one. But I dont see that done in Solr. When in Rome, I guess... bq. Then we don't put the authCredentials in the face of all users You are probably right bq. I think we ought to be able to break it down into smaller manageable commits Yes, I am sure that can be done. Seems you have a lot of good ideas on how to cut the cake. In regards to this particular SOLR-4470, I think you are focusing too much on the API changes, though. It is a fairly small part of the patch. So if we want to cut SOLR-4470 into smaller patches we need more cutting that just API stuff and the rest. But in general I like all of your ideas in this area. Support for basic http auth in internal solr requests - Key: SOLR-4470 URL: https://issues.apache.org/jira/browse/SOLR-4470 Project: Solr Issue Type: New Feature Components: clients - java, multicore, replication (java), SolrCloud Affects Versions: 4.0 Reporter: Per Steffensen Assignee: Jan Høydahl Labels: authentication, https, solrclient, solrcloud, ssl Fix For: Trunk Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch, SOLR-4470_trunk_r1568857.patch We want to protect any HTTP-resource (url). We want to require credentials no matter what kind of HTTP-request you make to a Solr-node. It can faily easy be acheived as described on http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes also make internal request to
[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #1278: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1278/ No tests ran. Build Log: [...truncated 247 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.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) 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:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:514) ... 35 more Caused by: java.net.SocketTimeoutException:
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b34) - Build # 11539 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11539/ Java: 64bit/jdk1.9.0-ea-b34 -XX:+UseCompressedOops -XX:+UseParallelGC (asserts: true) All tests passed Build Log: [...truncated 4090 lines...] [javac] Compiling 67 source files to /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/queries/classes/java [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/FunctionQuery.java:66: warning: [rawtypes] found raw type: Map [javac] protected final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:43: warning: [rawtypes] found raw type: Map [javac] public abstract FunctionValues getValues(Map context, LeafReaderContext readerContext) throws IOException; [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:67: warning: [rawtypes] found raw type: Map [javac] public void createWeight(Map context, IndexSearcher searcher) throws IOException { [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:73: warning: [rawtypes] found raw type: Map [javac] public static Map newContext(IndexSearcher searcher) { [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: Map [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: IdentityHashMap [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class IdentityHashMapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in class IdentityHashMap [javac] V extends Object declared in class IdentityHashMap [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:75: warning: [unchecked] unchecked call to put(K,V) as a member of the raw type Map [javac] context.put(searcher, searcher); [javac]^ [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:104: warning: [rawtypes] found raw type: Map [javac] Map context = newContext(searcher); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:111: warning: [rawtypes] found raw type: Map [javac] private final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac]
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_40-ea-b09) - Build # 11548 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11548/ Java: 64bit/jdk1.8.0_40-ea-b09 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC (asserts: true) All tests passed Build Log: [...truncated 4098 lines...] [javac] Compiling 67 source files to /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/queries/classes/java [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/FunctionQuery.java:66: warning: [rawtypes] found raw type: Map [javac] protected final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:43: warning: [rawtypes] found raw type: Map [javac] public abstract FunctionValues getValues(Map context, LeafReaderContext readerContext) throws IOException; [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:67: warning: [rawtypes] found raw type: Map [javac] public void createWeight(Map context, IndexSearcher searcher) throws IOException { [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:73: warning: [rawtypes] found raw type: Map [javac] public static Map newContext(IndexSearcher searcher) { [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: Map [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: IdentityHashMap [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class IdentityHashMapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in class IdentityHashMap [javac] V extends Object declared in class IdentityHashMap [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:75: warning: [unchecked] unchecked call to put(K,V) as a member of the raw type Map [javac] context.put(searcher, searcher); [javac]^ [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:104: warning: [rawtypes] found raw type: Map [javac] Map context = newContext(searcher); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:111: warning: [rawtypes] found raw type: Map [javac] private final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac]
[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.8.0_20) - Build # 4364 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4364/ Java: 32bit/jdk1.8.0_20 -client -XX:+UseParallelGC (asserts: true) All tests passed Build Log: [...truncated 4083 lines...] [javac] Compiling 67 source files to C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\build\queries\classes\java [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\FunctionQuery.java:66: warning: [rawtypes] found raw type: Map [javac] protected final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:43: warning: [rawtypes] found raw type: Map [javac] public abstract FunctionValues getValues(Map context, LeafReaderContext readerContext) throws IOException; [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:67: warning: [rawtypes] found raw type: Map [javac] public void createWeight(Map context, IndexSearcher searcher) throws IOException { [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:73: warning: [rawtypes] found raw type: Map [javac] public static Map newContext(IndexSearcher searcher) { [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:74: warning: [rawtypes] found raw type: Map [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:74: warning: [rawtypes] found raw type: IdentityHashMap [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class IdentityHashMapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in class IdentityHashMap [javac] V extends Object declared in class IdentityHashMap [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:75: warning: [unchecked] unchecked call to put(K,V) as a member of the raw type Map [javac] context.put(searcher, searcher); [javac]^ [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:104: warning: [rawtypes] found raw type: Map [javac] Map context = newContext(searcher); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:111: warning: [rawtypes] found raw type: Map [javac] private final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac]
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2273 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2273/ No tests ran. Build Log: [...truncated 3 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.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) 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:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:514)
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2277 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2277/ No tests ran. Build Log: [...truncated 3 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.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) 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:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at
[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.8.0_40-ea-b09) - Build # 4363 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4363/ Java: 32bit/jdk1.8.0_40-ea-b09 -client -XX:+UseParallelGC (asserts: false) All tests passed Build Log: [...truncated 4081 lines...] [javac] Compiling 67 source files to C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\build\queries\classes\java [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\FunctionQuery.java:66: warning: [rawtypes] found raw type: Map [javac] protected final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:43: warning: [rawtypes] found raw type: Map [javac] public abstract FunctionValues getValues(Map context, LeafReaderContext readerContext) throws IOException; [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:67: warning: [rawtypes] found raw type: Map [javac] public void createWeight(Map context, IndexSearcher searcher) throws IOException { [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:73: warning: [rawtypes] found raw type: Map [javac] public static Map newContext(IndexSearcher searcher) { [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:74: warning: [rawtypes] found raw type: Map [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:74: warning: [rawtypes] found raw type: IdentityHashMap [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class IdentityHashMapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in class IdentityHashMap [javac] V extends Object declared in class IdentityHashMap [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:75: warning: [unchecked] unchecked call to put(K,V) as a member of the raw type Map [javac] context.put(searcher, searcher); [javac]^ [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:104: warning: [rawtypes] found raw type: Map [javac] Map context = newContext(searcher); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:111: warning: [rawtypes] found raw type: Map [javac] private final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac]
[JENKINS] Lucene-Artifacts-5.x - Build # 700 - Failure
Build: https://builds.apache.org/job/Lucene-Artifacts-5.x/700/ No tests ran. Build Log: [...truncated 242 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.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) 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:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:514)
[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.8.0) - Build # 1930 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1930/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC (asserts: false) All tests passed Build Log: [...truncated 4071 lines...] [javac] Compiling 67 source files to /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/build/queries/classes/java [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/FunctionQuery.java:66: warning: [rawtypes] found raw type: Map [javac] protected final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:43: warning: [rawtypes] found raw type: Map [javac] public abstract FunctionValues getValues(Map context, LeafReaderContext readerContext) throws IOException; [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:67: warning: [rawtypes] found raw type: Map [javac] public void createWeight(Map context, IndexSearcher searcher) throws IOException { [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:73: warning: [rawtypes] found raw type: Map [javac] public static Map newContext(IndexSearcher searcher) { [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: Map [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: IdentityHashMap [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class IdentityHashMapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in class IdentityHashMap [javac] V extends Object declared in class IdentityHashMap [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:75: warning: [unchecked] unchecked call to put(K,V) as a member of the raw type Map [javac] context.put(searcher, searcher); [javac]^ [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:104: warning: [rawtypes] found raw type: Map [javac] Map context = newContext(searcher); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:111: warning: [rawtypes] found raw type: Map [javac] private final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac]
[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.8.0) - Build # 1929 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1929/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC (asserts: false) All tests passed Build Log: [...truncated 4073 lines...] [javac] Compiling 67 source files to /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/build/queries/classes/java [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/FunctionQuery.java:66: warning: [rawtypes] found raw type: Map [javac] protected final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:43: warning: [rawtypes] found raw type: Map [javac] public abstract FunctionValues getValues(Map context, LeafReaderContext readerContext) throws IOException; [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:67: warning: [rawtypes] found raw type: Map [javac] public void createWeight(Map context, IndexSearcher searcher) throws IOException { [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:73: warning: [rawtypes] found raw type: Map [javac] public static Map newContext(IndexSearcher searcher) { [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: Map [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: IdentityHashMap [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class IdentityHashMapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in class IdentityHashMap [javac] V extends Object declared in class IdentityHashMap [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:75: warning: [unchecked] unchecked call to put(K,V) as a member of the raw type Map [javac] context.put(searcher, searcher); [javac]^ [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:104: warning: [rawtypes] found raw type: Map [javac] Map context = newContext(searcher); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:111: warning: [rawtypes] found raw type: Map [javac] private final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac]
[jira] [Commented] (SOLR-4470) Support for basic http auth in internal solr requests
[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234187#comment-14234187 ] Mark Miller commented on SOLR-4470: --- bq. I personally wish we didn't need to do all the API back-compat If you can focus on an API breaks in isolated ways first, the upcoming 5.0 is a perfect time to break. Support for basic http auth in internal solr requests - Key: SOLR-4470 URL: https://issues.apache.org/jira/browse/SOLR-4470 Project: Solr Issue Type: New Feature Components: clients - java, multicore, replication (java), SolrCloud Affects Versions: 4.0 Reporter: Per Steffensen Assignee: Jan Høydahl Labels: authentication, https, solrclient, solrcloud, ssl Fix For: Trunk Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch, SOLR-4470_trunk_r1568857.patch We want to protect any HTTP-resource (url). We want to require credentials no matter what kind of HTTP-request you make to a Solr-node. It can faily easy be acheived as described on http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes also make internal request to other Solr-nodes, and for it to work credentials need to be provided here also. Ideally we would like to forward credentials from a particular request to all the internal sub-requests it triggers. E.g. for search and update request. But there are also internal requests * that only indirectly/asynchronously triggered from outside requests (e.g. shard creation/deletion/etc based on calls to the Collection API) * that do not in any way have relation to an outside super-request (e.g. replica synching stuff) We would like to aim at a solution where original credentials are forwarded when a request directly/synchronously trigger a subrequest, and fallback to a configured internal credentials for the asynchronous/non-rooted requests. In our solution we would aim at only supporting basic http auth, but we would like to make a framework around it, so that not to much refactoring is needed if you later want to make support for other kinds of auth (e.g. digest) We will work at a solution but create this JIRA issue early in order to get input/comments from the community as early as possible. -- This message was sent by Atlassian JIRA (v6.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-Windows (32bit/jdk1.8.0_40-ea-b09) - Build # 4362 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4362/ Java: 32bit/jdk1.8.0_40-ea-b09 -client -XX:+UseParallelGC (asserts: false) All tests passed Build Log: [...truncated 4318 lines...] [javac] Compiling 67 source files to C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\build\queries\classes\java [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\FunctionQuery.java:66: warning: [rawtypes] found raw type: Map [javac] protected final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:43: warning: [rawtypes] found raw type: Map [javac] public abstract FunctionValues getValues(Map context, LeafReaderContext readerContext) throws IOException; [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:67: warning: [rawtypes] found raw type: Map [javac] public void createWeight(Map context, IndexSearcher searcher) throws IOException { [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:73: warning: [rawtypes] found raw type: Map [javac] public static Map newContext(IndexSearcher searcher) { [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:74: warning: [rawtypes] found raw type: Map [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:74: warning: [rawtypes] found raw type: IdentityHashMap [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class IdentityHashMapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in class IdentityHashMap [javac] V extends Object declared in class IdentityHashMap [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:75: warning: [unchecked] unchecked call to put(K,V) as a member of the raw type Map [javac] context.put(searcher, searcher); [javac]^ [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:104: warning: [rawtypes] found raw type: Map [javac] Map context = newContext(searcher); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:111: warning: [rawtypes] found raw type: Map [javac] private final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac]
[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.7.0) - Build # 1928 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1928/ Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseG1GC (asserts: true) All tests passed Build Log: [...truncated 4167 lines...] [javac] Compiling 67 source files to /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/build/queries/classes/java [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/FunctionQuery.java:66: warning: [rawtypes] found raw type: Map [javac] protected final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:43: warning: [rawtypes] found raw type: Map [javac] public abstract FunctionValues getValues(Map context, LeafReaderContext readerContext) throws IOException; [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:67: warning: [rawtypes] found raw type: Map [javac] public void createWeight(Map context, IndexSearcher searcher) throws IOException { [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:73: warning: [rawtypes] found raw type: Map [javac] public static Map newContext(IndexSearcher searcher) { [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: Map [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: IdentityHashMap [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class IdentityHashMapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in class IdentityHashMap [javac] V extends Object declared in class IdentityHashMap [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:75: warning: [unchecked] unchecked call to put(K,V) as a member of the raw type Map [javac] context.put(searcher, searcher); [javac]^ [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:104: warning: [rawtypes] found raw type: Map [javac] Map context = newContext(searcher); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:111: warning: [rawtypes] found raw type: Map [javac] private final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac]
[JENKINS] Solr-Artifacts-5.x - Build # 676 - Failure
Build: https://builds.apache.org/job/Solr-Artifacts-5.x/676/ No tests ran. Build Log: [...truncated 249 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.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) 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:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:514)
[jira] [Created] (SOLR-6820) The sync on the VersionInfo bucket in DistributedUpdateProcesser#addDocument appears to be a large bottleneck when using replication.
Mark Miller created SOLR-6820: - Summary: The sync on the VersionInfo bucket in DistributedUpdateProcesser#addDocument appears to be a large bottleneck when using replication. Key: SOLR-6820 URL: https://issues.apache.org/jira/browse/SOLR-6820 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Mark Miller -- 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: Running tests incrementally based on changed files
Hmm. May have to retract that. Just tried running ant test on SSD and on RAM and saw no difference worth mentioning (nearly 1 hour each!). So maybe not useful for that. I _thought_ it was faster for compilation, which is mostly file access and no waiting for cloud instances to spin up. I'll have to retest that later. I did this on Mac where I have the following script: # Make 1Gb RAM Disk (1024*2048), where 2048 is block count in a megabyte diskutil erasevolume HFS+ 'RAMDisk' `hdiutil attach -nomount ram://2097152` Though 1Gb was not enough for the ant test and I had to recreate the disk with 2G. On an 8G total Mac Book Pro. On Linux I think it requires a memory-backed loop device filesystem. Or some such. Regards, Alex. Personal: http://www.outerthoughts.com/ and @arafalov Solr resources and newsletter: http://www.solr-start.com/ and @solrstart Solr popularizers community: https://www.linkedin.com/groups?gid=6713853 On 3 December 2014 at 01:14, Shawn Heisey apa...@elyograg.org wrote: On 12/2/2014 10:53 PM, Alexandre Rafalovitch wrote: A tangent, but a relevant one (to the issue of speed). Have you tried running the tests with Lucene/Solr code being in the RAM disk? I found that compiling source on RAMDisk is a lot faster than even with SSD drive. Must be just frequency of access. It might be the same with tests. I am intrigued by this. Do you have a quick and dirty guide to doing this on Linux? How much RAM must be allocated for a typical build and test run? Probably wouldn't want to run Monster tests on it. :) Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6820) The sync on the VersionInfo bucket in DistributedUpdateProcesser#addDocument appears to be a large bottleneck when using replication.
[ https://issues.apache.org/jira/browse/SOLR-6820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234189#comment-14234189 ] Mark Miller commented on SOLR-6820: --- In my simple testing for SOLR-6816, I can see that raising the number of buckets to 1024 from 256 seems to do nothing, but raising it to 65536 seem to give performance similar to removing the sync entirely. We should probably make the number of buckets configurable, consider our default, and review the hashing that is going on. The sync on the VersionInfo bucket in DistributedUpdateProcesser#addDocument appears to be a large bottleneck when using replication. - Key: SOLR-6820 URL: https://issues.apache.org/jira/browse/SOLR-6820 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Mark Miller -- 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.7.0_67) - Build # 11544 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11544/ Java: 64bit/jdk1.7.0_67 -XX:-UseCompressedOops -XX:+UseParallelGC (asserts: true) All tests passed Build Log: [...truncated 4084 lines...] [javac] Compiling 67 source files to /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/queries/classes/java [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/FunctionQuery.java:66: warning: [rawtypes] found raw type: Map [javac] protected final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:43: warning: [rawtypes] found raw type: Map [javac] public abstract FunctionValues getValues(Map context, LeafReaderContext readerContext) throws IOException; [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:67: warning: [rawtypes] found raw type: Map [javac] public void createWeight(Map context, IndexSearcher searcher) throws IOException { [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:73: warning: [rawtypes] found raw type: Map [javac] public static Map newContext(IndexSearcher searcher) { [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: Map [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: IdentityHashMap [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class IdentityHashMapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in class IdentityHashMap [javac] V extends Object declared in class IdentityHashMap [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:75: warning: [unchecked] unchecked call to put(K,V) as a member of the raw type Map [javac] context.put(searcher, searcher); [javac]^ [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:104: warning: [rawtypes] found raw type: Map [javac] Map context = newContext(searcher); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:111: warning: [rawtypes] found raw type: Map [javac] private final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac]
[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.7.0_67) - Build # 11543 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11543/ Java: 32bit/jdk1.7.0_67 -client -XX:+UseConcMarkSweepGC (asserts: true) All tests passed Build Log: [...truncated 4097 lines...] [javac] Compiling 67 source files to /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/queries/classes/java [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/FunctionQuery.java:66: warning: [rawtypes] found raw type: Map [javac] protected final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:43: warning: [rawtypes] found raw type: Map [javac] public abstract FunctionValues getValues(Map context, LeafReaderContext readerContext) throws IOException; [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:67: warning: [rawtypes] found raw type: Map [javac] public void createWeight(Map context, IndexSearcher searcher) throws IOException { [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:73: warning: [rawtypes] found raw type: Map [javac] public static Map newContext(IndexSearcher searcher) { [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: Map [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: IdentityHashMap [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class IdentityHashMapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in class IdentityHashMap [javac] V extends Object declared in class IdentityHashMap [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:75: warning: [unchecked] unchecked call to put(K,V) as a member of the raw type Map [javac] context.put(searcher, searcher); [javac]^ [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:104: warning: [rawtypes] found raw type: Map [javac] Map context = newContext(searcher); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:111: warning: [rawtypes] found raw type: Map [javac] private final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac]
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_40-ea-b09) - Build # 11540 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11540/ Java: 64bit/jdk1.8.0_40-ea-b09 -XX:+UseCompressedOops -XX:+UseSerialGC (asserts: true) All tests passed Build Log: [...truncated 4099 lines...] [javac] Compiling 67 source files to /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/queries/classes/java [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/FunctionQuery.java:66: warning: [rawtypes] found raw type: Map [javac] protected final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:43: warning: [rawtypes] found raw type: Map [javac] public abstract FunctionValues getValues(Map context, LeafReaderContext readerContext) throws IOException; [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:67: warning: [rawtypes] found raw type: Map [javac] public void createWeight(Map context, IndexSearcher searcher) throws IOException { [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:73: warning: [rawtypes] found raw type: Map [javac] public static Map newContext(IndexSearcher searcher) { [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: Map [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: IdentityHashMap [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class IdentityHashMapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in class IdentityHashMap [javac] V extends Object declared in class IdentityHashMap [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:75: warning: [unchecked] unchecked call to put(K,V) as a member of the raw type Map [javac] context.put(searcher, searcher); [javac]^ [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:104: warning: [rawtypes] found raw type: Map [javac] Map context = newContext(searcher); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:111: warning: [rawtypes] found raw type: Map [javac] private final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac]
Re: [JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2267 - Failure
Filed with patch to fix: https://issues.apache.org/jira/browse/LUCENE-6092 Credit to randomized testing approach to discover the bug. ~ David Smiley Freelance Apache Lucene/Solr Search Consultant/Developer http://www.linkedin.com/in/davidwsmiley On Tue, Dec 2, 2014 at 1:06 PM, david.w.smi...@gmail.com david.w.smi...@gmail.com wrote: I’ll dig. On Tue, Dec 2, 2014 at 11:57 AM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2267/ 1 tests failed. FAILED: org.apache.lucene.spatial.prefix.DateNRStrategyTest.testContains {#9 seed=[801EEB0A7D92DF9E:7325FAA06CA28D9F]} Error Message: [Contains] Shouldn't match I#1:465172-01 Q:[465172 TO 465172-01] Stack Trace: java.lang.AssertionError: [Contains] Shouldn't match I#1:465172-01 Q:[465172 TO 465172-01] at __randomizedtesting.SeedInfo.seed([801EEB0A7D92DF9E:7325FAA06CA28D9F]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126) at org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115) at org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:62) at org.apache.lucene.spatial.prefix.DateNRStrategyTest.testContains(DateNRStrategyTest.java:65) 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:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java: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:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at 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
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b34) - Build # 11542 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11542/ Java: 64bit/jdk1.9.0-ea-b34 -XX:+UseCompressedOops -XX:+UseSerialGC (asserts: true) All tests passed Build Log: [...truncated 4088 lines...] [javac] Compiling 67 source files to /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/queries/classes/java [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/FunctionQuery.java:66: warning: [rawtypes] found raw type: Map [javac] protected final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:43: warning: [rawtypes] found raw type: Map [javac] public abstract FunctionValues getValues(Map context, LeafReaderContext readerContext) throws IOException; [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:67: warning: [rawtypes] found raw type: Map [javac] public void createWeight(Map context, IndexSearcher searcher) throws IOException { [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:73: warning: [rawtypes] found raw type: Map [javac] public static Map newContext(IndexSearcher searcher) { [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: Map [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: IdentityHashMap [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class IdentityHashMapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in class IdentityHashMap [javac] V extends Object declared in class IdentityHashMap [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:75: warning: [unchecked] unchecked call to put(K,V) as a member of the raw type Map [javac] context.put(searcher, searcher); [javac]^ [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:104: warning: [rawtypes] found raw type: Map [javac] Map context = newContext(searcher); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:111: warning: [rawtypes] found raw type: Map [javac] private final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac]
Re: [JENKINS] Lucene-Solr-4.10-Linux (32bit/jdk1.8.0_40-ea-b09) - Build # 125 - Failure!
I'll be on a plane in a few hours, but here's the 4.x patch to fix once SVN starts working again... Index: lucene/test-framework/src/java/org/apache/lucene/search/BaseExplanationTestCase.java === --- lucene/test-framework/src/java/org/apache/lucene/search/BaseExplanationTestCase.java (revision 1643005) +++ lucene/test-framework/src/java/org/apache/lucene/search/BaseExplanationTestCase.java (working copy) @@ -33,6 +33,7 @@ import org.apache.lucene.store.Directory; import org.apache.lucene.util.BytesRef; import org.apache.lucene.util.LuceneTestCase; +import org.apache.lucene.util.LuceneTestCase.SuppressCodecs; import org.junit.AfterClass; import org.junit.BeforeClass; @@ -48,6 +49,7 @@ * * @see Subclasses for actual tests */ +@SuppressCodecs(Lucene3x) public abstract class BaseExplanationTestCase extends LuceneTestCase { protected static IndexSearcher searcher; protected static IndexReader reader; : Date: Wed, 3 Dec 2014 11:38:14 + (UTC) : From: Policeman Jenkins Server jenk...@thetaphi.de : Reply-To: dev@lucene.apache.org : To: dev@lucene.apache.org : Subject: [JENKINS] Lucene-Solr-4.10-Linux (32bit/jdk1.8.0_40-ea-b09) - Build # : 125 - Failure! : : Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.10-Linux/125/ : Java: 32bit/jdk1.8.0_40-ea-b09 -client -XX:+UseSerialGC (asserts: true) : : 2 tests failed. : FAILED: junit.framework.TestSuite.org.apache.lucene.search.TestComplexExplanationsOfNonMatches : : Error Message: : this codec cannot write docvalues : : Stack Trace: : java.lang.UnsupportedOperationException: this codec cannot write docvalues : at __randomizedtesting.SeedInfo.seed([A6BA94B21EE7E0BC]:0) : at org.apache.lucene.codecs.lucene3x.Lucene3xCodec$1.fieldsConsumer(Lucene3xCodec.java:73) : at org.apache.lucene.index.DefaultIndexingChain.writeDocValues(DefaultIndexingChain.java:141) : at org.apache.lucene.index.DefaultIndexingChain.flush(DefaultIndexingChain.java:95) : at org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:439) : at org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:513) : at org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:624) : at org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2942) : at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3097) : at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3064) : at org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:348) : at org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:277) : at org.apache.lucene.search.BaseExplanationTestCase.beforeClassTestExplanations(BaseExplanationTestCase.java:85) : 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:497) : at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) : at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:767) : at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) : at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) : at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) : at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) : at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) : at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) : at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) : at 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
Re: [JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2267 - Failure
Credit to randomized testing approach to discover the bug. :) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5987) Make indexwriter a mere mortal when exceptions strike
[ https://issues.apache.org/jira/browse/LUCENE-5987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234198#comment-14234198 ] Robert Muir commented on LUCENE-5987: - What is happening with TestIndexWriterAbort? I only added that recently to test we were doing the right thing so that abort() could be removed from the codec API (LUCENE-6082). But with this patch, the unreferenced files check is disabled (and should be?), so the patch doesnt offer anything that TestIndexWriterExceptions2 isn't already checking. What is happening with TestIndexWriterDelete.testErrorInDocsWriterAdd(), it still causes aborting exceptions and checks that unreferenced files are removed. Why is it passing? Make indexwriter a mere mortal when exceptions strike - Key: LUCENE-5987 URL: https://issues.apache.org/jira/browse/LUCENE-5987 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Assignee: Michael McCandless Attachments: LUCENE-5987.patch, LUCENE-5987.patch IndexWriter's exception handling is overly complicated. Every method in general reads like this: {code} try { try { try { ... // lock order: COMPLICATED synchronized(this or that) { } ... } finally { if (!success5) { deleter.deleteThisFileOrThat(); } ... } } {code} Part of the problem is it acts like its an invincible superhero, e.g. can take a disk full on merge or flush to the face and just keep on trucking, and you can somehow fix the root cause and then just go about making commits on the same instance. But we have a hard enough time ensuring exceptions dont do the wrong thing (e.g. cause corruption), and I don't think we really test this crazy behavior anywhere: e.g. making commits AFTER hitting disk full and so on. It would probably be simpler if when such things happen, IW just considered them tragic just like OOM and rolled itself back, instead of doing all kinds of really scary stuff to try to keep itself healthy (like the little dance it plays with IFD in mergeMiddle manually deleting CFS files). Besides, without something like a WAL, Indexwriter isn't really fit to be a superhero anyway: it can't prevent you from losing data in such situations. It just doesn't have the right tools for the job. edit: just to be clear I am referring to abort (low level exception during flush) and exceptions during merge. For simple non-aborting cases like analyzer errors, of course we can deal with this. We already made great progress on turning a lot of BS exceptions that would cause aborts into non-aborting ones recently. -- 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: solr client sdk's/libraries for native platforms
Nice! I like the title “Solr Ecosystem” so I propose the SolrIntegration content by moved there, but it’s not critical to me that the content move that way vs the other. I think when listing projects grouped by source code language, it’s important to make further distinctions as to what the nature of the project is. Some are just clients, some are actually response formats Solr natively supports, and some are fundamentally integrated with another framework (e.g. Rails or Django). It’s good to see some of that here… but it’s weird to see Haystack (a Django plug-in) down in the unorganized list at the bottom “Integrating Solr with Other (Non Search) Applications”. CMSs should get their own category. ~ David Smiley Freelance Apache Lucene/Solr Search Consultant/Developer http://www.linkedin.com/in/davidwsmiley On Wed, Dec 3, 2014 at 8:36 AM, Alexandre Rafalovitch arafa...@gmail.com wrote: +1 on merging those two. But also needs a bit of a 'design' of what goes into it. I have probably another 30 links of various Solr-related products. I didn't touch SolrPython page because it had that extra information compared to just one liners on the main screen. And I didn't have the time to review whether those examples are still valid or need to be present. Same with SolrPHP legacy stuff I linked to. Another pass through this would be nice. For example, little did I know there was a client for Solr for the Rust programming language. And four for Clojure :-) Regards, Alex. Personal: http://www.outerthoughts.com/ and @arafalov Solr resources and newsletter: http://www.solr-start.com/ and @solrstart Solr popularizers community: https://www.linkedin.com/groups?gid=6713853 On 3 December 2014 at 08:28, Eric Pugh ep...@opensourceconnections.com wrote: Maybe this should just be one long page? David and I were thinking of merging it, since it’s an arbitrary split anyway between IntegratingSolr and the SolrEcosystem pages. After all, it’s all part of the SolrEcosystem! One of the reasons I like having this all pulled together into one place is that it shows new users how much breadth and depth there is!For example, little did I know there was a client for Solr for the Rust programming language. Maybe merge IntegratingSolr and SolrEcosystem and SolPython? And rename SolPython to SolrPython, and put a link with just the example code bits? Eric On Dec 3, 2014, at 12:23 AM, Alexandre Rafalovitch arafa...@gmail.com wrote: Ok, Done: https://wiki.apache.org/solr/IntegratingSolr Also: https://wiki.apache.org/solr/SolPython I am not sure what to do with the stuff at the bottom of the client list, though I've put the dates on it anyway. It's neither comprehensive nor representative and I don't understand the significance of that part vs. https://wiki.apache.org/solr/SolrEcosystem . But that's all I had patience for this time with WIKI being an absolute turtle. Perhaps somebody else can revisit it with a fresh eye now that I cleaned it up a bit. Regards, Alex. Personal: http://www.outerthoughts.com/ and @arafalov Solr resources and newsletter: http://www.solr-start.com/ and @solrstart Solr popularizers community: https://www.linkedin.com/groups?gid=6713853 On 1 December 2014 at 20:04, david.w.smi...@gmail.com david.w.smi...@gmail.com wrote: I like the “last updated …” (rounded to the month) idea. It may be difficult to maintain a “last checked” distinction, and create somewhat more of a burden on maintaining the list. I think it’s useful to list out old projects, maybe separately, and indicated as old. This makes the page a better comprehensive resource. Thanks for volunteering Alex! ~ David Smiley Freelance Apache Lucene/Solr Search Consultant/Developer http://www.linkedin.com/in/davidwsmiley On Mon, Dec 1, 2014 at 7:35 PM, Alexandre Rafalovitch arafa...@gmail.com wrote: What would be the reasonable cutoff for the client library last update? Say if it was not updated in 2 years - should it be included in the list? In 3? Included with a warning? Or do we list them all and let the user sort it out? Or put a last-checked date on the wiki and mention rough last update against each library? Regards, Alex. Personal: http://www.outerthoughts.com/ and @arafalov Solr resources and newsletter: http://www.solr-start.com/ and @solrstart Solr popularizers community: https://www.linkedin.com/groups?gid=6713853 On 1 December 2014 at 11:03, Eric Pugh ep...@opensourceconnections.com wrote: I think in the vein of a “do-it-tocracy”, getting the Wiki updated is a perfectly good first step, and then if there is a better approach, hopefully that occurs.… ;-) On Dec 1, 2014, at 10:51 AM, Alexandre Rafalovitch arafa...@gmail.com wrote: On 1 December 2014 at 10:02, david.w.smi...@gmail.com david.w.smi...@gmail.com wrote: I meant to reply
[jira] [Commented] (SOLR-5890) Delete silently fails if not sent to shard where document was added
[ https://issues.apache.org/jira/browse/SOLR-5890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234200#comment-14234200 ] Ishan Chattopadhyaya commented on SOLR-5890: Here are my observations after some limited testing: Implicit router - 1. Without router.field defined, deleteByQuery. This worked for me, even without _route_, while sending the delete update request to a different shard. 2. Without router.field defined, deleteById. This worked for me only once I send the _route_ parameter with the correct shard name. 3. With router.field defined, deleteByQuery. This worked for me, even without _route_, while sending the delete update request to a different shard. 4. With router.field defined, deleteById. This worked for me with _route_ parameter, while sending the delete update request to a different shard. Delete silently fails if not sent to shard where document was added --- Key: SOLR-5890 URL: https://issues.apache.org/jira/browse/SOLR-5890 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.7 Environment: Debian 7.4. Reporter: Peter Inglesby Assignee: Noble Paul Labels: difficulty-medium, impact-medium, workaround-exists Fix For: 5.0, Trunk We have SolrCloud set up with two shards, each with a leader and a replica. We use haproxy to distribute requests between the four nodes. Regardless of which node we send an add request to, following a commit, the newly-added document is returned in a search, as expected. However, we can only delete a document if the delete request is sent to a node in the shard where the document was added. If we send the delete request to a node in the other shard (and then send a commit) the document is not deleted. Such a delete request will get a 200 response, with the following body: {'responseHeader'={'status'=0,'QTime'=7}} Apart from the the very low QTime, this is indistinguishable from a successful delete. -- This message was sent by Atlassian JIRA (v6.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-6821) It's difficult to saturate a Solr servers resources when bulk indexing. Using multiple JVM's on a single machine can drastically improve indexing performance.
Mark Miller created SOLR-6821: - Summary: It's difficult to saturate a Solr servers resources when bulk indexing. Using multiple JVM's on a single machine can drastically improve indexing performance. Key: SOLR-6821 URL: https://issues.apache.org/jira/browse/SOLR-6821 Project: Solr Issue Type: Sub-task Reporter: Mark Miller -- 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 (32bit/jdk1.9.0-ea-b34) - Build # 11538 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11538/ Java: 32bit/jdk1.9.0-ea-b34 -client -XX:+UseG1GC (asserts: false) All tests passed Build Log: [...truncated 4096 lines...] [javac] Compiling 67 source files to /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/queries/classes/java [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/FunctionQuery.java:66: warning: [rawtypes] found raw type: Map [javac] protected final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:43: warning: [rawtypes] found raw type: Map [javac] public abstract FunctionValues getValues(Map context, LeafReaderContext readerContext) throws IOException; [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:67: warning: [rawtypes] found raw type: Map [javac] public void createWeight(Map context, IndexSearcher searcher) throws IOException { [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:73: warning: [rawtypes] found raw type: Map [javac] public static Map newContext(IndexSearcher searcher) { [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: Map [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: IdentityHashMap [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class IdentityHashMapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in class IdentityHashMap [javac] V extends Object declared in class IdentityHashMap [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:75: warning: [unchecked] unchecked call to put(K,V) as a member of the raw type Map [javac] context.put(searcher, searcher); [javac]^ [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:104: warning: [rawtypes] found raw type: Map [javac] Map context = newContext(searcher); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:111: warning: [rawtypes] found raw type: Map [javac] private final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac]
[jira] [Commented] (SOLR-5890) Delete silently fails if not sent to shard where document was added
[ https://issues.apache.org/jira/browse/SOLR-5890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234208#comment-14234208 ] Ishan Chattopadhyaya commented on SOLR-5890: For supporting _route_ parameter per id in a deleteById request, instead of a _route_ parameter per request, I propose the following changes to the request format. JSON: delete: { id:ID , _route_:route} XML: delete id _route_=shard1123/id id _route_=shard2124/id /delete Similarly, together with UpdateRequest.deleteById(ListString ids), I propose another method: UpdateRequest.deleteById(ListString ids, ListString routes), Here, I don't like the idea of list of encapsulated objects that contains both id and route, hence want to go with two lists. Any suggestions? Also, like UpdateRequest.deleteById(String id), I propose another method: UpdateRequest.deleteById(String id, String route) Delete silently fails if not sent to shard where document was added --- Key: SOLR-5890 URL: https://issues.apache.org/jira/browse/SOLR-5890 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.7 Environment: Debian 7.4. Reporter: Peter Inglesby Assignee: Noble Paul Labels: difficulty-medium, impact-medium, workaround-exists Fix For: 5.0, Trunk We have SolrCloud set up with two shards, each with a leader and a replica. We use haproxy to distribute requests between the four nodes. Regardless of which node we send an add request to, following a commit, the newly-added document is returned in a search, as expected. However, we can only delete a document if the delete request is sent to a node in the shard where the document was added. If we send the delete request to a node in the other shard (and then send a commit) the document is not deleted. Such a delete request will get a 200 response, with the following body: {'responseHeader'={'status'=0,'QTime'=7}} Apart from the the very low QTime, this is indistinguishable from a successful delete. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5890) Delete silently fails if not sent to shard where document was added
[ https://issues.apache.org/jira/browse/SOLR-5890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234208#comment-14234208 ] Ishan Chattopadhyaya edited comment on SOLR-5890 at 12/4/14 1:54 PM: - For supporting _route_ parameter per id in a deleteById request, instead of a _route_ parameter per request, I propose the following changes to the request format. JSON: delete: { id:ID , _route_:route} XML: delete id _route_=shard1123/id id _route_=shard2124/id /delete Similarly, together with UpdateRequest.deleteById(ListString ids), I propose another method: UpdateRequest.deleteById(ListString ids, ListString routes), Here, I don't like the idea of list of encapsulated objects that contains both id and route, hence want to go with two lists. Any suggestions? Also, like UpdateRequest.deleteById(String id), I propose another method: UpdateRequest.deleteById(String id, String route) Can someone please review these suggestions? was (Author: ichattopadhyaya): For supporting _route_ parameter per id in a deleteById request, instead of a _route_ parameter per request, I propose the following changes to the request format. JSON: delete: { id:ID , _route_:route} XML: delete id _route_=shard1123/id id _route_=shard2124/id /delete Similarly, together with UpdateRequest.deleteById(ListString ids), I propose another method: UpdateRequest.deleteById(ListString ids, ListString routes), Here, I don't like the idea of list of encapsulated objects that contains both id and route, hence want to go with two lists. Any suggestions? Also, like UpdateRequest.deleteById(String id), I propose another method: UpdateRequest.deleteById(String id, String route) Delete silently fails if not sent to shard where document was added --- Key: SOLR-5890 URL: https://issues.apache.org/jira/browse/SOLR-5890 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.7 Environment: Debian 7.4. Reporter: Peter Inglesby Assignee: Noble Paul Labels: difficulty-medium, impact-medium, workaround-exists Fix For: 5.0, Trunk We have SolrCloud set up with two shards, each with a leader and a replica. We use haproxy to distribute requests between the four nodes. Regardless of which node we send an add request to, following a commit, the newly-added document is returned in a search, as expected. However, we can only delete a document if the delete request is sent to a node in the shard where the document was added. If we send the delete request to a node in the other shard (and then send a commit) the document is not deleted. Such a delete request will get a 200 response, with the following body: {'responseHeader'={'status'=0,'QTime'=7}} Apart from the the very low QTime, this is indistinguishable from a successful delete. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: solr client sdk's/libraries for native platforms
Sure, we could do CMSs as a category. I think there would be about 10 entries or so. Regards, Alex Personal: http://www.outerthoughts.com/ and @arafalov Solr resources and newsletter: http://www.solr-start.com/ and @solrstart Solr popularizers community: https://www.linkedin.com/groups?gid=6713853 On 3 December 2014 at 12:24, david.w.smi...@gmail.com david.w.smi...@gmail.com wrote: Nice! I like the title “Solr Ecosystem” so I propose the SolrIntegration content by moved there, but it’s not critical to me that the content move that way vs the other. I think when listing projects grouped by source code language, it’s important to make further distinctions as to what the nature of the project is. Some are just clients, some are actually response formats Solr natively supports, and some are fundamentally integrated with another framework (e.g. Rails or Django). It’s good to see some of that here… but it’s weird to see Haystack (a Django plug-in) down in the unorganized list at the bottom “Integrating Solr with Other (Non Search) Applications”. CMSs should get their own category. ~ David Smiley Freelance Apache Lucene/Solr Search Consultant/Developer http://www.linkedin.com/in/davidwsmiley On Wed, Dec 3, 2014 at 8:36 AM, Alexandre Rafalovitch arafa...@gmail.com wrote: +1 on merging those two. But also needs a bit of a 'design' of what goes into it. I have probably another 30 links of various Solr-related products. I didn't touch SolrPython page because it had that extra information compared to just one liners on the main screen. And I didn't have the time to review whether those examples are still valid or need to be present. Same with SolrPHP legacy stuff I linked to. Another pass through this would be nice. For example, little did I know there was a client for Solr for the Rust programming language. And four for Clojure :-) Regards, Alex. Personal: http://www.outerthoughts.com/ and @arafalov Solr resources and newsletter: http://www.solr-start.com/ and @solrstart Solr popularizers community: https://www.linkedin.com/groups?gid=6713853 On 3 December 2014 at 08:28, Eric Pugh ep...@opensourceconnections.com wrote: Maybe this should just be one long page? David and I were thinking of merging it, since it’s an arbitrary split anyway between IntegratingSolr and the SolrEcosystem pages. After all, it’s all part of the SolrEcosystem! One of the reasons I like having this all pulled together into one place is that it shows new users how much breadth and depth there is!For example, little did I know there was a client for Solr for the Rust programming language. Maybe merge IntegratingSolr and SolrEcosystem and SolPython? And rename SolPython to SolrPython, and put a link with just the example code bits? Eric On Dec 3, 2014, at 12:23 AM, Alexandre Rafalovitch arafa...@gmail.com wrote: Ok, Done: https://wiki.apache.org/solr/IntegratingSolr Also: https://wiki.apache.org/solr/SolPython I am not sure what to do with the stuff at the bottom of the client list, though I've put the dates on it anyway. It's neither comprehensive nor representative and I don't understand the significance of that part vs. https://wiki.apache.org/solr/SolrEcosystem . But that's all I had patience for this time with WIKI being an absolute turtle. Perhaps somebody else can revisit it with a fresh eye now that I cleaned it up a bit. Regards, Alex. Personal: http://www.outerthoughts.com/ and @arafalov Solr resources and newsletter: http://www.solr-start.com/ and @solrstart Solr popularizers community: https://www.linkedin.com/groups?gid=6713853 On 1 December 2014 at 20:04, david.w.smi...@gmail.com david.w.smi...@gmail.com wrote: I like the “last updated …” (rounded to the month) idea. It may be difficult to maintain a “last checked” distinction, and create somewhat more of a burden on maintaining the list. I think it’s useful to list out old projects, maybe separately, and indicated as old. This makes the page a better comprehensive resource. Thanks for volunteering Alex! ~ David Smiley Freelance Apache Lucene/Solr Search Consultant/Developer http://www.linkedin.com/in/davidwsmiley On Mon, Dec 1, 2014 at 7:35 PM, Alexandre Rafalovitch arafa...@gmail.com wrote: What would be the reasonable cutoff for the client library last update? Say if it was not updated in 2 years - should it be included in the list? In 3? Included with a warning? Or do we list them all and let the user sort it out? Or put a last-checked date on the wiki and mention rough last update against each library? Regards, Alex. Personal: http://www.outerthoughts.com/ and @arafalov Solr resources and newsletter: http://www.solr-start.com/ and @solrstart Solr popularizers community: https://www.linkedin.com/groups?gid=6713853 On 1 December 2014 at 11:03, Eric
[jira] [Comment Edited] (SOLR-5890) Delete silently fails if not sent to shard where document was added
[ https://issues.apache.org/jira/browse/SOLR-5890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234211#comment-14234211 ] Ishan Chattopadhyaya edited comment on SOLR-5890 at 12/4/14 1:58 PM: - Whenever it is not possible to identify the shard correctly (either using id or router.field ) the requests should be distributed across the cluster [~noble.paul] For a deleteById (implicit or compositeId router) without a __route__ parameter, do you think it is reasonable to distribute the request across the cluster always? was (Author: ichattopadhyaya): Whenever it is not possible to identify the shard correctly (either using id or router.field ) the requests should be distributed across the cluster For a deleteById (implicit or compositeId router) without a __route__ parameter, do you think it is reasonable to distribute the request across the cluster always? Delete silently fails if not sent to shard where document was added --- Key: SOLR-5890 URL: https://issues.apache.org/jira/browse/SOLR-5890 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.7 Environment: Debian 7.4. Reporter: Peter Inglesby Assignee: Noble Paul Labels: difficulty-medium, impact-medium, workaround-exists Fix For: 5.0, Trunk We have SolrCloud set up with two shards, each with a leader and a replica. We use haproxy to distribute requests between the four nodes. Regardless of which node we send an add request to, following a commit, the newly-added document is returned in a search, as expected. However, we can only delete a document if the delete request is sent to a node in the shard where the document was added. If we send the delete request to a node in the other shard (and then send a commit) the document is not deleted. Such a delete request will get a 200 response, with the following body: {'responseHeader'={'status'=0,'QTime'=7}} Apart from the the very low QTime, this is indistinguishable from a successful delete. -- This message was sent by Atlassian JIRA (v6.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-5890) Delete silently fails if not sent to shard where document was added
[ https://issues.apache.org/jira/browse/SOLR-5890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234211#comment-14234211 ] Ishan Chattopadhyaya commented on SOLR-5890: Whenever it is not possible to identify the shard correctly (either using id or router.field ) the requests should be distributed across the cluster For a deleteById (implicit or compositeId router) without a __route__ parameter, do you think it is reasonable to distribute the request across the cluster always? Delete silently fails if not sent to shard where document was added --- Key: SOLR-5890 URL: https://issues.apache.org/jira/browse/SOLR-5890 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.7 Environment: Debian 7.4. Reporter: Peter Inglesby Assignee: Noble Paul Labels: difficulty-medium, impact-medium, workaround-exists Fix For: 5.0, Trunk We have SolrCloud set up with two shards, each with a leader and a replica. We use haproxy to distribute requests between the four nodes. Regardless of which node we send an add request to, following a commit, the newly-added document is returned in a search, as expected. However, we can only delete a document if the delete request is sent to a node in the shard where the document was added. If we send the delete request to a node in the other shard (and then send a commit) the document is not deleted. Such a delete request will get a 200 response, with the following body: {'responseHeader'={'status'=0,'QTime'=7}} Apart from the the very low QTime, this is indistinguishable from a successful delete. -- This message was sent by Atlassian JIRA (v6.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 # 693 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/693/ No tests ran. Build Log: [...truncated 4 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.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) 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:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at
[JENKINS] Lucene-Artifacts-5.x - Build # 701 - Still Failing
Build: https://builds.apache.org/job/Lucene-Artifacts-5.x/701/ 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.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) 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:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:520)
[JENKINS] Solr-Artifacts-5.x - Build # 677 - Still Failing
Build: https://builds.apache.org/job/Solr-Artifacts-5.x/677/ 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.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) 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:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:520)
[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #1279: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1279/ No tests ran. Build Log: [...truncated 4 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.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) 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:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:520) ... 35 more Caused by: java.net.ConnectException:
[jira] [Commented] (SOLR-6818) Delegating collector in Analytics API returns not right docNum in collect method
[ https://issues.apache.org/jira/browse/SOLR-6818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234219#comment-14234219 ] Joel Bernstein commented on SOLR-6818: -- Daulet, Your initial question was answered by Alan. I also took a quick look at your post on stackoverflow: http://stackoverflow.com/questions/27164634/solr-analyticsquery-api-returns-analytics-by-documents-that-dont-match-query There are also other problems with the code you posted. You actually want to use the segment level docId to collect the analytics. But you don't want to use the searcher. You'll want to review the API's for the DocValues and FieldCache which allow you to access fields much more efficiently then going through the searcher. Delegating collector in Analytics API returns not right docNum in collect method Key: SOLR-6818 URL: https://issues.apache.org/jira/browse/SOLR-6818 Project: Solr Issue Type: Bug Affects Versions: 4.10.2 Reporter: Daulet Kadirbekov Delegating collector in Analytics API returns not right docNum in collect method. I have used Analytics API in my solr. I created ResourceAnalyticsCollector which extends DelegatingCollector class. In that class there is collect(int docNum) method. This is the continue of https://issues.apache.org/jira/browse/SOLR-6802 issue. The problem that I found that the docNum value is repeated in collect method of DelegatingCollector. -- 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-4470) Support for basic http auth in internal solr requests
[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234220#comment-14234220 ] Shai Erera commented on SOLR-4470: -- bq. No. Actually I thought Jan Høydahl removed the added API methods Hmm, I downloaded the latest SOLR-4470.patch, which seems to be the latest of all other patches too, dating 14/Mar/14. bq. I think you are focusing too much on the API changes, though. It is a fairly small part of the patch. You're right :). But that's the first thing that caught my eyes - at least 10% of the patch seem to be involving these API changes. So in trying to help understand how can this patch be split into (hopefully *much*) smaller patches, I saw this as a low hanging fruit. When I started my way in this community, I used to think like you - I've done some work, so let me just drop it into JIRA and get a committer to commit it. Not because it's perfect, but because it's mature and product-ready - we can always iterate and improve afterwards. Over the years I've learned that it doesn't work that way - small patches require less time of a committer to review and approve. This is also in general how we develop software. I'm sure you didn't code all of this in a single stroke. And I bet that in your private SVN (or whatever you use), these changes were done over multiple commits. To you, this is one piece of work ready to get in. To the community, it's a giant clob that will be committed without a decent chance to review it thoroughly, and explore alternatives. It's just too overwhelming to think about it from the start, like we would have if you e.g. opened a JIRA and said hey, I want to add basic-auth to Solr, let's discuss. So maybe one suggestion I would make is - don't give up on this patch. Use this issue as an umbrella issue for adding basic-auth to Solr. Tell us here's the entire piece of work that I've done, now I want to do it in steps (baby steps preferred). And then open subsequent issues to address different places of the code that involve basic-auth. Even if this work *must* be committed as a whole to trunk, that's fine. We'll do this work entirely in a branch, but still - multiple issues. That way, each commit gets its proper review. When it's merged to trunk, we're sure of the design, the tests and everything else. I didn't get too deep into it, but I do believe that it can be done on trunk though, in baby steps. Remember, basic-auth can exist in the code hidden, until we feel it's ready. So e.g. it's OK if the first commit only adds basic-auth to UpdateRequest, then to HttpSolrServer, then to CloudSolrServer etc ... they don't all need to support it from the start. Support for basic http auth in internal solr requests - Key: SOLR-4470 URL: https://issues.apache.org/jira/browse/SOLR-4470 Project: Solr Issue Type: New Feature Components: clients - java, multicore, replication (java), SolrCloud Affects Versions: 4.0 Reporter: Per Steffensen Assignee: Jan Høydahl Labels: authentication, https, solrclient, solrcloud, ssl Fix For: Trunk Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch, SOLR-4470_trunk_r1568857.patch We want to protect any HTTP-resource (url). We want to require credentials no matter what kind of HTTP-request you make to a Solr-node. It can faily easy be acheived as described on http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes also make internal request to other Solr-nodes, and for it to work credentials need to be provided here also. Ideally we would like to forward credentials from a particular request to all the internal sub-requests it triggers. E.g. for search and update request. But there are also internal requests * that only indirectly/asynchronously triggered from outside requests (e.g. shard creation/deletion/etc based on calls to the Collection API) * that do not in any way have relation to an outside super-request (e.g. replica synching stuff) We would like to aim at a solution where original credentials are forwarded when a request directly/synchronously trigger a subrequest, and fallback to a configured internal credentials for the asynchronous/non-rooted requests. In our solution we would aim at only supporting basic http auth, but we would like to make a framework around it, so that not to much refactoring is needed if you later want to make support for other kinds of auth (e.g. digest)
[jira] [Comment Edited] (SOLR-6816) Review SolrCloud Indexing Performance.
[ https://issues.apache.org/jira/browse/SOLR-6816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14233651#comment-14233651 ] Mark Miller edited comment on SOLR-6816 at 12/4/14 2:34 PM: I'm starting to feel around the edges with 2 of my local machines and simple benchmarking. I've found two fairly concerning things so far: * I can't seem to saturate any key resource. * The VersionInfo bucket size appears to be a large bottleneck with replication (we lock on this bucket in DistributedUpdateProcessor for the entire document add). I've attached a PDF record of my runs that I'm keeping. was (Author: markrmil...@gmail.com): I'm starting to feel around the edges with 2 of my local machines and simple benchmarking. I've found two fairy concerning things so far: * I can't seem to saturate any key resource. * The VersionInfo bucket size appears to be a large bottleneck with replication (we lock on this bucket in DistributedUpdateProcessor for the entire document add). I've attached a PDF record of my runs that I'm keeping. Review SolrCloud Indexing Performance. -- Key: SOLR-6816 URL: https://issues.apache.org/jira/browse/SOLR-6816 Project: Solr Issue Type: Task Components: SolrCloud Reporter: Mark Miller Priority: Critical Attachments: SolrBench.pdf We have never really focused on indexing performance, just correctness and low hanging fruit. We need to vet the performance and try to address any holes. Note: A common report is that adding any replication is very slow. -- 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-6821) It's difficult to saturate a Solr servers resources when bulk indexing. Using multiple JVM's on a single machine can drastically improve indexing performance.
[ https://issues.apache.org/jira/browse/SOLR-6821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234237#comment-14234237 ] Mark Miller commented on SOLR-6821: --- Non SolrCloud mode did not seem to fair any better. It's difficult to saturate a Solr servers resources when bulk indexing. Using multiple JVM's on a single machine can drastically improve indexing performance. -- Key: SOLR-6821 URL: https://issues.apache.org/jira/browse/SOLR-6821 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Mark Miller -- 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-6819) Being able to configure the updates log implementation from solrconfig.xml
[ https://issues.apache.org/jira/browse/SOLR-6819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Renaud Delbru updated SOLR-6819: Attachment: SOLR-6819.patch The patch implementing the extension to configure the class of the updates log. This makes also the update log initialisation part of the UpdateHandler more cleaner. Specific instructions for the configuration of the HdfsUpdateLog has been moved withing HdfsUpdateLog itself. Being able to configure the updates log implementation from solrconfig.xml -- Key: SOLR-6819 URL: https://issues.apache.org/jira/browse/SOLR-6819 Project: Solr Issue Type: Improvement Components: SolrCloud, update Affects Versions: Trunk Reporter: Renaud Delbru Attachments: SOLR-6819.patch CDCR requires its own implementation of the updates log. At the moment, there is no way to configure the class to use when instantiating the updates log. The UpdateHandler is deciding to instantiate the base class UpdateLog or its hdfs version HdfsUpdateLog based on the directory path prefix. We can extend the UpdateHandler to allow for a class parameter to be defined for the updateLog section of the solrconfig.xml. For example, the relevant part of the solrconfig,xml will look like: {code:xml} updateHandler class=solr.DirectUpdateHandler2 updateLog class=solr.CdcrUpdateLog str name=dir${solr.ulog.dir:}/str /updateLog /updateHandler {code} where the updateLog entry has a parameter class that indicates that the CdcrUpdateLog implementation must be used. -- 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.7.0_67) - Build # 11549 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11549/ Java: 64bit/jdk1.7.0_67 -XX:-UseCompressedOops -XX:+UseSerialGC (asserts: true) All tests passed Build Log: [...truncated 4089 lines...] [javac] Compiling 67 source files to /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/queries/classes/java [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/FunctionQuery.java:66: warning: [rawtypes] found raw type: Map [javac] protected final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:43: warning: [rawtypes] found raw type: Map [javac] public abstract FunctionValues getValues(Map context, LeafReaderContext readerContext) throws IOException; [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:67: warning: [rawtypes] found raw type: Map [javac] public void createWeight(Map context, IndexSearcher searcher) throws IOException { [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:73: warning: [rawtypes] found raw type: Map [javac] public static Map newContext(IndexSearcher searcher) { [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: Map [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: IdentityHashMap [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class IdentityHashMapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in class IdentityHashMap [javac] V extends Object declared in class IdentityHashMap [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:75: warning: [unchecked] unchecked call to put(K,V) as a member of the raw type Map [javac] context.put(searcher, searcher); [javac]^ [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:104: warning: [rawtypes] found raw type: Map [javac] Map context = newContext(searcher); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:111: warning: [rawtypes] found raw type: Map [javac] private final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac]
[jira] [Commented] (SOLR-4470) Support for basic http auth in internal solr requests
[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234279#comment-14234279 ] David Webster commented on SOLR-4470: - Shai, we took a bit of a different approach than Per did. This patch is much more complete and robust that our solution as it deals with securing the server (receiving) side of the SOLR cloud at the API level. Instead of relying on the complete patch version to secure our SOLR cloud we simply added our internal auth mechanism on the client side by modifying four lines of code of the HTTPClient side, and then shelled out all the security on the server side out to a JAAS TomcatLogin module implemented as a Tomcat Valve. We were able to do that because SOLR ships as a WAR deployable to a servlet container. They break that model and we are brokenagain. Per's patch, I don't believe, would be affected by that architectural change. The benefit to us is that now when SOLR releases happen, all we have to do patch is four lines of client side code and we can adopt the body of the rest of the SOLR upgrade, as-is. Support for basic http auth in internal solr requests - Key: SOLR-4470 URL: https://issues.apache.org/jira/browse/SOLR-4470 Project: Solr Issue Type: New Feature Components: clients - java, multicore, replication (java), SolrCloud Affects Versions: 4.0 Reporter: Per Steffensen Assignee: Jan Høydahl Labels: authentication, https, solrclient, solrcloud, ssl Fix For: Trunk Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch, SOLR-4470_trunk_r1568857.patch We want to protect any HTTP-resource (url). We want to require credentials no matter what kind of HTTP-request you make to a Solr-node. It can faily easy be acheived as described on http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes also make internal request to other Solr-nodes, and for it to work credentials need to be provided here also. Ideally we would like to forward credentials from a particular request to all the internal sub-requests it triggers. E.g. for search and update request. But there are also internal requests * that only indirectly/asynchronously triggered from outside requests (e.g. shard creation/deletion/etc based on calls to the Collection API) * that do not in any way have relation to an outside super-request (e.g. replica synching stuff) We would like to aim at a solution where original credentials are forwarded when a request directly/synchronously trigger a subrequest, and fallback to a configured internal credentials for the asynchronous/non-rooted requests. In our solution we would aim at only supporting basic http auth, but we would like to make a framework around it, so that not to much refactoring is needed if you later want to make support for other kinds of auth (e.g. digest) We will work at a solution but create this JIRA issue early in order to get input/comments from the community as early as possible. -- This message was sent by Atlassian JIRA (v6.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-6816) Review SolrCloud Indexing Performance.
[ https://issues.apache.org/jira/browse/SOLR-6816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234281#comment-14234281 ] Mark Miller commented on SOLR-6816: --- Another note: I also am beginning to have reason to believe we have lost a decent percentage of indexing performance since at least 4.4 or 4.5. Review SolrCloud Indexing Performance. -- Key: SOLR-6816 URL: https://issues.apache.org/jira/browse/SOLR-6816 Project: Solr Issue Type: Task Components: SolrCloud Reporter: Mark Miller Priority: Critical Attachments: SolrBench.pdf We have never really focused on indexing performance, just correctness and low hanging fruit. We need to vet the performance and try to address any holes. Note: A common report is that adding any replication is very slow. -- 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-4470) Support for basic http auth in internal solr requests
[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234286#comment-14234286 ] David Webster commented on SOLR-4470: - In other words, we focused solely on the auth securitythis patch is much deeper than just that Support for basic http auth in internal solr requests - Key: SOLR-4470 URL: https://issues.apache.org/jira/browse/SOLR-4470 Project: Solr Issue Type: New Feature Components: clients - java, multicore, replication (java), SolrCloud Affects Versions: 4.0 Reporter: Per Steffensen Assignee: Jan Høydahl Labels: authentication, https, solrclient, solrcloud, ssl Fix For: Trunk Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch, SOLR-4470_trunk_r1568857.patch We want to protect any HTTP-resource (url). We want to require credentials no matter what kind of HTTP-request you make to a Solr-node. It can faily easy be acheived as described on http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes also make internal request to other Solr-nodes, and for it to work credentials need to be provided here also. Ideally we would like to forward credentials from a particular request to all the internal sub-requests it triggers. E.g. for search and update request. But there are also internal requests * that only indirectly/asynchronously triggered from outside requests (e.g. shard creation/deletion/etc based on calls to the Collection API) * that do not in any way have relation to an outside super-request (e.g. replica synching stuff) We would like to aim at a solution where original credentials are forwarded when a request directly/synchronously trigger a subrequest, and fallback to a configured internal credentials for the asynchronous/non-rooted requests. In our solution we would aim at only supporting basic http auth, but we would like to make a framework around it, so that not to much refactoring is needed if you later want to make support for other kinds of auth (e.g. digest) We will work at a solution but create this JIRA issue early in order to get input/comments from the community as early as possible. -- This message was sent by Atlassian JIRA (v6.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-6127) Improve Solr's exampledocs data
[ https://issues.apache.org/jira/browse/SOLR-6127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-6127: --- Priority: Major (was: Minor) Improve Solr's exampledocs data --- Key: SOLR-6127 URL: https://issues.apache.org/jira/browse/SOLR-6127 Project: Solr Issue Type: Improvement Components: documentation, scripts and tools Reporter: Varun Thacker Assignee: Erik Hatcher Fix For: 5.0, Trunk Attachments: LICENSE.txt, README.txt, README.txt, film.csv, film.json, film.xml, freebase_film_dump.py, freebase_film_dump.py, freebase_film_dump.py, freebase_film_dump.py, freebase_film_dump.py, freebase_film_dump.py, freebase_film_dump.py Currently - The CSV example has 10 documents. - The JSON example has 4 documents. - The XML example has 32 documents. 1. We should have equal number of documents and the same documents in all the example formats 2. A data set which is slightly more comprehensive. -- 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-6821) It's difficult to saturate a Solr servers resources when bulk indexing. Using multiple JVM's on a single machine can drastically improve indexing performance.
[ https://issues.apache.org/jira/browse/SOLR-6821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234318#comment-14234318 ] Mikhail Khludnev commented on SOLR-6821: I wonder if you bear SOLR-3585 in mind? It's difficult to saturate a Solr servers resources when bulk indexing. Using multiple JVM's on a single machine can drastically improve indexing performance. -- Key: SOLR-6821 URL: https://issues.apache.org/jira/browse/SOLR-6821 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Mark Miller -- 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-Tests-5.x-Java7 - Build # 2279 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2279/ No tests ran. Build Log: [...truncated 3 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.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) 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:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at
[jira] [Reopened] (SOLR-6653) bin/solr start script should return error code 0 when something fails
[ https://issues.apache.org/jira/browse/SOLR-6653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Potter reopened SOLR-6653: -- oops! one of the changes I added for this broke restart ability bin/solr start script should return error code 0 when something fails -- Key: SOLR-6653 URL: https://issues.apache.org/jira/browse/SOLR-6653 Project: Solr Issue Type: Bug Components: scripts and tools Affects Versions: 4.10.1 Reporter: Jan Høydahl Assignee: Timothy Potter Labels: bin/solr Fix For: 4.10.3, 5.0 In order to be able to include {{bin/solr}} in scripts, it should be possible to test the return value for success or failure. Examples: {noformat} jan:solr janhoy$ bin/solr start Waiting to see Solr listening on port 8983 [/] Started Solr server on port 8983 (pid=47354). Happy searching! jan:solr janhoy$ echo $? 0 jan:solr janhoy$ bin/solr start Solr already running on port 8983 (pid: 47354)! Please use the 'restart' command if you want to restart this node. jan:solr janhoy$ echo $? 0 {noformat} The last command should return status 1 {noformat} jan:solr janhoy$ bin/solr stop -p 1234 No process found for Solr node running on port 1234 jan:solr janhoy$ echo $? 0 {noformat} Same here. Probably other places too. -- 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-6820) The sync on the VersionInfo bucket in DistributedUpdateProcesser#addDocument appears to be a large bottleneck when using replication.
[ https://issues.apache.org/jira/browse/SOLR-6820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234328#comment-14234328 ] Yonik Seeley commented on SOLR-6820: That's pretty surprising... with a 6 core CPU, it's unclear how 256 buckets could cause that much contention. The id's are UUIDs, and they are hashed with murmur3... it should be well distributed. Is the occasional block causing something else bad to happen in the whole stack (sending clients, etc)? The sync on the VersionInfo bucket in DistributedUpdateProcesser#addDocument appears to be a large bottleneck when using replication. - Key: SOLR-6820 URL: https://issues.apache.org/jira/browse/SOLR-6820 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Mark Miller -- 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-trunk-Windows (64bit/jdk1.8.0_20) - Build # 4470 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4470/ Java: 64bit/jdk1.8.0_20 -XX:+UseCompressedOops -XX:+UseG1GC (asserts: true) All tests passed Build Log: [...truncated 58494 lines...] -documentation-lint: [jtidy] Checking for broken html (such as invalid tags)... [delete] Deleting directory C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\jtidy_tmp [echo] Checking for broken links... [exec] [exec] Crawl/parse... [exec] [exec] Verify... [exec] [exec] file:///C%3A/Users/JenkinsSlave/workspace/Lucene-Solr-trunk-Windows/solr/build/docs/solr-dataimporthandler/org/apache/solr/handler/dataimport/EntityProcessorBase.html [exec] BROKEN LINK: file:///C%3A/Users/JenkinsSlave/workspace/Lucene-Solr-trunk-Windows/solr/build/docs/solr-core/org/apache/solr/handler/dataimport.Zipper.html [exec] BROKEN LINK: file:///C%3A/Users/JenkinsSlave/workspace/Lucene-Solr-trunk-Windows/solr/build/docs/solr-core/org/apache/solr/handler/dataimport.Zipper.html [exec] [exec] Broken javadocs links were found! BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:519: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:83: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build.xml:554: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build.xml:567: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\common-build.xml:2388: exec returned: 1 Total time: 185 minutes 41 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 64bit/jdk1.8.0_20 -XX:+UseCompressedOops -XX:+UseG1GC (asserts: true) Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Odd Solr version in Jira - SOLR-6607
Along with the expected 4.10.3, 5.0, and Trunk, there's another unreleased Solr version showing in Jira -- SOLR-6607. https://issues.apache.org/jira/browse/SOLR A cropped screenshot: https://www.dropbox.com/s/yb5p44f4352nvt8/odd-solr-version-in-jira.png?dl=0 I think this may be a mistake, but I don't want to assume. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.8.0_20) - Build # 4365 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4365/ Java: 32bit/jdk1.8.0_20 -client -XX:+UseParallelGC (asserts: true) All tests passed Build Log: [...truncated 4079 lines...] [javac] Compiling 67 source files to C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\build\queries\classes\java [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\FunctionQuery.java:66: warning: [rawtypes] found raw type: Map [javac] protected final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:43: warning: [rawtypes] found raw type: Map [javac] public abstract FunctionValues getValues(Map context, LeafReaderContext readerContext) throws IOException; [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:67: warning: [rawtypes] found raw type: Map [javac] public void createWeight(Map context, IndexSearcher searcher) throws IOException { [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:73: warning: [rawtypes] found raw type: Map [javac] public static Map newContext(IndexSearcher searcher) { [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:74: warning: [rawtypes] found raw type: Map [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:74: warning: [rawtypes] found raw type: IdentityHashMap [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class IdentityHashMapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in class IdentityHashMap [javac] V extends Object declared in class IdentityHashMap [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:75: warning: [unchecked] unchecked call to put(K,V) as a member of the raw type Map [javac] context.put(searcher, searcher); [javac]^ [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:104: warning: [rawtypes] found raw type: Map [javac] Map context = newContext(searcher); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\queries\src\java\org\apache\lucene\queries\function\ValueSource.java:111: warning: [rawtypes] found raw type: Map [javac] private final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac]
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_40-ea-b09) - Build # 11550 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11550/ Java: 64bit/jdk1.8.0_40-ea-b09 -XX:-UseCompressedOops -XX:+UseParallelGC (asserts: true) All tests passed Build Log: [...truncated 4098 lines...] [javac] Compiling 67 source files to /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/queries/classes/java [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/FunctionQuery.java:66: warning: [rawtypes] found raw type: Map [javac] protected final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:43: warning: [rawtypes] found raw type: Map [javac] public abstract FunctionValues getValues(Map context, LeafReaderContext readerContext) throws IOException; [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:67: warning: [rawtypes] found raw type: Map [javac] public void createWeight(Map context, IndexSearcher searcher) throws IOException { [javac]^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:73: warning: [rawtypes] found raw type: Map [javac] public static Map newContext(IndexSearcher searcher) { [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: Map [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:74: warning: [rawtypes] found raw type: IdentityHashMap [javac] Map context = new IdentityHashMap(); [javac] ^ [javac] missing type arguments for generic class IdentityHashMapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in class IdentityHashMap [javac] V extends Object declared in class IdentityHashMap [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:75: warning: [unchecked] unchecked call to put(K,V) as a member of the raw type Map [javac] context.put(searcher, searcher); [javac]^ [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:104: warning: [rawtypes] found raw type: Map [javac] Map context = newContext(searcher); [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java:111: warning: [rawtypes] found raw type: Map [javac] private final Map context; [javac] ^ [javac] missing type arguments for generic class MapK,V [javac] where K,V are type-variables: [javac] K extends Object declared in interface Map [javac] V extends Object declared in interface Map [javac]
[jira] [Updated] (SOLR-5641) REST API to modify request handlers
[ https://issues.apache.org/jira/browse/SOLR-5641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-5641: --- Fix Version/s: (was: SOLR-6607) remove bogus fix version REST API to modify request handlers --- Key: SOLR-5641 URL: https://issues.apache.org/jira/browse/SOLR-5641 Project: Solr Issue Type: Sub-task Reporter: Willy Solaligue Attachments: SOLR-5641.patch, SolrConfigApiDocumentation.pdf There should be a REST API to allow modify request handlers. -- 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