[jira] [Created] (SOLR-6818) Delegating collector in Analytics API returns not right docNum in collect method

2014-12-04 Thread Daulet Kadirbekov (JIRA)
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

2014-12-04 Thread Daulet Kadirbekov (JIRA)

 [ 
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

2014-12-04 Thread Daulet Kadirbekov (JIRA)

[ 
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

2014-12-04 Thread Forest Soup (JIRA)

[ 
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

2014-12-04 Thread Forest Soup (JIRA)

[ 
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

2014-12-04 Thread Forest Soup (JIRA)

[ 
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

2014-12-04 Thread Adrien Grand (JIRA)

[ 
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

2014-12-04 Thread Alan Woodward (JIRA)

[ 
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

2014-12-04 Thread Per Steffensen (JIRA)

[ 
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

2014-12-04 Thread Per Steffensen (JIRA)

[ 
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

2014-12-04 Thread Michael McCandless (JIRA)

 [ 
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

2014-12-04 Thread Per Steffensen (JIRA)

 [ 
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

2014-12-04 Thread Per Steffensen (JIRA)

[ 
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

2014-12-04 Thread Shai Erera (JIRA)

[ 
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

2014-12-04 Thread Daulet Kadirbekov (JIRA)

 [ 
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

2014-12-04 Thread Daulet Kadirbekov (JIRA)

 [ 
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

2014-12-04 Thread Daulet Kadirbekov (JIRA)

 [ 
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

2014-12-04 Thread Daulet Kadirbekov (JIRA)

 [ 
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

2014-12-04 Thread Renaud Delbru (JIRA)
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

2014-12-04 Thread Robert Muir (JIRA)

[ 
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

2014-12-04 Thread Robert Muir (JIRA)

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

2014-12-04 Thread Per Steffensen (JIRA)

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

2014-12-04 Thread Per Steffensen (JIRA)

[ 
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

2014-12-04 Thread Apache Jenkins Server
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!

2014-12-04 Thread Policeman Jenkins Server
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

2014-12-04 Thread Apache Jenkins Server
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

2014-12-04 Thread Apache Jenkins Server
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

2014-12-04 Thread Apache Jenkins Server
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

2014-12-04 Thread Apache Jenkins Server
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!

2014-12-04 Thread Policeman Jenkins Server
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

2014-12-04 Thread Michael Wechner
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

2014-12-04 Thread Apache Jenkins Server
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

2014-12-04 Thread Apache Jenkins Server
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

2014-12-04 Thread Robert Muir (JIRA)

 [ 
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!

2014-12-04 Thread Policeman Jenkins Server
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!

2014-12-04 Thread Policeman Jenkins Server
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!

2014-12-04 Thread Policeman Jenkins Server
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!

2014-12-04 Thread Policeman Jenkins Server
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!

2014-12-04 Thread Policeman Jenkins Server
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

2014-12-04 Thread Apache Jenkins Server
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!

2014-12-04 Thread Policeman Jenkins Server
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!

2014-12-04 Thread Shawn Heisey
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

2014-12-04 Thread Per Steffensen (JIRA)

[ 
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

2014-12-04 Thread Apache Jenkins Server
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!

2014-12-04 Thread Policeman Jenkins Server
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!

2014-12-04 Thread Policeman Jenkins Server
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!

2014-12-04 Thread Policeman Jenkins Server
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

2014-12-04 Thread Apache Jenkins Server
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

2014-12-04 Thread Apache Jenkins Server
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!

2014-12-04 Thread Policeman Jenkins Server
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

2014-12-04 Thread Apache Jenkins Server
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!

2014-12-04 Thread Policeman Jenkins Server
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!

2014-12-04 Thread Policeman Jenkins Server
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

2014-12-04 Thread Mark Miller (JIRA)

[ 
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!

2014-12-04 Thread Policeman Jenkins Server
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!

2014-12-04 Thread Policeman Jenkins Server
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

2014-12-04 Thread Apache Jenkins Server
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.

2014-12-04 Thread Mark Miller (JIRA)
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

2014-12-04 Thread Alexandre Rafalovitch
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.

2014-12-04 Thread Mark Miller (JIRA)

[ 
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!

2014-12-04 Thread Policeman Jenkins Server
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!

2014-12-04 Thread Policeman Jenkins Server
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!

2014-12-04 Thread Policeman Jenkins Server
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

2014-12-04 Thread david.w.smi...@gmail.com
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!

2014-12-04 Thread Policeman Jenkins Server
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!

2014-12-04 Thread Chris Hostetter

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

2014-12-04 Thread Dawid Weiss
 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

2014-12-04 Thread Robert Muir (JIRA)

[ 
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

2014-12-04 Thread david.w.smi...@gmail.com
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

2014-12-04 Thread Ishan Chattopadhyaya (JIRA)

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

2014-12-04 Thread Mark Miller (JIRA)
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!

2014-12-04 Thread Policeman Jenkins Server
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

2014-12-04 Thread Ishan Chattopadhyaya (JIRA)

[ 
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

2014-12-04 Thread Ishan Chattopadhyaya (JIRA)

[ 
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

2014-12-04 Thread Alexandre Rafalovitch
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

2014-12-04 Thread Ishan Chattopadhyaya (JIRA)

[ 
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

2014-12-04 Thread Ishan Chattopadhyaya (JIRA)

[ 
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

2014-12-04 Thread Apache Jenkins Server
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

2014-12-04 Thread Apache Jenkins Server
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

2014-12-04 Thread Apache Jenkins Server
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

2014-12-04 Thread Apache Jenkins Server
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

2014-12-04 Thread Joel Bernstein (JIRA)

[ 
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

2014-12-04 Thread Shai Erera (JIRA)

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

2014-12-04 Thread Mark Miller (JIRA)

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

2014-12-04 Thread Mark Miller (JIRA)

[ 
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

2014-12-04 Thread Renaud Delbru (JIRA)

 [ 
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!

2014-12-04 Thread Policeman Jenkins Server
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

2014-12-04 Thread David Webster (JIRA)

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

2014-12-04 Thread Mark Miller (JIRA)

[ 
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

2014-12-04 Thread David Webster (JIRA)

[ 
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

2014-12-04 Thread Erik Hatcher (JIRA)

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

2014-12-04 Thread Mikhail Khludnev (JIRA)

[ 
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

2014-12-04 Thread Apache Jenkins Server
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

2014-12-04 Thread Timothy Potter (JIRA)

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

2014-12-04 Thread Yonik Seeley (JIRA)

[ 
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!

2014-12-04 Thread Policeman Jenkins Server
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

2014-12-04 Thread Shawn Heisey
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!

2014-12-04 Thread Policeman Jenkins Server
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!

2014-12-04 Thread Policeman Jenkins Server
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

2014-12-04 Thread Hoss Man (JIRA)

 [ 
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



  1   2   >