[jira] [Commented] (SOLR-9493) uniqueKey generation fails if content POSTed as "application/javabin".

[Alexandre Rafalovitch (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15481057#comment-15481057
 ] 

Alexandre Rafalovitch commented on SOLR-9493:
-

Any chance you could try this with the latest Solr (6.2 or master)? There has 
been quite a lot of changes and it would be good to know if that's something 
that's already been fixed under a different name or still a valid issue.

> uniqueKey generation fails if content POSTed as "application/javabin".
> --
>
> Key: SOLR-9493
> URL: https://issues.apache.org/jira/browse/SOLR-9493
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Yury Kartsev
> Attachments: 200.png, 400.png
>
>
> I have faced a weird issue when the same application code (using SolrJ) fails 
> indexing a document without a unique key (should be auto-generated by SOLR) 
> in SolrCloud and succeeds indexing it in standalone SOLR instance (or even in 
> cloud mode, but from web interface of one of the replicas). Difference is 
> obviously only between clients (CloudSolrClient vs HttpSolrClient) and SOLR 
> URLs (Zokeeper hostname+port vs standalone SOLR instance hostname and port). 
> Failure is seen as "org.apache.solr.client.solrj.SolrServerException: 
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: 
> Document is missing mandatory uniqueKey field: id".
> I am using SOLR 5.1. In cloud mode I have 1 shard and 3 replicas.
> After lot of debugging and investigation (see below as well as my 
> [StackOverflow 
> post|http://stackoverflow.com/questions/39401792/uniquekey-generation-does-not-work-in-solrcloud-but-works-if-standalone])
>  I came to a conclusion that the difference in failing and succeeding calls 
> is simply content type of the POSTing requests. Local proxy clearly shows 
> that the request fails if content is sent as "application/javabin" (see 
> attached screenshot with sensitive data removed) and succeeds if content sent 
> as "application/xml; charset=UTF-8"  (see attached screenshot with sensitive 
> data removed).
> Would you be able to please assist?
> Thank you very much in advance!
> 
> Copying whole description and investigation here as well:
> 
> [Documentation|https://cwiki.apache.org/confluence/display/solr/Other+Schema+Elements]
>  states:{quote}Schema defaults and copyFields cannot be used to populate the 
> uniqueKey field. You can use UUIDUpdateProcessorFactory to have uniqueKey 
> values generated automatically.{quote}
> Therefore I have added my uniqueKey field to the schema:{code} name="uuid" class="solr.UUIDField" indexed="true" />
> ...
> 
> ...
> id{code}Then I have added updateRequestProcessorChain 
> to my solrconfig:{code}
> 
> id
> 
> 
> {code}And made it the default for the 
> UpdateRequestHandler:{code}
>  
>   uuid
>  
> {code}
> Adding new documents with null/absent id works fine as from web-interface of 
> one of the replicas, as when using SOLR in standalone mode (non-cloud) from 
> my application. Although when only I'm using SolrCloud and add document from 
> my application (using CloudSolrClient from SolrJ) it fails with 
> "org.apache.solr.client.solrj.SolrServerException: 
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: 
> Document is missing mandatory uniqueKey field: id"
> All other operations like ping or search for documents work fine in either 
> mode (standalone or cloud).
> INVESTIGATION (i.e. more details):
> In standalone mode obviously update request is:{code}POST 
> standalone_host:port/solr/collection_name/update?wt=json{code}
> In SOLR cloud mode, when adding document from one replica's web interface, 
> update request is (found through inspecting the call made by web interface): 
> {code}POST 
> replica_host:port/solr/collection_name_shard1_replica_1/update?wt=json{code}
> In both these cases payload is something like:{code}{
> "add": {
> "doc": {
>  .
> },
> "boost": 1.0,
> "overwrite": true,
> "commitWithin": 1000
> }
> }{code}
> In case when CloudSolrClient is used, the following happens (found through 
> debugging):
> Using ZK and some logic, URL list of replicas is constructed that looks like 
> this:{code}[http://replica_1_host:port/solr/collection_name/,
>  http://replica_2_host:port/solr/collection_name/,
>  http://replica_3_host:port/solr/collection_name/]{code}
> This code is called:{code}LBHttpSolrClient.Req req = new 
> LBHttpSolrClient.Req(request, theUrlList);
> LBHttpSolrClient.Rsp rsp = lbClient.request(req);
> return rsp.getResponse();{code}
> Where the second line fails with the exception.
> If to debug the second line further, it 

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+134) - Build # 17798 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17798/
Java: 32bit/jdk-9-ea+134 -client -XX:+UseG1GC

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.TestSolrConfigHandlerCloud

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([1F47A2C9DA27B742]:0)


FAILED:  org.apache.solr.handler.TestSolrConfigHandlerCloud.test

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([1F47A2C9DA27B742]:0)




Build Log:
[...truncated 12658 lines...]
   [junit4] Suite: org.apache.solr.handler.TestSolrConfigHandlerCloud
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestSolrConfigHandlerCloud_1F47A2C9DA27B742-001/init-core-data-001
   [junit4]   2> 1046755 INFO  
(SUITE-TestSolrConfigHandlerCloud-seed#[1F47A2C9DA27B742]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason="", ssl=0.0/0.0, value=0.0/0.0, 
clientAuth=0.0/0.0)
   [junit4]   2> 1046755 INFO  
(SUITE-TestSolrConfigHandlerCloud-seed#[1F47A2C9DA27B742]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 1046756 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[1F47A2C9DA27B742]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1046757 INFO  (Thread-2083) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1046757 INFO  (Thread-2083) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 1046857 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[1F47A2C9DA27B742]) [] 
o.a.s.c.ZkTestServer start zk server on port:37609
   [junit4]   2> 1046857 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[1F47A2C9DA27B742]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 1046857 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[1F47A2C9DA27B742]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 1046859 INFO  (zkCallback-1226-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@176d0df name:ZooKeeperConnection 
Watcher:127.0.0.1:37609 got event WatchedEvent state:SyncConnected type:None 
path:null path:null type:None
   [junit4]   2> 1046859 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[1F47A2C9DA27B742]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 1046859 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[1F47A2C9DA27B742]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 1046859 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[1F47A2C9DA27B742]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr
   [junit4]   2> 1046860 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[1F47A2C9DA27B742]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 1046860 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[1F47A2C9DA27B742]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 1046861 INFO  (zkCallback-1227-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@12aab72 name:ZooKeeperConnection 
Watcher:127.0.0.1:37609/solr got event WatchedEvent state:SyncConnected 
type:None path:null path:null type:None
   [junit4]   2> 1046861 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[1F47A2C9DA27B742]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 1046861 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[1F47A2C9DA27B742]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 1046861 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[1F47A2C9DA27B742]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/collection1
   [junit4]   2> 1046862 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[1F47A2C9DA27B742]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/collection1/shards
   [junit4]   2> 1046862 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[1F47A2C9DA27B742]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/control_collection
   [junit4]   2> 1046863 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[1F47A2C9DA27B742]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/control_collection/shards
   [junit4]   2> 1046863 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[1F47A2C9DA27B742]) [] 
o.a.s.c.AbstractZkTestCase put 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 1046863 INFO  

[jira] [Created] (SOLR-9497) HttpSolrClient.Builder Returns Unusable Connection

[Will McGinnis (JIRA)]

Will McGinnis created SOLR-9497:
---

 Summary: HttpSolrClient.Builder Returns Unusable Connection
 Key: SOLR-9497
 URL: https://issues.apache.org/jira/browse/SOLR-9497
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: clients - java
Affects Versions: 6.2
 Environment: Java 1.8 Mac OSX
Reporter: Will McGinnis
 Fix For: 6.1.1


SolrClient solr = new HttpSolrClient.Builder(urlString).build();
Exception in thread "main" java.lang.VerifyError: Bad return type
Exception Details:
  Location:
 
org/apache/solr/client/solrj/impl/HttpClientUtil.createClient(Lorg/apache/solr/common/params/SolrParams;Lorg/apache/http/conn/ClientConnectionManager;)Lorg/apache/http/impl/client/CloseableHttpClient;
 @58: areturn
  Reason:
Type 'org/apache/http/impl/client/DefaultHttpClient' (current frame, 
stack[0]) is not assignable to 
'org/apache/http/impl/client/CloseableHttpClient' (from method signature)
  Current Frame:
bci: @58
flags: { }
locals: { 'org/apache/solr/common/params/SolrParams', 
'org/apache/http/conn/ClientConnectionManager', 
'org/apache/solr/common/params/ModifiableSolrParams', 
'org/apache/http/impl/client/DefaultHttpClient' }
stack: { 'org/apache/http/impl/client/DefaultHttpClient' }
  Bytecode:
0x000: bb00 0359 2ab7 0004 4db2 0005 b900 0601
0x010: 0099 001e b200 05bb 0007 59b7 0008 1209
0x020: b600 0a2c b600 0bb6 000c b900 0d02 002b
0x030: b800 104e 2d2c b800 0f2d b0
  Stackmap Table:
append_frame(@47,Object[#143])
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.(HttpSolrClient.java:209)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient$Builder.build(HttpSolrClient.java:874)

I have tried upgrading to httpclient-4.5.2. This appears to create the same 
problem. For now, I use this deprecated, connection code.
return new HttpSolrClient(urlString, new SystemDefaultHttpClient());
Eventually, this hangs the Solr server, because you run out of file handles.
I suspect calling solrClient.close() is doing nothing.
I tried not closing and using a static connection to Solr.
This results in basically, the same problem of, eventually hanging the Solr 
server.



--
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: Is "solr.AnalyzerName" expansion supposed to work for Analyzers?

[Alexandre Rafalovitch]

I feel the total issue might be somewhat above my current code
understanding, but I would be happy to do the grunt work for the
factories to self-describe their parameters. I think that would be
useful in multiple ways. I was already looking at perhaps using MBean
describers for that, as that allows to specify types, acceptable
values, etc.

Regards,
   Alex.

Newsletter and resources for Solr beginners and intermediates:
http://www.solr-start.com/


On 11 September 2016 at 00:12, Uwe Schindler  wrote:
> Hi,
>
> In addition this change (to "name" or "type" in the components) would allow 
> to remove Steve Rowe's hack in AbstractAnalysisFactory to keep the class name 
> in the parameter map for serializing, which is Solr specific and should not 
> be there! With the "official" names, this is no longer needed and Solr could 
> simple serialize the name. This hack hurted me several times already!
>
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>> -Original Message-
>> From: Uwe Schindler [mailto:u...@thetaphi.de]
>> Sent: Saturday, September 10, 2016 6:54 PM
>> To: dev@lucene.apache.org
>> Subject: RE: Is "solr.AnalyzerName" expansion supposed to work for
>> Analyzers?
>>
>> Let's open an issue to do what I proposed! After that you could add the
>> schema editor GUI.
>>
>> I think Robert already proposed back at that time to add an additional
>> abstract method to each factory that returns the acceptable parameter
>> names. So one could select the component with help of SPI set. Once the
>> component was chosen the acceptable configuration parameters can be
>> retrieved from the instance.
>>
>> Uwe
>>
>> -
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: u...@thetaphi.de
>>
>> > -Original Message-
>> > From: Upayavira [mailto:u...@odoko.co.uk]
>> > Sent: Saturday, September 10, 2016 5:21 PM
>> > To: dev@lucene.apache.org
>> > Subject: Re: Is "solr.AnalyzerName" expansion supposed to work for
>> > Analyzers?
>> >
>> > On Sat, 10 Sep 2016, at 04:03 PM, Uwe Schindler wrote:
>> > > To add,
>> > >
>> > > the manages schema really makes it easy to "rewrite". My plan would be:
>> > >
>> > > - Add a new "type" or "name" attribute to schema.xml, which is contrary
>> > > to "class" attribute usage
>> > > - When a manages schema is loaded, the resolving of classes using the
>> > > hack is done as it is now. Warnings are printed as said before.
>> > > - The managed schema is then changes to switch to the new attribute
>> > > (there is a getter to get the symbolic name from the factory, so
>> > > rewriting is easy)
>> > >
>> > > In addition, this simplifies usage: Some GUI could show a dropdown list
>> > > for clicking together the analyzer. We just need to add a schema-REST
>> > > endpoint to get all names.
>> > >
>> > > Maybe open an issue targeted for 6.x / 7.0. I'd be happy to help to fix
>> > > this, although I could only do the SolrResourceLoader and SolrAnalyzer
>> > > stuff.
>> >
>> >  Not knowing how to get a list of acceptable components was the thing
>> >  that stopped me adding that part of the schema API to the admin UI. And
>> >  API to tell you which components exist would be extremely helpful.
>> >
>> > Upayavira
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9495) AIOBE with confusing message for incomplete sort spec in Streaming Expression

[Joel Bernstein (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15480868#comment-15480868
 ] 

Joel Bernstein commented on SOLR-9495:
--

Thanks Gus, looks good. We should get this in for 6.3.

> AIOBE with confusing message for incomplete sort spec in Streaming Expression
> -
>
> Key: SOLR-9495
> URL: https://issues.apache.org/jira/browse/SOLR-9495
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 6.2
> Environment: 6.2.0_RC1
>Reporter: Gus Heck
>Priority: Minor
> Attachments: SOLR-9495.patch
>
>
> I was thinking of using streaming expressions for something, and started to 
> play around with it, but I made a bonehaded mistake, and got an error that's 
> pretty confusing: 
> {code}{"result-set":{"docs":[
> {"EXCEPTION":"1","EOF":true}]}}{code}
> This turns out to be due to: 
> {code}
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.reflect.InvocationTargetException
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at 
> org.apache.solr.client.solrj.io.stream.expr.StreamFactory.createInstance(StreamFactory.java:316)
>   ... 33 more
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
>   at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.parseComp(CloudSolrStream.java:334)
>   at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.init(CloudSolrStream.java:274)
>   at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.(CloudSolrStream.java:181)
>   ... 38 more
> {code}
> The mistake I made was omitting a direction from the sort spec. Attaching 
> trivial patch to provide a better error message...



--
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-master - Build # 1388 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1388/

1 tests failed.
FAILED:  org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:39981/pi_ko/z/forceleader_test_collection_shard1_replica2]

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: No live 
SolrServers available to handle this 
request:[http://127.0.0.1:39981/pi_ko/z/forceleader_test_collection_shard1_replica2]
at 
__randomizedtesting.SeedInfo.seed([48722C3319D162D2:AEE518F320539BB3]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:755)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1161)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1050)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:992)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:753)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:741)
at 
org.apache.solr.cloud.ForceLeaderTest.sendDoc(ForceLeaderTest.java:424)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:131)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_102) - Build # 446 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/446/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.handler.TestReplicationHandler.doTestStressReplication

Error Message:
[index.20160910211614625, index.20160910211617076, index.properties, 
replication.properties, snapshot_metadata] expected:<1> but was:<2>

Stack Trace:
java.lang.AssertionError: [index.20160910211614625, index.20160910211617076, 
index.properties, replication.properties, snapshot_metadata] expected:<1> but 
was:<2>
at 
__randomizedtesting.SeedInfo.seed([C7F24F7FD24F8B5A:1C594FB9D767E2E9]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:909)
at 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:876)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+134) - Build # 1700 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1700/
Java: 32bit/jdk-9-ea+134 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth

Error Message:
IOException occured when talking to server at: https://127.0.0.1:36184/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: https://127.0.0.1:36184/solr
at 
__randomizedtesting.SeedInfo.seed([AC938D6031354D91:10FDFB729566CEEB]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:606)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:158)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_102) - Build # 6110 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6110/
Java: 64bit/jdk1.8.0_102 -XX:+UseCompressedOops -XX:+UseG1GC

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.util.TestSolrCLIRunExample

Error Message:
ObjectTracker found 4 object(s) that were not released!!! 
[MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, SolrCore]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 4 object(s) that were not 
released!!! [MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, 
SolrCore]
at __randomizedtesting.SeedInfo.seed([12EEB736D86EC708]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:257)
at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI

Error Message:
ObjectTracker found 10 object(s) that were not released!!! 
[MDCAwareThreadPoolExecutor, MockDirectoryWrapper, MockDirectoryWrapper, 
TransactionLog, MockDirectoryWrapper, MockDirectoryWrapper, 
MockDirectoryWrapper, TransactionLog, MDCAwareThreadPoolExecutor, 
MockDirectoryWrapper]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 10 object(s) that were not 
released!!! [MDCAwareThreadPoolExecutor, MockDirectoryWrapper, 
MockDirectoryWrapper, TransactionLog, MockDirectoryWrapper, 
MockDirectoryWrapper, MockDirectoryWrapper, TransactionLog, 
MDCAwareThreadPoolExecutor, MockDirectoryWrapper]
at __randomizedtesting.SeedInfo.seed([12EEB736D86EC708]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:257)
at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 579 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/579/

No tests ran.

Build Log:
[...truncated 40563 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (11.9 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.0.0-src.tgz...
   [smoker] 29.9 MB in 0.11 sec (260.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.tgz...
   [smoker] 64.3 MB in 0.08 sec (808.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.zip...
   [smoker] 74.8 MB in 0.10 sec (769.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6012 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6012 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 213 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] Releases that don't seem to be tested:
   [smoker]   5.5.3
   [smoker] Traceback (most recent call last):
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1438, in 
   [smoker] main()
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1382, in main
   [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
c.is_signed, ' '.join(c.test_args))
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1420, in smokeTest
   [smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
version, gitRevision, version, testArgs, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 597, in unpackAndVerify
   [smoker] verifyUnpacked(java, project, artifact, unpackPath, 
gitRevision, version, testArgs, tmpDir, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 743, in verifyUnpacked
   [smoker] confirmAllReleasesAreTestedForBackCompat(version, unpackPath)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1358, in confirmAllReleasesAreTestedForBackCompat
   [smoker] raise RuntimeError('some releases are not tested by 
TestBackwardsCompatibility?')
   [smoker] RuntimeError: some releases are not tested by 
TestBackwardsCompatibility?

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/build.xml:559:
 exec returned: 1

Total time: 68 minutes 53 seconds
Build step 'Invoke Ant' marked build as failure
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

[jira] [Created] (SOLR-9496) SolrJ + Kerberos Requires commons-codec

[Bryan Bende (JIRA)]

Bryan Bende created SOLR-9496:
-

 Summary: SolrJ + Kerberos Requires commons-codec
 Key: SOLR-9496
 URL: https://issues.apache.org/jira/browse/SOLR-9496
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrJ
Affects Versions: 6.2
Reporter: Bryan Bende
Priority: Minor


When using SolrJ 6.2 with Kerberos enabled on the server (also 6.2), the 
following exception was encountered:

{code}
java.lang.NoClassDefFoundError: org/apache/commons/codec/binary/Base64
at 
org.apache.http.impl.auth.GGSSchemeBase.(GGSSchemeBase.java:85) 
~[httpclient-4.4.1.jar:4.4.1]
at org.apache.http.impl.auth.SPNegoScheme.(SPNegoScheme.java:54) 
~[httpclient-4.4.1.jar:4.4.1]
at 
org.apache.http.impl.auth.SPNegoSchemeFactory.newInstance(SPNegoSchemeFactory.java:78)
 ~[httpclient-4.4.1.jar:4.4.1]
at 
org.apache.http.auth.AuthSchemeRegistry.getAuthScheme(AuthSchemeRegistry.java:113)
 ~[httpclient-4.4.1.jar:4.4.1]
at 
org.apache.http.auth.AuthSchemeRegistry$1.create(AuthSchemeRegistry.java:151) 
~[httpclient-4.4.1.jar:4.4.1]
at 
org.apache.http.impl.client.AuthenticationStrategyImpl.select(AuthenticationStrategyImpl.java:188)
 ~[httpclient-4.4.1.jar:4.4.1]
at 
org.apache.http.impl.client.TargetAuthenticationStrategy.select(TargetAuthenticationStrategy.java:43)
 ~[httpclient-4.4.1.jar:4.4.1]
at 
org.apache.http.impl.auth.HttpAuthenticator.handleAuthChallenge(HttpAuthenticator.java:154)
 ~[httpclient-4.4.1.jar:4.4.1]
at 
org.apache.http.impl.client.HttpAuthenticator.authenticate(HttpAuthenticator.java:58)
 ~[httpclient-4.4.1.jar:4.4.1]
at 
org.apache.http.impl.client.DefaultRequestDirector.handleResponse(DefaultRequestDirector.java:1057)
 ~[httpclient-4.4.1.jar:4.4.1]
at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:515)
 ~[httpclient-4.4.1.jar:4.4.1]
at 
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
 ~[httpclient-4.4.1.jar:4.4.1]
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
 ~[httpclient-4.4.1.jar:4.4.1]
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
 ~[httpclient-4.4.1.jar:4.4.1]
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
 ~[httpclient-4.4.1.jar:4.4.1]
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:497)
 ~[na:na]
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
 ~[na:na]
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
 ~[na:na]
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:403)
 ~[na:na]
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:355)
 ~[na:na]
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1291)
 ~[na:na]
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
 ~[na:na]
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
 ~[na:na]
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149) ~[na:na]
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:166) ~[na:na]
{code}

Adding a dependency to my project on commons-codec resolved the issue:
{code}

commons-codec
commons-codec
1.10

{code}

SolrJ should include this dependency if it is required for Kerberos 
authentication. 

If not we should consider updating the SolrJ section on the Wiki page here to 
mention that client application needs to add it:
https://cwiki.apache.org/confluence/display/solr/Kerberos+Authentication+Plugin



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+134) - Build # 17797 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17797/
Java: 32bit/jdk-9-ea+134 -client -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:34018/si_zwg/d/c8n_1x3_lf_shard1_replica2]

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: No live 
SolrServers available to handle this 
request:[http://127.0.0.1:34018/si_zwg/d/c8n_1x3_lf_shard1_replica2]
at 
__randomizedtesting.SeedInfo.seed([10E9EDF2EA7DC836:98BDD2284481A5CE]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:755)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1161)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1050)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:992)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:753)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:741)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:178)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:57)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 383 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/383/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth

Error Message:
IOException occured when talking to server at: https://127.0.0.1:47782/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: https://127.0.0.1:47782/solr
at 
__randomizedtesting.SeedInfo.seed([4A2B627F97BE926A:F645146D33ED1110]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:606)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:158)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[JENKINS] Lucene-Solr-Tests-6.x - Build # 446 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/446/

1 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth

Error Message:
IOException occured when talking to server at: https://127.0.0.1:37613/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: https://127.0.0.1:37613/solr
at 
__randomizedtesting.SeedInfo.seed([D14145E9FA658966:6D2F33FB5E360A1C]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:606)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:158)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 

[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+134) - Build # 1699 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1699/
Java: 64bit/jdk-9-ea+134 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth

Error Message:
IOException occured when talking to server at: https://127.0.0.1:37368/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: https://127.0.0.1:37368/solr
at 
__randomizedtesting.SeedInfo.seed([5369EC070DA230CE:EF079A15A9F1B3B4]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:606)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:158)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 838 - Still unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/838/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader

Error Message:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[http://127.0.0.1:56167/forceleader_test_collection_shard1_replica2]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[http://127.0.0.1:56167/forceleader_test_collection_shard1_replica2]
at 
__randomizedtesting.SeedInfo.seed([11351025A0F0242E:F7A224E59972DD4F]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:769)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1161)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1050)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:992)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:753)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:741)
at 
org.apache.solr.cloud.ForceLeaderTest.sendDoc(ForceLeaderTest.java:424)
at 
org.apache.solr.cloud.ForceLeaderTest.assertSendDocFails(ForceLeaderTest.java:315)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:110)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[jira] [Commented] (SOLR-9495) AIOBE with confusing message for incomplete sort spec in Streaming Expression

[Gus Heck (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15480425#comment-15480425
 ] 

Gus Heck commented on SOLR-9495:


Patch provides an error message like: 

{code}{"result-set":{"docs":[
{"EXCEPTION":"Invalid sort spec:id","EOF":true}]}}{code}

> AIOBE with confusing message for incomplete sort spec in Streaming Expression
> -
>
> Key: SOLR-9495
> URL: https://issues.apache.org/jira/browse/SOLR-9495
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 6.2
> Environment: 6.2.0_RC1
>Reporter: Gus Heck
>Priority: Minor
> Attachments: SOLR-9495.patch
>
>
> I was thinking of using streaming expressions for something, and started to 
> play around with it, but I made a bonehaded mistake, and got an error that's 
> pretty confusing: 
> {code}{"result-set":{"docs":[
> {"EXCEPTION":"1","EOF":true}]}}{code}
> This turns out to be due to: 
> {code}
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.reflect.InvocationTargetException
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at 
> org.apache.solr.client.solrj.io.stream.expr.StreamFactory.createInstance(StreamFactory.java:316)
>   ... 33 more
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
>   at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.parseComp(CloudSolrStream.java:334)
>   at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.init(CloudSolrStream.java:274)
>   at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.(CloudSolrStream.java:181)
>   ... 38 more
> {code}
> The mistake I made was omitting a direction from the sort spec. Attaching 
> trivial patch to provide a better error message...



--
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-9495) AIOBE with confusing message for incomplete sort spec in Streaming Expression

[Gus Heck (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gus Heck updated SOLR-9495:
---
Attachment: SOLR-9495.patch

patch vs 6_x 

> AIOBE with confusing message for incomplete sort spec in Streaming Expression
> -
>
> Key: SOLR-9495
> URL: https://issues.apache.org/jira/browse/SOLR-9495
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 6.2
> Environment: 6.2.0_RC1
>Reporter: Gus Heck
>Priority: Minor
> Attachments: SOLR-9495.patch
>
>
> I was thinking of using streaming expressions for something, and started to 
> play around with it, but I made a bonehaded mistake, and got an error that's 
> pretty confusing: 
> {code}{"result-set":{"docs":[
> {"EXCEPTION":"1","EOF":true}]}}{code}
> This turns out to be due to: 
> {code}
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.reflect.InvocationTargetException
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at 
> org.apache.solr.client.solrj.io.stream.expr.StreamFactory.createInstance(StreamFactory.java:316)
>   ... 33 more
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
>   at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.parseComp(CloudSolrStream.java:334)
>   at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.init(CloudSolrStream.java:274)
>   at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.(CloudSolrStream.java:181)
>   ... 38 more
> {code}
> The mistake I made was omitting a direction from the sort spec. Attaching 
> trivial patch to provide a better error message...



--
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] (LUCENE-7440) Document skipping on large indexes is broken

[Yonik Seeley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yonik Seeley resolved LUCENE-7440.
--
   Resolution: Fixed
Fix Version/s: 6.3
   master (7.0)

> Document skipping on large indexes is broken
> 
>
> Key: LUCENE-7440
> URL: https://issues.apache.org/jira/browse/LUCENE-7440
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 2.2
>Reporter: Yonik Seeley
>Priority: Critical
> Fix For: master (7.0), 6.3
>
> Attachments: LUCENE-7440.patch, LUCENE-7440.patch
>
>
> Large skips on large indexes fail.
> Anything that uses skips (such as a boolean query, filtered queries, faceted 
> queries, join queries, etc) can trigger this bug on a sufficiently large 
> index.
> The bug is a numeric overflow in MultiLevelSkipList that has been present 
> since inception (Lucene 2.2).  It may not manifest until one has a single 
> segment with more than ~1.8B documents, and a large skip is performed on that 
> segment.
> Typical stack trace on Lucene7-dev:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 110
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:297)
>   at org.apache.lucene.store.DataInput.readVInt(DataInput.java:125)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50SkipReader.readSkipData(Lucene50SkipReader.java:180)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:163)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:133)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.advance(Lucene50PostingsReader.java:421)
>   at YCS_skip7$1.testSkip(YCS_skip7.java:307)
> {code}
> Typical stack trace on Lucene4.10.3:
> {code}
> 6-08-31 18:57:17,460 ERROR org.apache.solr.servlet.SolrDispatchFilter: 
> null:java.lang.ArrayIndexOutOfBoundsException: 75
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:301)
>  at org.apache.lucene.store.DataInput.readVInt(DataInput.java:122)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41SkipReader.readSkipData(Lucene41SkipReader.java:194)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:168)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:138)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.advance(Lucene41PostingsReader.java:506)
>  at org.apache.lucene.search.TermScorer.advance(TermScorer.java:85)
> [...]
>  at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
> [...]
>  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2004)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7440) Document skipping on large indexes is broken

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15480369#comment-15480369
 ] 

ASF subversion and git services commented on LUCENE-7440:
-

Commit cf72eebf75bb3c5c3bdd8ef2ee288e67f89b5538 in lucene-solr's branch 
refs/heads/branch_6x from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cf72eeb ]

LUCENE-7440: fix MultiLevelSkipListReader overflow


> Document skipping on large indexes is broken
> 
>
> Key: LUCENE-7440
> URL: https://issues.apache.org/jira/browse/LUCENE-7440
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 2.2
>Reporter: Yonik Seeley
>Priority: Critical
> Attachments: LUCENE-7440.patch, LUCENE-7440.patch
>
>
> Large skips on large indexes fail.
> Anything that uses skips (such as a boolean query, filtered queries, faceted 
> queries, join queries, etc) can trigger this bug on a sufficiently large 
> index.
> The bug is a numeric overflow in MultiLevelSkipList that has been present 
> since inception (Lucene 2.2).  It may not manifest until one has a single 
> segment with more than ~1.8B documents, and a large skip is performed on that 
> segment.
> Typical stack trace on Lucene7-dev:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 110
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:297)
>   at org.apache.lucene.store.DataInput.readVInt(DataInput.java:125)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50SkipReader.readSkipData(Lucene50SkipReader.java:180)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:163)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:133)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.advance(Lucene50PostingsReader.java:421)
>   at YCS_skip7$1.testSkip(YCS_skip7.java:307)
> {code}
> Typical stack trace on Lucene4.10.3:
> {code}
> 6-08-31 18:57:17,460 ERROR org.apache.solr.servlet.SolrDispatchFilter: 
> null:java.lang.ArrayIndexOutOfBoundsException: 75
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:301)
>  at org.apache.lucene.store.DataInput.readVInt(DataInput.java:122)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41SkipReader.readSkipData(Lucene41SkipReader.java:194)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:168)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:138)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.advance(Lucene41PostingsReader.java:506)
>  at org.apache.lucene.search.TermScorer.advance(TermScorer.java:85)
> [...]
>  at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
> [...]
>  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2004)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-9344) BasicAuthIntegrationTest test failures on update

[Alan Woodward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Woodward updated SOLR-9344:

Attachment: SOLR-9344-httpconfigurer.patch

Fixed the test failures - I added a 'resetConfigurers()' method to 
HttpClientUtil which removes all added configurers and goes back to using the 
default, and also ensured that a default configurer was always the first 
element in the chain.

> BasicAuthIntegrationTest test failures on update
> 
>
> Key: SOLR-9344
> URL: https://issues.apache.org/jira/browse/SOLR-9344
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security, Tests
>Affects Versions: trunk
>Reporter: Gregory Chanan
>Assignee: Alan Woodward
> Fix For: 6.3
>
> Attachments: SOLR-9344-httpconfigurer.patch, 
> SOLR-9344-httpconfigurer.patch, SOLR-9344.patch
>
>
> I've seen this a number of times while developing SOLR-9200 and SOLR-9324; 
> there's also a public failure here: 
> http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17372/
> {code}
> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: IOException 
> occured when talking to server at: 
> http://127.0.0.1:45882/solr/testSolrCloudCollection_shard1_replica2
>   at 
> __randomizedtesting.SeedInfo.seed([99BB0D0378978FA8:A463A32F4079D1D8]:0)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:760)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
>   at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
>   at 
> org.apache.solr.security.BasicAuthIntegrationTest.doExtraTests(BasicAuthIntegrationTest.java:193)
>   at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testCollectionCreateSearchDelete(TestMiniSolrCloudClusterBase.java:196)
>   at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testBasics(TestMiniSolrCloudClusterBase.java:79)
>   at 
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
> Method)
>   at 
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
>   at 
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>   at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
>   at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> 

[jira] [Updated] (LUCENE-7442) MinHashFilter.FixedSizeTreeSet.add() calls TreeSet.last() without first testing for emptiness, under which condition NoSuchElementException is thrown

[Cao Manh Dat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cao Manh Dat updated LUCENE-7442:
-
Attachment: LUCENE-7442.patch

It seem that TestRandomChains init MinHashFilter with wrong parameters
{code}
public MinHashFilter(TokenStream input, int hashCount, int bucketCount, int 
hashSetSize, boolean withRotation)
{code}
hashCount, bucketCount, hashSetSize must be positive ones.

Here are the patch to fix this issue.

> MinHashFilter.FixedSizeTreeSet.add() calls TreeSet.last() without first 
> testing for emptiness, under which condition NoSuchElementException is thrown
> -
>
> Key: LUCENE-7442
> URL: https://issues.apache.org/jira/browse/LUCENE-7442
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Reporter: Steve Rowe
> Attachments: LUCENE-7442.patch
>
>
> My Jenkins found this reproducing branch_6x seed:
> {noformat}
>[junit4] Suite: org.apache.lucene.analysis.core.TestRandomChains
>[junit4]   2> Exception from random analyzer: 
>[junit4]   2> charfilters=
>[junit4]   2> tokenizer=
>[junit4]   2>   org.apache.lucene.analysis.standard.StandardTokenizer()
>[junit4]   2> filters=
>[junit4]   2>   
> org.apache.lucene.analysis.minhash.MinHashFilter(ValidatingTokenFilter@6ae99167
>  
> term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,
>  5, 5, -3, true)
>[junit4]   2>   
> org.apache.lucene.analysis.bg.BulgarianStemFilter(ValidatingTokenFilter@40844352
>  
> term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,keyword=false)
>[junit4]   2> offsetsAreCorrect=true
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestRandomChains 
> -Dtests.method=testRandomChainsWithLargeStrings -Dtests.seed=4733E677EBDC28FC 
> -Dtests.slow=true -Dtests.locale=ar-OM 
> -Dtests.timezone=Atlantic/South_Georgia -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   3.18s J4 | 
> TestRandomChains.testRandomChainsWithLargeStrings <<<
>[junit4]> Throwable #1: java.util.NoSuchElementException
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([4733E677EBDC28FC:2D685966B292080F]:0)
>[junit4]>  at java.util.TreeMap.key(TreeMap.java:1323)
>[junit4]>  at java.util.TreeMap.lastKey(TreeMap.java:297)
>[junit4]>  at java.util.TreeSet.last(TreeSet.java:401)
>[junit4]>  at 
> org.apache.lucene.analysis.minhash.MinHashFilter$FixedSizeTreeSet.add(MinHashFilter.java:325)
>[junit4]>  at 
> org.apache.lucene.analysis.minhash.MinHashFilter.incrementToken(MinHashFilter.java:159)
>[junit4]>  at 
> org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:67)
>[junit4]>  at 
> org.apache.lucene.analysis.bg.BulgarianStemFilter.incrementToken(BulgarianStemFilter.java:48)
>[junit4]>  at 
> org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:67)
>[junit4]>  at 
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException(BaseTokenStreamTestCase.java:405)
>[junit4]>  at 
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:510)
>[junit4]>  at 
> org.apache.lucene.analysis.core.TestRandomChains.testRandomChainsWithLargeStrings(TestRandomChains.java:959)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene62): 
> {dummy=Lucene50(blocksize=128)}, docValues:{}, maxPointsInLeafNode=252, 
> maxMBSortInHeap=5.297834377897023, sim=ClassicSimilarity, locale=ar-OM, 
> timezone=Atlantic/South_Georgia
>[junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
> 1.8.0_77 (64-bit)/cpus=16,threads=1,free=395080152,total=465567744
>[junit4]   2> NOTE: All tests run in this JVM: 
> [TestDecimalDigitFilterFactory, TestMultiWordSynonyms, 
> TestReversePathHierarchyTokenizer, TestDoubleEscape, 
> TestHunspellStemFilterFactory, TestArabicNormalizationFilter, 
> TestUAX29URLEmailAnalyzer, TestSwedishLightStemFilterFactory, 
> TestBulgarianStemmer, TestASCIIFoldingFilter, 
> TestDelimitedPayloadTokenFilterFactory, TestIndonesianStemmer, TestCircumfix, 
> EdgeNGramTokenFilterTest, TestPatternTokenizer, 
> TestScandinavianFoldingFilter, TestIgnore, TestRandomChains]
>[junit4] Completed [130/272 (1!)] on J4 in 9.85s, 2 tests, 1 error <<< 
> FAILURES!
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, 

[jira] [Commented] (LUCENE-7440) Document skipping on large indexes is broken

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15480355#comment-15480355
 ] 

ASF subversion and git services commented on LUCENE-7440:
-

Commit c929d0595c0ad2ef311054746dc24aa8704f55e6 in lucene-solr's branch 
refs/heads/master from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c929d05 ]

LUCENE-7440: fix MultiLevelSkipListReader overflow


> Document skipping on large indexes is broken
> 
>
> Key: LUCENE-7440
> URL: https://issues.apache.org/jira/browse/LUCENE-7440
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 2.2
>Reporter: Yonik Seeley
>Priority: Critical
> Attachments: LUCENE-7440.patch, LUCENE-7440.patch
>
>
> Large skips on large indexes fail.
> Anything that uses skips (such as a boolean query, filtered queries, faceted 
> queries, join queries, etc) can trigger this bug on a sufficiently large 
> index.
> The bug is a numeric overflow in MultiLevelSkipList that has been present 
> since inception (Lucene 2.2).  It may not manifest until one has a single 
> segment with more than ~1.8B documents, and a large skip is performed on that 
> segment.
> Typical stack trace on Lucene7-dev:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 110
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:297)
>   at org.apache.lucene.store.DataInput.readVInt(DataInput.java:125)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50SkipReader.readSkipData(Lucene50SkipReader.java:180)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:163)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:133)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.advance(Lucene50PostingsReader.java:421)
>   at YCS_skip7$1.testSkip(YCS_skip7.java:307)
> {code}
> Typical stack trace on Lucene4.10.3:
> {code}
> 6-08-31 18:57:17,460 ERROR org.apache.solr.servlet.SolrDispatchFilter: 
> null:java.lang.ArrayIndexOutOfBoundsException: 75
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:301)
>  at org.apache.lucene.store.DataInput.readVInt(DataInput.java:122)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41SkipReader.readSkipData(Lucene41SkipReader.java:194)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:168)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:138)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.advance(Lucene41PostingsReader.java:506)
>  at org.apache.lucene.search.TermScorer.advance(TermScorer.java:85)
> [...]
>  at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
> [...]
>  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2004)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-5.5-Linux (32bit/jdk1.7.0_80) - Build # 418 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/418/
Java: 32bit/jdk1.7.0_80 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestAuthenticationFramework.testStopAllStartAll

Error Message:
Address already in use

Stack Trace:
java.net.BindException: Address already in use
at 
__randomizedtesting.SeedInfo.seed([9ECCDFEB7F3F8387:E8F2C0983E082EA8]:0)
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:463)
at sun.nio.ch.Net.bind(Net.java:455)
at 
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at 
org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:321)
at 
org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80)
at 
org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:236)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.server.Server.doStart(Server.java:366)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at 
org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:409)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.startJettySolrRunner(MiniSolrCloudCluster.java:356)
at 
org.apache.solr.cloud.TestMiniSolrCloudCluster.testStopAllStartAll(TestMiniSolrCloudCluster.java:463)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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 

[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 403 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/403/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth

Error Message:
IOException occured when talking to server at: https://127.0.0.1:55498/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: https://127.0.0.1:55498/solr
at 
__randomizedtesting.SeedInfo.seed([9F524F49A2B89E96:233C395B06EB1DEC]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:606)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:158)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Created] (SOLR-9495) AIOBE with confusing message for incomplete sort spec in Streaming Expression

[Gus Heck (JIRA)]

Gus Heck created SOLR-9495:
--

 Summary: AIOBE with confusing message for incomplete sort spec in 
Streaming Expression
 Key: SOLR-9495
 URL: https://issues.apache.org/jira/browse/SOLR-9495
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: search
Affects Versions: 6.2
 Environment: 6.2.0_RC1
Reporter: Gus Heck
Priority: Minor


I was thinking of using streaming expressions for something, and started to 
play around with it, but I made a bonehaded mistake, and got an error that's 
pretty confusing: 

{code}{"result-set":{"docs":[
{"EXCEPTION":"1","EOF":true}]}}{code}

This turns out to be due to: 
{code}
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at 
org.apache.solr.client.solrj.io.stream.expr.StreamFactory.createInstance(StreamFactory.java:316)
... 33 more
Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
at 
org.apache.solr.client.solrj.io.stream.CloudSolrStream.parseComp(CloudSolrStream.java:334)
at 
org.apache.solr.client.solrj.io.stream.CloudSolrStream.init(CloudSolrStream.java:274)
at 
org.apache.solr.client.solrj.io.stream.CloudSolrStream.(CloudSolrStream.java:181)
... 38 more
{code}

The mistake I made was omitting a direction from the sort spec. Attaching 
trivial patch to provide a better error message...



--
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-master - Build # 1113 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1113/

13 tests failed.
FAILED:  
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testReplicationAfterRestart

Error Message:
Timeout waiting for CDCR replication to complete @source_collection:shard2

Stack Trace:
java.lang.RuntimeException: Timeout waiting for CDCR replication to complete 
@source_collection:shard2
at 
__randomizedtesting.SeedInfo.seed([8F24B045D9638E9:54EFAC8593B68CDF]:0)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForReplicationToComplete(BaseCdcrDistributedZkTest.java:794)
at 
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testReplicationAfterRestart(CdcrReplicationDistributedZkTest.java:236)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-9344) BasicAuthIntegrationTest test failures on update

[Alan Woodward (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15480291#comment-15480291
 ] 

Alan Woodward commented on SOLR-9344:
-

Hm, actually scratch this patch, it's causing a whole bag of test failures, 
looking into why now...

> BasicAuthIntegrationTest test failures on update
> 
>
> Key: SOLR-9344
> URL: https://issues.apache.org/jira/browse/SOLR-9344
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security, Tests
>Affects Versions: trunk
>Reporter: Gregory Chanan
>Assignee: Alan Woodward
> Fix For: 6.3
>
> Attachments: SOLR-9344-httpconfigurer.patch, SOLR-9344.patch
>
>
> I've seen this a number of times while developing SOLR-9200 and SOLR-9324; 
> there's also a public failure here: 
> http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17372/
> {code}
> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: IOException 
> occured when talking to server at: 
> http://127.0.0.1:45882/solr/testSolrCloudCollection_shard1_replica2
>   at 
> __randomizedtesting.SeedInfo.seed([99BB0D0378978FA8:A463A32F4079D1D8]:0)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:760)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
>   at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
>   at 
> org.apache.solr.security.BasicAuthIntegrationTest.doExtraTests(BasicAuthIntegrationTest.java:193)
>   at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testCollectionCreateSearchDelete(TestMiniSolrCloudClusterBase.java:196)
>   at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testBasics(TestMiniSolrCloudClusterBase.java:79)
>   at 
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
> Method)
>   at 
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
>   at 
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>   at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
>   at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
>   at 
> 

[jira] [Updated] (SOLR-9344) BasicAuthIntegrationTest test failures on update

[Alan Woodward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Woodward updated SOLR-9344:

Attachment: SOLR-9344-httpconfigurer.patch

Looking at SOLR-9028 and SOLR-4509, it looks like it we can't backport the 
mechanism changes without breaking the auth plugin API.  Instead, here's a 
patch for 6x only that changes HttpClientUtil to hold a list of 
HttpClientConfigurer objects, which seems to make tests pass.  [~hossman] 
[~markrmil...@gmail.com] you did most of the work changing stuff for the master 
branch, does this change make sense?

> BasicAuthIntegrationTest test failures on update
> 
>
> Key: SOLR-9344
> URL: https://issues.apache.org/jira/browse/SOLR-9344
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security, Tests
>Affects Versions: trunk
>Reporter: Gregory Chanan
>Assignee: Alan Woodward
> Fix For: 6.3
>
> Attachments: SOLR-9344-httpconfigurer.patch, SOLR-9344.patch
>
>
> I've seen this a number of times while developing SOLR-9200 and SOLR-9324; 
> there's also a public failure here: 
> http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17372/
> {code}
> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: IOException 
> occured when talking to server at: 
> http://127.0.0.1:45882/solr/testSolrCloudCollection_shard1_replica2
>   at 
> __randomizedtesting.SeedInfo.seed([99BB0D0378978FA8:A463A32F4079D1D8]:0)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:760)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
>   at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
>   at 
> org.apache.solr.security.BasicAuthIntegrationTest.doExtraTests(BasicAuthIntegrationTest.java:193)
>   at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testCollectionCreateSearchDelete(TestMiniSolrCloudClusterBase.java:196)
>   at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testBasics(TestMiniSolrCloudClusterBase.java:79)
>   at 
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
> Method)
>   at 
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
>   at 
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>   at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
>   at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
>   at 
> 

[jira] [Commented] (SOLR-9467) Document Transformer to Remove Fields

[Gus Heck (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15480136#comment-15480136
 ] 

Gus Heck commented on SOLR-9467:


Been on vacation (still am)... will think about the cases [~hossman] mentioned.

[~arafalov], The intent here is to solve only the transport cost issue 
initially, deeper better savings (or more expressive versions, using regexes, 
globs etc) can be had via future enhancements or SOLR-3191.

> Document Transformer to Remove Fields
> -
>
> Key: SOLR-9467
> URL: https://issues.apache.org/jira/browse/SOLR-9467
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SearchComponents - other
>Affects Versions: 6.2
>Reporter: Gus Heck
> Attachments: SOLR-9467.patch
>
>
> Given that SOLR-3191 has become bogged down and inactive, evidently stuck in 
> low level details, and since I have wished several times for some way to just 
> get that one big field out of my results to improve transfer times without 
> making a big brittle list of all my other fields. I'd like to propose a 
> DocumentTransformer that accomplishes this.
> It would look something like this:
> {code}=*,[fl.rm v="title"]{code} 
> Since removing one field with a known name is probably the most common case 
> I'd like to start by keeping this simple, and if further features like globs 
> or lists of fields are desired, subsequent Jira tickets can be opened to add 
> them. Not attached to specifics here, only looking to keep things simple and 
> solve the key use case. If you don't like fl.rm as a name for a transformer, 
> suggest a better one (for example). 



--
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-6.x-Linux (64bit/jdk1.8.0_102) - Build # 1698 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1698/
Java: 64bit/jdk1.8.0_102 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth

Error Message:
IOException occured when talking to server at: https://127.0.0.1:37565/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: https://127.0.0.1:37565/solr
at 
__randomizedtesting.SeedInfo.seed([9EFE537BC715F3D1:22902569634670AB]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:606)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:158)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Updated] (LUCENE-7443) Enforcing BooleanClause.Occur.FILTER before CustomScoreQuery

[Shayan Tabrizi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shayan Tabrizi updated LUCENE-7443:
---
Description: 
I have a BooleanQuery including a BooleanClause.Occur.MUST clause and a 
BooleanClause.Occur.FILTER clause. I then use the BooleanQuery in a 
CustomScoreQuery. It seems that the filtering constraint is not enforced before 
calculating the score in CustomScoreQuery and is enforced after the 
calculation. This can cause performance issues, since CustomScoreQuery may 
perform costly operations to rescore the BooleanQuery results. If the filter is 
enforced before rescoring, much less documents may require rescoring in 
CustomScoreQuery, and it does not make sense to spend a lot of processing for 
documents we know will be filtered out.
More details:
The BooleanQuery is used as subQuery in the following constructor, and a costly 
scoringQuery is used which is more rational to calculate it only when the 
results of subQuery is not trivially filtered out because of the FILTER in 
subQuery.
  public CustomScoreQuery(Query subQuery, FunctionQuery scoringQuery) {


  was:
I have a BooleanQuery including a BooleanClause.Occur.MUST clause and a 
BooleanClause.Occur.FILTER clause. I then use the BooleanQuery in a 
CustomScoreQuery. It seems that the filtering constraint is not enforced before 
calculating the score in CustomScoreQuery and is enforced after the 
calculation. This can cause performance issues, since CustomScoreQuery may 
perform costly operations to rescore the BooleanQuery results. If the filter is 
enforced before rescoring, much less documents may require rescoring in 
CustomScoreQuery, and it does not make sense to spend a lot of processing for 
documents we know will be filtered out.
More details:
The BooleanQuery is used as subQuery in the following constructor, and a costly 
scoringQuery is used which is more rational to calculate it only when the 
results of subQuery is not trivially filtered out because of the FILTER in the 
boolean query.
  public CustomScoreQuery(Query subQuery, FunctionQuery scoringQuery) {



> Enforcing BooleanClause.Occur.FILTER before CustomScoreQuery
> 
>
> Key: LUCENE-7443
> URL: https://issues.apache.org/jira/browse/LUCENE-7443
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 6.2
>Reporter: Shayan Tabrizi
>Priority: Minor
>
> I have a BooleanQuery including a BooleanClause.Occur.MUST clause and a 
> BooleanClause.Occur.FILTER clause. I then use the BooleanQuery in a 
> CustomScoreQuery. It seems that the filtering constraint is not enforced 
> before calculating the score in CustomScoreQuery and is enforced after the 
> calculation. This can cause performance issues, since CustomScoreQuery may 
> perform costly operations to rescore the BooleanQuery results. If the filter 
> is enforced before rescoring, much less documents may require rescoring in 
> CustomScoreQuery, and it does not make sense to spend a lot of processing for 
> documents we know will be filtered out.
> More details:
> The BooleanQuery is used as subQuery in the following constructor, and a 
> costly scoringQuery is used which is more rational to calculate it only when 
> the results of subQuery is not trivially filtered out because of the FILTER 
> in subQuery.
>   public CustomScoreQuery(Query subQuery, FunctionQuery scoringQuery) {



--
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-7443) Enforcing BooleanClause.Occur.FILTER before CustomScoreQuery

[Shayan Tabrizi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shayan Tabrizi updated LUCENE-7443:
---
Description: 
I have a BooleanQuery including a BooleanClause.Occur.MUST clause and a 
BooleanClause.Occur.FILTER clause. I then use the BooleanQuery in a 
CustomScoreQuery. It seems that the filtering constraint is not enforced before 
calculating the score in CustomScoreQuery and is enforced after the 
calculation. This can cause performance issues, since CustomScoreQuery may 
perform costly operations to rescore the BooleanQuery results. If the filter is 
enforced before rescoring, much less documents may require rescoring in 
CustomScoreQuery, and it does not make sense to spend a lot of processing for 
documents we know will be filtered out.
More details:
The BooleanQuery is used as subQuery in the following constructor, and a costly 
scoringQuery is used which is more rational to calculate it only when the 
results of subQuery is not trivially filtered out because of the FILTER in the 
boolean query.
  public CustomScoreQuery(Query subQuery, FunctionQuery scoringQuery) {


  was:I have a BooleanQuery including a BooleanClause.Occur.MUST clause and a 
BooleanClause.Occur.FILTER clause. I then use the BooleanQuery in a 
CustomScoreQuery. It seems that the filtering constraint is not enforced before 
calculating the score in CustomScoreQuery and is enforced after the 
calculation. This can cause performance issues, since CustomScoreQuery may 
perform costly operations to rescore the BooleanQuery results. If the filter is 
enforced before rescoring, much less documents may require rescoring in 
CustomScoreQuery, and it does not make sense to spend a lot of processing for 
documents we know will be filtered out.


> Enforcing BooleanClause.Occur.FILTER before CustomScoreQuery
> 
>
> Key: LUCENE-7443
> URL: https://issues.apache.org/jira/browse/LUCENE-7443
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 6.2
>Reporter: Shayan Tabrizi
>Priority: Minor
>
> I have a BooleanQuery including a BooleanClause.Occur.MUST clause and a 
> BooleanClause.Occur.FILTER clause. I then use the BooleanQuery in a 
> CustomScoreQuery. It seems that the filtering constraint is not enforced 
> before calculating the score in CustomScoreQuery and is enforced after the 
> calculation. This can cause performance issues, since CustomScoreQuery may 
> perform costly operations to rescore the BooleanQuery results. If the filter 
> is enforced before rescoring, much less documents may require rescoring in 
> CustomScoreQuery, and it does not make sense to spend a lot of processing for 
> documents we know will be filtered out.
> More details:
> The BooleanQuery is used as subQuery in the following constructor, and a 
> costly scoringQuery is used which is more rational to calculate it only when 
> the results of subQuery is not trivially filtered out because of the FILTER 
> in the boolean query.
>   public CustomScoreQuery(Query subQuery, FunctionQuery scoringQuery) {



--
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: Is "solr.AnalyzerName" expansion supposed to work for Analyzers?

[Uwe Schindler]

Hi,

In addition this change (to "name" or "type" in the components) would allow to 
remove Steve Rowe's hack in AbstractAnalysisFactory to keep the class name in 
the parameter map for serializing, which is Solr specific and should not be 
there! With the "official" names, this is no longer needed and Solr could 
simple serialize the name. This hack hurted me several times already!

Uwe

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Uwe Schindler [mailto:u...@thetaphi.de]
> Sent: Saturday, September 10, 2016 6:54 PM
> To: dev@lucene.apache.org
> Subject: RE: Is "solr.AnalyzerName" expansion supposed to work for
> Analyzers?
> 
> Let's open an issue to do what I proposed! After that you could add the
> schema editor GUI.
> 
> I think Robert already proposed back at that time to add an additional
> abstract method to each factory that returns the acceptable parameter
> names. So one could select the component with help of SPI set. Once the
> component was chosen the acceptable configuration parameters can be
> retrieved from the instance.
> 
> Uwe
> 
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
> > -Original Message-
> > From: Upayavira [mailto:u...@odoko.co.uk]
> > Sent: Saturday, September 10, 2016 5:21 PM
> > To: dev@lucene.apache.org
> > Subject: Re: Is "solr.AnalyzerName" expansion supposed to work for
> > Analyzers?
> >
> > On Sat, 10 Sep 2016, at 04:03 PM, Uwe Schindler wrote:
> > > To add,
> > >
> > > the manages schema really makes it easy to "rewrite". My plan would be:
> > >
> > > - Add a new "type" or "name" attribute to schema.xml, which is contrary
> > > to "class" attribute usage
> > > - When a manages schema is loaded, the resolving of classes using the
> > > hack is done as it is now. Warnings are printed as said before.
> > > - The managed schema is then changes to switch to the new attribute
> > > (there is a getter to get the symbolic name from the factory, so
> > > rewriting is easy)
> > >
> > > In addition, this simplifies usage: Some GUI could show a dropdown list
> > > for clicking together the analyzer. We just need to add a schema-REST
> > > endpoint to get all names.
> > >
> > > Maybe open an issue targeted for 6.x / 7.0. I'd be happy to help to fix
> > > this, although I could only do the SolrResourceLoader and SolrAnalyzer
> > > stuff.
> >
> >  Not knowing how to get a list of acceptable components was the thing
> >  that stopped me adding that part of the schema API to the admin UI. And
> >  API to tell you which components exist would be extremely helpful.
> >
> > Upayavira
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-7443) Enforcing BooleanClause.Occur.FILTER before CustomScoreQuery

[Shayan Tabrizi (JIRA)]

Shayan Tabrizi created LUCENE-7443:
--

 Summary: Enforcing BooleanClause.Occur.FILTER before 
CustomScoreQuery
 Key: LUCENE-7443
 URL: https://issues.apache.org/jira/browse/LUCENE-7443
 Project: Lucene - Core
  Issue Type: Improvement
Affects Versions: 6.2
Reporter: Shayan Tabrizi
Priority: Minor


I have a BooleanQuery including a BooleanClause.Occur.MUST clause and a 
BooleanClause.Occur.FILTER clause. I then use the BooleanQuery in a 
CustomScoreQuery. It seems that the filtering constraint is not enforced before 
calculating the score in CustomScoreQuery and is enforced after the 
calculation. This can cause performance issues, since CustomScoreQuery may 
perform costly operations to rescore the BooleanQuery results. If the filter is 
enforced before rescoring, much less documents may require rescoring in 
CustomScoreQuery, and it does not make sense to spend a lot of processing for 
documents we know will be filtered out.



--
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-7440) Document skipping on large indexes is broken

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15480081#comment-15480081
 ] 

Uwe Schindler commented on LUCENE-7440:
---

+1

> Document skipping on large indexes is broken
> 
>
> Key: LUCENE-7440
> URL: https://issues.apache.org/jira/browse/LUCENE-7440
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 2.2
>Reporter: Yonik Seeley
>Priority: Critical
> Attachments: LUCENE-7440.patch, LUCENE-7440.patch
>
>
> Large skips on large indexes fail.
> Anything that uses skips (such as a boolean query, filtered queries, faceted 
> queries, join queries, etc) can trigger this bug on a sufficiently large 
> index.
> The bug is a numeric overflow in MultiLevelSkipList that has been present 
> since inception (Lucene 2.2).  It may not manifest until one has a single 
> segment with more than ~1.8B documents, and a large skip is performed on that 
> segment.
> Typical stack trace on Lucene7-dev:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 110
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:297)
>   at org.apache.lucene.store.DataInput.readVInt(DataInput.java:125)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50SkipReader.readSkipData(Lucene50SkipReader.java:180)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:163)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:133)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.advance(Lucene50PostingsReader.java:421)
>   at YCS_skip7$1.testSkip(YCS_skip7.java:307)
> {code}
> Typical stack trace on Lucene4.10.3:
> {code}
> 6-08-31 18:57:17,460 ERROR org.apache.solr.servlet.SolrDispatchFilter: 
> null:java.lang.ArrayIndexOutOfBoundsException: 75
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:301)
>  at org.apache.lucene.store.DataInput.readVInt(DataInput.java:122)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41SkipReader.readSkipData(Lucene41SkipReader.java:194)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:168)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:138)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.advance(Lucene41PostingsReader.java:506)
>  at org.apache.lucene.search.TermScorer.advance(TermScorer.java:85)
> [...]
>  at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
> [...]
>  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2004)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: Is "solr.AnalyzerName" expansion supposed to work for Analyzers?

[Uwe Schindler]

Let's open an issue to do what I proposed! After that you could add the schema 
editor GUI.

I think Robert already proposed back at that time to add an additional abstract 
method to each factory that returns the acceptable parameter names. So one 
could select the component with help of SPI set. Once the component was chosen 
the acceptable configuration parameters can be retrieved from the instance.

Uwe

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Upayavira [mailto:u...@odoko.co.uk]
> Sent: Saturday, September 10, 2016 5:21 PM
> To: dev@lucene.apache.org
> Subject: Re: Is "solr.AnalyzerName" expansion supposed to work for
> Analyzers?
> 
> On Sat, 10 Sep 2016, at 04:03 PM, Uwe Schindler wrote:
> > To add,
> >
> > the manages schema really makes it easy to "rewrite". My plan would be:
> >
> > - Add a new "type" or "name" attribute to schema.xml, which is contrary
> > to "class" attribute usage
> > - When a manages schema is loaded, the resolving of classes using the
> > hack is done as it is now. Warnings are printed as said before.
> > - The managed schema is then changes to switch to the new attribute
> > (there is a getter to get the symbolic name from the factory, so
> > rewriting is easy)
> >
> > In addition, this simplifies usage: Some GUI could show a dropdown list
> > for clicking together the analyzer. We just need to add a schema-REST
> > endpoint to get all names.
> >
> > Maybe open an issue targeted for 6.x / 7.0. I'd be happy to help to fix
> > this, although I could only do the SolrResourceLoader and SolrAnalyzer
> > stuff.
> 
>  Not knowing how to get a list of acceptable components was the thing
>  that stopped me adding that part of the schema API to the admin UI. And
>  API to tell you which components exist would be extremely helpful.
> 
> Upayavira
> 
> -
> 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] [Updated] (LUCENE-7440) Document skipping on large indexes is broken

[Yonik Seeley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yonik Seeley updated LUCENE-7440:
-
Attachment: LUCENE-7440.patch

Ok, I did a quick review to ensure that the other operand in the comparison, 
docCount, would never legitimately be negative and then switched to 
compareUnsigned.

> Document skipping on large indexes is broken
> 
>
> Key: LUCENE-7440
> URL: https://issues.apache.org/jira/browse/LUCENE-7440
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 2.2
>Reporter: Yonik Seeley
>Priority: Critical
> Attachments: LUCENE-7440.patch, LUCENE-7440.patch
>
>
> Large skips on large indexes fail.
> Anything that uses skips (such as a boolean query, filtered queries, faceted 
> queries, join queries, etc) can trigger this bug on a sufficiently large 
> index.
> The bug is a numeric overflow in MultiLevelSkipList that has been present 
> since inception (Lucene 2.2).  It may not manifest until one has a single 
> segment with more than ~1.8B documents, and a large skip is performed on that 
> segment.
> Typical stack trace on Lucene7-dev:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 110
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:297)
>   at org.apache.lucene.store.DataInput.readVInt(DataInput.java:125)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50SkipReader.readSkipData(Lucene50SkipReader.java:180)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:163)
>   at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:133)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.advance(Lucene50PostingsReader.java:421)
>   at YCS_skip7$1.testSkip(YCS_skip7.java:307)
> {code}
> Typical stack trace on Lucene4.10.3:
> {code}
> 6-08-31 18:57:17,460 ERROR org.apache.solr.servlet.SolrDispatchFilter: 
> null:java.lang.ArrayIndexOutOfBoundsException: 75
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader$SkipBuffer.readByte(MultiLevelSkipListReader.java:301)
>  at org.apache.lucene.store.DataInput.readVInt(DataInput.java:122)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41SkipReader.readSkipData(Lucene41SkipReader.java:194)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:168)
>  at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:138)
>  at 
> org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.advance(Lucene41PostingsReader.java:506)
>  at org.apache.lucene.search.TermScorer.advance(TermScorer.java:85)
> [...]
>  at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
> [...]
>  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2004)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: 6.2.1?

[Shalin Shekhar Mangar]

I can help shepherd the 6.2.1 release. I'll back-port some other Solr bug
fixes as well.

On Sat, Sep 10, 2016 at 12:37 AM, Chris Hostetter 
wrote:

>
>
> FWIW: SOLR-9490 Is a pretty nasty bug for most BoolField users.
>
> We should probably consider a rapid 6.2.1 release.
>
>
> https://issues.apache.org/jira/browse/SOLR-9490
>
>
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
Regards,
Shalin Shekhar Mangar.

[JENKINS] Lucene-Solr-5.5-Linux (64bit/jdk1.7.0_80) - Build # 417 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/417/
Java: 64bit/jdk1.7.0_80 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.schema.TestManagedSchemaAPI.test

Error Message:
Error from server at http://127.0.0.1:38834/solr/testschemaapi_shard1_replica2: 
ERROR: [doc=2] unknown field 'myNewField1'

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:38834/solr/testschemaapi_shard1_replica2: ERROR: 
[doc=2] unknown field 'myNewField1'
at 
__randomizedtesting.SeedInfo.seed([E26F4EFD00885B42:6A3B7127AE7436BA]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:653)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1002)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:891)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:827)
at 
org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:101)
at 
org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:69)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

Re: Is "solr.AnalyzerName" expansion supposed to work for Analyzers?

[Upayavira]

On Sat, 10 Sep 2016, at 04:03 PM, Uwe Schindler wrote:
> To add,
> 
> the manages schema really makes it easy to "rewrite". My plan would be:
> 
> - Add a new "type" or "name" attribute to schema.xml, which is contrary
> to "class" attribute usage
> - When a manages schema is loaded, the resolving of classes using the
> hack is done as it is now. Warnings are printed as said before.
> - The managed schema is then changes to switch to the new attribute
> (there is a getter to get the symbolic name from the factory, so
> rewriting is easy)
> 
> In addition, this simplifies usage: Some GUI could show a dropdown list
> for clicking together the analyzer. We just need to add a schema-REST
> endpoint to get all names.
> 
> Maybe open an issue targeted for 6.x / 7.0. I'd be happy to help to fix
> this, although I could only do the SolrResourceLoader and SolrAnalyzer
> stuff.

 Not knowing how to get a list of acceptable components was the thing
 that stopped me adding that part of the schema API to the admin UI. And
 API to tell you which components exist would be extremely helpful.

Upayavira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Is "solr.AnalyzerName" expansion supposed to work for Analyzers?

[David Smiley]

Thanks for this detailed answer.

On Sat, Sep 10, 2016 at 3:24 AM Uwe Schindler  wrote:

> Hallo Alexandre,
>
> > I can't see a reason why it should be different, but:
> >
> > This works
> > 
> > 
> > 
> > 
> >
> >
> > This does not:
> > 
> > 
> > 
> >
> > This does work again:
> > 
> >  class="org.apache.lucene.analysis.core.SimpleAnalyzer"/>
> > 
> >
> > Both LowerCaseTokenizerFactory and SimpleAnalyzer are in the same
> > package.
> >
> > Is this a bug or some sort of legacy decision?
>
> There is a long history behind that and there is also a *fundamental*
> difference between the factories used for building custom analyzers in XML
> code and just referring to an Analyzer!
>
> Let me start with some history: From the early beginning there was the
> concept of factories in Solr, so implementation classes are initialized
> from a map of properties given in the XML. Those factories were specified
> by Java binary class name ("org.apache.solr.foo.bar.MyFactory"). This is
> used at many places in Solr. The problem is that those class names could be
> quite long, so the SolrResourceLoader has a "hack" to allow short names
> (IMHO, which was a horrible decision). When it sees a class starting with
> name "solr.", it tris to lookup different possibilities. See code here:
> https://goo.gl/P24ZU3 (subpackages is generally a list like
> "o.a.solr.something",...).
>
> In the early days (before Lucene/Solr 4.0), those factories were *all*
> part of Solr, so the lookup with the "solr." short name prefix was easy and
> the subpackages list was short. So it "just worked" and many people had
> those class names in their config files.
>
> The Analyzers (2nd example) were always referred to by their full name,
> because they were part of Lucene and not Solr. Using a "solr." Short name
> was never ever possible because of that.
>
> Now a change in 4.0 comes into the game: To make the concept of building
> "custom" analyzers easier to use for non-Solr users, and to make the whole
> concept easier to maintain, the factories for tokenstream components were
> moved out of Solr into Lucene (
> https://issues.apache.org/jira/browse/LUCENE-2510). The analysis parts
> got new package names below the Lucene namespace. The effect of this would
> have been that all people have to change their config files, because the
> "solr." Shortcut won't work with Lucene classes.
>
> Now you might ask why the "solr." Prefix still works? The reason is a
> second fundamental change with Lucene 4. We no longer use class names in
> Lucene to refer to stuff like Codecs, PostingFormats - we use the java
> concept of SPI. All components get a name, the implementation class is not
> exposed to outside. Like with Codecs, where you use
> Codec.forName("Lucene70") to instantiate it, the same was done for
> TokenStream components. This allows now to create StandardTokenizerFactory
> using the following code: TokenizerFactory.forName("standard"). Or
> LowercaseFilter with TokenFilterFactory.forName("lowercase"). There is no
> such concept for Analyzers (no SPI) [this explains your original question].
>
> Now we have the two pieces to put together: Refactoring of class names and
> adding of SPI concept. The "correct" fix in Solr would have been to remove
> the "class=" attribute in the fieldType and replace by something called
> "name" or "type", so the XML would look like (https://goo.gl/Dr3gpO):
>
> 
>
>   
>
> 
>
> Similar to those examples of the corresponding class to build Analyzers
> from those SPI names in Lucene:
> https://lucene.apache.org/core/6_2_0/analyzers-common/org/apache/lucene/analysis/custom/CustomAnalyzer.html
>
> The above syntax is wonderful, but again this caused lots of complaints
> from Solr developers, that people are unable to understand this WTF :-) It
> may also have to do with those short names look more like  name here>  analysis component names (no idea, although its completely
> unrelated). The issue with more history is here:
> https://issues.apache.org/jira/browse/LUCENE-4044
>
> Because of that there was a second hack added so all schema.xml files
> worked like before (in LUCENE-4044). This hack is the only way to configure
> tokenstream components up to this day - which is a desaster, IMHO! The hack
> is a fancy regular expression that tries to convert the old
> "solr.FoobarTokenFilterFactory" to the nice reading "names" like above:
> https://goo.gl/mtWmjm
> The factory is then loaded using SPI: https://goo.gl/EwDtQr
> IMHO, the hack should be deprecated and removed and the new syntax, as
> described above, should be introduced.
>
> Analyzer class names would still (and will for sure stay like that - as
> used seldom in Solr) be *full* class names. There is no way to change that!
>
> Now you have a bit of history and you might see that there is absolutely
> no relationship between the class name / package name and the 

[jira] [Commented] (LUCENE-7318) Graduate StandardAnalyzer out of analyzers module into core

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15479939#comment-15479939
 ] 

Uwe Schindler commented on LUCENE-7318:
---

As we plan to release 6.2.1 quite soon, I will for now add back the 
"deprecated" subclasses in the analyzers/common module. The decision if the 
StopFilter should stay in StandardAnalyzer and the whole base classes in core 
is a different decision and should be discussed in a separate issue.

> Graduate StandardAnalyzer out of analyzers module into core
> ---
>
> Key: LUCENE-7318
> URL: https://issues.apache.org/jira/browse/LUCENE-7318
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0), 6.2
>
> Attachments: LUCENE-7318.patch
>
>
> Spinoff from LUCENE-7314:
> {{StandardAnalyzer}} has progressed substantially since we broke out the 
> analyzers module ... it now follows a real Unicode standard (UAX #29 Unicode 
> Text Segmentation).  It's also much faster than it used to be, since it 
> switched to JFlex a while back.  Many bug fixes, etc.
> I think it would make a good default for most Lucene users, and we should 
> graduate it from the analyzers module into core, and make it the default for 
> {{IndexWriter}}.
> It's really quite crazy that users must go digging in the analyzers module to 
> get started with Lucene ... we don't make them dig through the codecs module 
> to find a good 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

RE: Is "solr.AnalyzerName" expansion supposed to work for Analyzers?

[Uwe Schindler]

To add,

the manages schema really makes it easy to "rewrite". My plan would be:

- Add a new "type" or "name" attribute to schema.xml, which is contrary to 
"class" attribute usage
- When a manages schema is loaded, the resolving of classes using the hack is 
done as it is now. Warnings are printed as said before.
- The managed schema is then changes to switch to the new attribute (there is a 
getter to get the symbolic name from the factory, so rewriting is easy)

In addition, this simplifies usage: Some GUI could show a dropdown list for 
clicking together the analyzer. We just need to add a schema-REST endpoint to 
get all names.

Maybe open an issue targeted for 6.x / 7.0. I'd be happy to help to fix this, 
although I could only do the SolrResourceLoader and SolrAnalyzer stuff.

Uwe

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Uwe Schindler [mailto:u...@thetaphi.de]
> Sent: Saturday, September 10, 2016 4:03 PM
> To: dev@lucene.apache.org; Alexandre Rafalovitch 
> Subject: Re: Is "solr.AnalyzerName" expansion supposed to work for
> Analyzers?
> 
> Hi,
> 
> The registry is there. To get all symbolic names of analyzer components in
> classpath, use XxxFacrory.availableXxx() static methods.
> 
> I don't think it makes sense to replace all factories in solr with named SPIs.
> But I'd suggest to add the type or name attribute to analysis components and
> promote it. Class attribute can still be used like now but logs warning if it 
> was
> misused to load an SPI. If it refers to a real class all is fine.
> 
> Uwe
> 
> Am 10. September 2016 15:56:51 MESZ, schrieb Alexandre Rafalovitch
> :
> >Wow Uwe,
> >
> >Thanks for the treatise. That's an interesting discussion, but I
> >wonder if anything changed since?
> >
> >In terms of user-confusion/migration, we now have managed schema and
> >can probably rewrite from 'solr.x' to symbol names on first use. That,
> >of course, requires some sort of registry of those names, which I am
> >not sure if it exists (apart from my own solrt-start.com hacks). But
> >then the registry may well align with some other configuration
> >reporting by the components. And with plugins/library jars.
> >
> >I am also wondering if the objection is still valid that other
> >components in Solr (such as search components) are still not able to
> >move to SPI? I am especially curious if any of that was affected by
> >Nobble's work on having libraries loaded into Solr's special
> >collection. What is the mechanism used there to load things.
> >
> >But yes, I can see it is a big topic. I may just update the
> >documentation and examples to mention that Analyzers have to use
> >full-name when I get to it.
> >
> >Regards,
> >   Alex.
> >
> >Newsletter and resources for Solr beginners and intermediates:
> >http://www.solr-start.com/
> >
> >
> >On 10 September 2016 at 14:24, Uwe Schindler  wrote:
> >> Hallo Alexandre,
> >>
> >>> I can't see a reason why it should be different, but:
> >>>
> >>> This works
> >>> 
> >>> 
> >>> 
> >>> 
> >>>
> >>>
> >>> This does not:
> >>> 
> >>> 
> >>> 
> >>>
> >>> This does work again:
> >>> 
> >>>  >class="org.apache.lucene.analysis.core.SimpleAnalyzer"/>
> >>> 
> >>>
> >>> Both LowerCaseTokenizerFactory and SimpleAnalyzer are in the same
> >>> package.
> >>>
> >>> Is this a bug or some sort of legacy decision?
> >>
> >> There is a long history behind that and there is also a *fundamental*
> >difference between the factories used for building custom analyzers in
> >XML code and just referring to an Analyzer!
> >>
> >> Let me start with some history: From the early beginning there was
> >the concept of factories in Solr, so implementation classes are
> >initialized from a map of properties given in the XML. Those factories
> >were specified by Java binary class name
> >("org.apache.solr.foo.bar.MyFactory"). This is used at many places in
> >Solr. The problem is that those class names could be quite long, so the
> >SolrResourceLoader has a "hack" to allow short names (IMHO, which was a
> >horrible decision). When it sees a class starting with name "solr.", it
> >tris to lookup different possibilities. See code here:
> >https://goo.gl/P24ZU3 (subpackages is generally a list like
> >"o.a.solr.something",...).
> >>
> >> In the early days (before Lucene/Solr 4.0), those factories were
> >*all* part of Solr, so the lookup with the "solr." short name prefix
> >was easy and the subpackages list was short. So it "just worked" and
> >many people had those class names in their config files.
> >>
> >> The Analyzers (2nd example) were always referred to by their full
> >name, because they were part of Lucene and not Solr. Using a "solr."
> >Short name was never ever possible because of that.
> >>
> >> Now a change in 4.0 comes into the game: To make the 

[jira] [Updated] (LUCENE-7439) Should FuzzyQuery match short terms too?

[Michael McCandless (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless updated LUCENE-7439:
---
Attachment: LUCENE-7439.patch

Another iteration, just adding a randomized test, which seems to be passing.

> Should FuzzyQuery match short terms too?
> 
>
> Key: LUCENE-7439
> URL: https://issues.apache.org/jira/browse/LUCENE-7439
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0), 6.3
>
> Attachments: LUCENE-7439.patch, LUCENE-7439.patch
>
>
> Today, if you ask {{FuzzyQuery}} to match {{abcd}} with edit distance 2, it 
> will fail to match the term {{ab}} even though it's 2 edits away.
> Its javadocs explain this:
> {noformat}
>  * NOTE: terms of length 1 or 2 will sometimes not match because of how 
> the scaled
>  * distance between two terms is computed.  For a term to match, the edit 
> distance between
>  * the terms must be less than the minimum length term (either the input 
> term, or
>  * the candidate term).  For example, FuzzyQuery on term "abcd" with 
> maxEdits=2 will
>  * not match an indexed term "ab", and FuzzyQuery on term "a" with maxEdits=2 
> will not
>  * match an indexed term "abc".
> {noformat}
> On the one hand, I can see that this behavior is sort of justified in that 
> 50% of the characters are different and so this is a very "weak" match, but 
> on the other hand, it's quite unexpected since edit distance is such an exact 
> measure so the terms should have matched.
> It seems like the behavior is caused by internal implementation details about 
> how the relative (floating point) score is computed.  I think we should fix 
> it, so that edit distance 2 does in fact match all terms with edit distance 
> <= 2.



--
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: Is "solr.AnalyzerName" expansion supposed to work for Analyzers?

[Uwe Schindler]

Hi,

The registry is there. To get all symbolic names of analyzer components in 
classpath, use XxxFacrory.availableXxx() static methods.

I don't think it makes sense to replace all factories in solr with named SPIs. 
But I'd suggest to add the type or name attribute to analysis components and 
promote it. Class attribute can still be used like now but logs warning if it 
was misused to load an SPI. If it refers to a real class all is fine.

Uwe

Am 10. September 2016 15:56:51 MESZ, schrieb Alexandre Rafalovitch 
:
>Wow Uwe,
>
>Thanks for the treatise. That's an interesting discussion, but I
>wonder if anything changed since?
>
>In terms of user-confusion/migration, we now have managed schema and
>can probably rewrite from 'solr.x' to symbol names on first use. That,
>of course, requires some sort of registry of those names, which I am
>not sure if it exists (apart from my own solrt-start.com hacks). But
>then the registry may well align with some other configuration
>reporting by the components. And with plugins/library jars.
>
>I am also wondering if the objection is still valid that other
>components in Solr (such as search components) are still not able to
>move to SPI? I am especially curious if any of that was affected by
>Nobble's work on having libraries loaded into Solr's special
>collection. What is the mechanism used there to load things.
>
>But yes, I can see it is a big topic. I may just update the
>documentation and examples to mention that Analyzers have to use
>full-name when I get to it.
>
>Regards,
>   Alex.
>
>Newsletter and resources for Solr beginners and intermediates:
>http://www.solr-start.com/
>
>
>On 10 September 2016 at 14:24, Uwe Schindler  wrote:
>> Hallo Alexandre,
>>
>>> I can't see a reason why it should be different, but:
>>>
>>> This works
>>> 
>>> 
>>> 
>>> 
>>>
>>>
>>> This does not:
>>> 
>>> 
>>> 
>>>
>>> This does work again:
>>> 
>>> class="org.apache.lucene.analysis.core.SimpleAnalyzer"/>
>>> 
>>>
>>> Both LowerCaseTokenizerFactory and SimpleAnalyzer are in the same
>>> package.
>>>
>>> Is this a bug or some sort of legacy decision?
>>
>> There is a long history behind that and there is also a *fundamental*
>difference between the factories used for building custom analyzers in
>XML code and just referring to an Analyzer!
>>
>> Let me start with some history: From the early beginning there was
>the concept of factories in Solr, so implementation classes are
>initialized from a map of properties given in the XML. Those factories
>were specified by Java binary class name
>("org.apache.solr.foo.bar.MyFactory"). This is used at many places in
>Solr. The problem is that those class names could be quite long, so the
>SolrResourceLoader has a "hack" to allow short names (IMHO, which was a
>horrible decision). When it sees a class starting with name "solr.", it
>tris to lookup different possibilities. See code here:
>https://goo.gl/P24ZU3 (subpackages is generally a list like
>"o.a.solr.something",...).
>>
>> In the early days (before Lucene/Solr 4.0), those factories were
>*all* part of Solr, so the lookup with the "solr." short name prefix
>was easy and the subpackages list was short. So it "just worked" and
>many people had those class names in their config files.
>>
>> The Analyzers (2nd example) were always referred to by their full
>name, because they were part of Lucene and not Solr. Using a "solr."
>Short name was never ever possible because of that.
>>
>> Now a change in 4.0 comes into the game: To make the concept of
>building "custom" analyzers easier to use for non-Solr users, and to
>make the whole concept easier to maintain, the factories for
>tokenstream components were moved out of Solr into Lucene
>(https://issues.apache.org/jira/browse/LUCENE-2510). The analysis parts
>got new package names below the Lucene namespace. The effect of this
>would have been that all people have to change their config files,
>because the "solr." Shortcut won't work with Lucene classes.
>>
>> Now you might ask why the "solr." Prefix still works? The reason is a
>second fundamental change with Lucene 4. We no longer use class names
>in Lucene to refer to stuff like Codecs, PostingFormats - we use the
>java concept of SPI. All components get a name, the implementation
>class is not exposed to outside. Like with Codecs, where you use
>Codec.forName("Lucene70") to instantiate it, the same was done for
>TokenStream components. This allows now to create
>StandardTokenizerFactory using the following code:
>TokenizerFactory.forName("standard"). Or LowercaseFilter with
>TokenFilterFactory.forName("lowercase"). There is no such concept for
>Analyzers (no SPI) [this explains your original question].
>>
>> Now we have the two pieces to put together: Refactoring of class
>names and adding of SPI concept. The "correct" fix in Solr would have
>been to remove the "class=" attribute in 

Re: Is "solr.AnalyzerName" expansion supposed to work for Analyzers?

[Alexandre Rafalovitch]

Wow Uwe,

Thanks for the treatise. That's an interesting discussion, but I
wonder if anything changed since?

In terms of user-confusion/migration, we now have managed schema and
can probably rewrite from 'solr.x' to symbol names on first use. That,
of course, requires some sort of registry of those names, which I am
not sure if it exists (apart from my own solrt-start.com hacks). But
then the registry may well align with some other configuration
reporting by the components. And with plugins/library jars.

I am also wondering if the objection is still valid that other
components in Solr (such as search components) are still not able to
move to SPI? I am especially curious if any of that was affected by
Nobble's work on having libraries loaded into Solr's special
collection. What is the mechanism used there to load things.

But yes, I can see it is a big topic. I may just update the
documentation and examples to mention that Analyzers have to use
full-name when I get to it.

Regards,
   Alex.

Newsletter and resources for Solr beginners and intermediates:
http://www.solr-start.com/


On 10 September 2016 at 14:24, Uwe Schindler  wrote:
> Hallo Alexandre,
>
>> I can't see a reason why it should be different, but:
>>
>> This works
>> 
>> 
>> 
>> 
>>
>>
>> This does not:
>> 
>> 
>> 
>>
>> This does work again:
>> 
>> 
>> 
>>
>> Both LowerCaseTokenizerFactory and SimpleAnalyzer are in the same
>> package.
>>
>> Is this a bug or some sort of legacy decision?
>
> There is a long history behind that and there is also a *fundamental* 
> difference between the factories used for building custom analyzers in XML 
> code and just referring to an Analyzer!
>
> Let me start with some history: From the early beginning there was the 
> concept of factories in Solr, so implementation classes are initialized from 
> a map of properties given in the XML. Those factories were specified by Java 
> binary class name ("org.apache.solr.foo.bar.MyFactory"). This is used at many 
> places in Solr. The problem is that those class names could be quite long, so 
> the SolrResourceLoader has a "hack" to allow short names (IMHO, which was a 
> horrible decision). When it sees a class starting with name "solr.", it tris 
> to lookup different possibilities. See code here: https://goo.gl/P24ZU3 
> (subpackages is generally a list like "o.a.solr.something",...).
>
> In the early days (before Lucene/Solr 4.0), those factories were *all* part 
> of Solr, so the lookup with the "solr." short name prefix was easy and the 
> subpackages list was short. So it "just worked" and many people had those 
> class names in their config files.
>
> The Analyzers (2nd example) were always referred to by their full name, 
> because they were part of Lucene and not Solr. Using a "solr." Short name was 
> never ever possible because of that.
>
> Now a change in 4.0 comes into the game: To make the concept of building 
> "custom" analyzers easier to use for non-Solr users, and to make the whole 
> concept easier to maintain, the factories for tokenstream components were 
> moved out of Solr into Lucene 
> (https://issues.apache.org/jira/browse/LUCENE-2510). The analysis parts got 
> new package names below the Lucene namespace. The effect of this would have 
> been that all people have to change their config files, because the "solr." 
> Shortcut won't work with Lucene classes.
>
> Now you might ask why the "solr." Prefix still works? The reason is a second 
> fundamental change with Lucene 4. We no longer use class names in Lucene to 
> refer to stuff like Codecs, PostingFormats - we use the java concept of SPI. 
> All components get a name, the implementation class is not exposed to 
> outside. Like with Codecs, where you use Codec.forName("Lucene70") to 
> instantiate it, the same was done for TokenStream components. This allows now 
> to create StandardTokenizerFactory using the following code: 
> TokenizerFactory.forName("standard"). Or LowercaseFilter with 
> TokenFilterFactory.forName("lowercase"). There is no such concept for 
> Analyzers (no SPI) [this explains your original question].
>
> Now we have the two pieces to put together: Refactoring of class names and 
> adding of SPI concept. The "correct" fix in Solr would have been to remove 
> the "class=" attribute in the fieldType and replace by something called 
> "name" or "type", so the XML would look like (https://goo.gl/Dr3gpO):
>
> 
>
>   
>
> 
>
> Similar to those examples of the corresponding class to build Analyzers from 
> those SPI names in Lucene: 
> https://lucene.apache.org/core/6_2_0/analyzers-common/org/apache/lucene/analysis/custom/CustomAnalyzer.html
>
> The above syntax is wonderful, but again this caused lots of complaints from 
> Solr developers, that people are unable to understand this WTF :-) It may 
> also have to do with those short names look more like  here>  analysis 

Re: Request for sanity check: SOLR-9477 (UpdateRequestProcessors ignore child documents)

[Alexandre Rafalovitch]

Only AddSchemaFieldsUpdateProcessorFactory deals with the children.
None others do.

So, I am looking at this and as a first group I am looking at
DefaultValue URPs, of which we have 3:
* DefaultValueUpdateProcessorFactory
* TimestampUpdateProcessorFactory
* UUIDUpdateProcessorFactory

Of those, UUIDUpdateProcessorFactory - to me - should always apply on
all levels. Mikhail said we need a paradigm shift on the whole ID
thing, but while we wait for that, we need to assign those unique IDs
or see the import fail.

On the other hand, both Timestamp and DefaultValue URPs are more
complex as they both actually create a field. With timestamp, it seems
that applying it universally would mean it would be on all nested
documents, however many levels down. Seems redundant.

Default value URP is more complex again - the 'price' element given in
the example could be in a parent or in a child. Or in a grandchild.
And may not make sense on the other levels. What's the best way to
deal with that?

Obviously, this discussion applies to all of the URPs, I am just using
concrete example here to make the discussion more concrete.

Regards,
   Alex.



Newsletter and resources for Solr beginners and intermediates:
http://www.solr-start.com/


On 7 September 2016 at 22:01, David Smiley  wrote:
> I think we need to document which URPs apply to child docs (if any) and
> otherwise say that, unless otherwise noted, URPs only apply to the root doc.
>
> It would be nice if one could simply configure at the URP declaration if it
> applies to children only, root doc only, or both.  I figure *most* URPs
> don't need internal coding to pick.  If users could pick at the declaration
> to which it applies, we might then also want the ability for some URPs to
> declare that they only work with root docs and then Solr could give you a
> helpful error if you misuse it.
>
> ~ David
>
> On Wed, Sep 7, 2016 at 4:38 AM Alexandre Rafalovitch 
> wrote:
>>
>> On 7 September 2016 at 11:52, Mikhail Khludnev  wrote:
>> >> *) Do we need to document this as a limitation?
>> >
>> > Yes. Sure. But it's nowhere promised that update processors are applied
>> > on
>> > children.
>> I feel this violates the expectation of least surprise. For example, I
>> have discovered this issue by creating a sample dataset that ended-up
>> with a blank Date field in the child record. So, I figured this is
>> easy to fix Solr side by just adding RemoveBlankField URP. And it
>> did not work. Took me an hour to figure out that _none_ of the URPs
>> work at all. More importantly, it means we have no solutions for the
>> child documents for all those problems we solved over time with URPs.
>> Which we need to document and/or fix.
>>
>> >> *) Do we need to fix it individually or there is a smart way to do it
>> >> centrally?
>>
>> > Probably yes, but I prefer to aim someones real life challenge, than
>> > solve an abstract
>> > common sense problem. eg.
>> > how to apply a processor to children only but not to parent? Another
>> > case is ID generation
>> > - it's often required
>> > to generate it for parent but then implicitly propagate to children, but
>> > it requires paradigm
>> > shift:
>> > uniqueKey should be assigned on a block not a single document. This will
>> > fix when
>> > childless docs are mixed with blocks, etc.
>> > Perhaps, it make sense to create a processed which applies a certain
>> > chain of processors
>> > to children docs only?
>>
>> Ok, these are interesting questions that can apply to specific URPs.
>> This suggests to me that each one (or each group) should be deal with
>> separately.
>>
>> > Frankly speaking, block support are yet raw, and this limitation is not
>> > considered
>> > significant at comparison with other ones.
>>
>> Well, we support them in XML, JSON, DIH, queries, etc. It may be raw
>> but it is usable and people are using it. So - to me - it is a valid
>> issue and worth thinking about.
>>
>> Regards,
>> Alex.
>> 
>> Newsletter and resources for Solr beginners and intermediates:
>> http://www.solr-start.com/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_102) - Build # 1697 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1697/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth

Error Message:
IOException occured when talking to server at: https://127.0.0.1:39005/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: https://127.0.0.1:39005/solr
at 
__randomizedtesting.SeedInfo.seed([2018D0E25A5A215E:9C76A6F0FE09A224]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:606)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:158)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_102) - Build # 6109 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6109/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseG1GC

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI

Error Message:
ObjectTracker found 10 object(s) that were not released!!! 
[MockDirectoryWrapper, MockDirectoryWrapper, MDCAwareThreadPoolExecutor, 
TransactionLog, MockDirectoryWrapper, MockDirectoryWrapper, 
MockDirectoryWrapper, TransactionLog, MDCAwareThreadPoolExecutor, 
MockDirectoryWrapper]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 10 object(s) that were not 
released!!! [MockDirectoryWrapper, MockDirectoryWrapper, 
MDCAwareThreadPoolExecutor, TransactionLog, MockDirectoryWrapper, 
MockDirectoryWrapper, MockDirectoryWrapper, TransactionLog, 
MDCAwareThreadPoolExecutor, MockDirectoryWrapper]
at __randomizedtesting.SeedInfo.seed([85D8B94A0B941025]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:257)
at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_85D8B94A0B941025-001\tempDir-001\node2\testschemaapi_shard1_replica1\data\tlog\tlog.000:
 java.nio.file.FileSystemException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_85D8B94A0B941025-001\tempDir-001\node2\testschemaapi_shard1_replica1\data\tlog\tlog.000:
 The process cannot access the file because it is being used by another 
process. 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_85D8B94A0B941025-001\tempDir-001\node2\testschemaapi_shard1_replica1\data\tlog:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_85D8B94A0B941025-001\tempDir-001\node2\testschemaapi_shard1_replica1\data\tlog

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_85D8B94A0B941025-001\tempDir-001\node2\testschemaapi_shard1_replica1\data:
 java.nio.file.DirectoryNotEmptyException: 

[JENKINS] Lucene-Solr-5.5-Linux (64bit/jdk1.7.0_80) - Build # 416 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/416/
Java: 64bit/jdk1.7.0_80 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.handler.TestReplicationHandler.doTestStressReplication

Error Message:
timed out waiting for collection1 startAt time to exceed: Sat Sep 10 04:11:32 
MST 2016

Stack Trace:
java.lang.AssertionError: timed out waiting for collection1 startAt time to 
exceed: Sat Sep 10 04:11:32 MST 2016
at 
__randomizedtesting.SeedInfo.seed([AB655BFE5EF55F1F:70CE5B385BDD36AC]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.handler.TestReplicationHandler.watchCoreStartAt(TestReplicationHandler.java:1501)
at 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:853)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 9 lines...]
   [junit4] Suite: 

[jira] [Commented] (SOLR-9344) BasicAuthIntegrationTest test failures on update

[Noble Paul (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15479663#comment-15479663
 ] 

Noble Paul commented on SOLR-9344:
--

Good catch. What's stopping us from moving the coffee from master to 6.x

> BasicAuthIntegrationTest test failures on update
> 
>
> Key: SOLR-9344
> URL: https://issues.apache.org/jira/browse/SOLR-9344
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security, Tests
>Affects Versions: trunk
>Reporter: Gregory Chanan
>Assignee: Alan Woodward
> Fix For: 6.3
>
> Attachments: SOLR-9344.patch
>
>
> I've seen this a number of times while developing SOLR-9200 and SOLR-9324; 
> there's also a public failure here: 
> http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17372/
> {code}
> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: IOException 
> occured when talking to server at: 
> http://127.0.0.1:45882/solr/testSolrCloudCollection_shard1_replica2
>   at 
> __randomizedtesting.SeedInfo.seed([99BB0D0378978FA8:A463A32F4079D1D8]:0)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:760)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
>   at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
>   at 
> org.apache.solr.security.BasicAuthIntegrationTest.doExtraTests(BasicAuthIntegrationTest.java:193)
>   at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testCollectionCreateSearchDelete(TestMiniSolrCloudClusterBase.java:196)
>   at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testBasics(TestMiniSolrCloudClusterBase.java:79)
>   at 
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
> Method)
>   at 
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
>   at 
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>   at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
>   at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
>   at 
> 

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_102) - Build # 17794 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17794/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseSerialGC

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI

Error Message:
ObjectTracker found 10 object(s) that were not released!!! [TransactionLog, 
MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, 
MDCAwareThreadPoolExecutor, MDCAwareThreadPoolExecutor, MockDirectoryWrapper, 
MockDirectoryWrapper, TransactionLog, MockDirectoryWrapper]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 10 object(s) that were not 
released!!! [TransactionLog, MockDirectoryWrapper, MockDirectoryWrapper, 
MockDirectoryWrapper, MDCAwareThreadPoolExecutor, MDCAwareThreadPoolExecutor, 
MockDirectoryWrapper, MockDirectoryWrapper, TransactionLog, 
MockDirectoryWrapper]
at __randomizedtesting.SeedInfo.seed([2C69E749B828036B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:257)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 10568 lines...]
   [junit4] Suite: org.apache.solr.schema.TestManagedSchemaAPI
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/temp/solr.schema.TestManagedSchemaAPI_2C69E749B828036B-001/init-core-data-001
   [junit4]   2> 7419 INFO  
(SUITE-TestManagedSchemaAPI-seed#[2C69E749B828036B]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) via: 
@org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
   [junit4]   2> 7482 INFO  
(SUITE-TestManagedSchemaAPI-seed#[2C69E749B828036B]-worker) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 7484 INFO  (Thread-22) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 7484 INFO  (Thread-22) [] o.a.s.c.ZkTestServer Starting 
server
   [junit4]   2> 7584 INFO  
(SUITE-TestManagedSchemaAPI-seed#[2C69E749B828036B]-worker) [] 
o.a.s.c.ZkTestServer start zk server on port:44469
   [junit4]   2> 7593 INFO  
(SUITE-TestManagedSchemaAPI-seed#[2C69E749B828036B]-worker) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 7626 INFO  
(SUITE-TestManagedSchemaAPI-seed#[2C69E749B828036B]-worker) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 7651 INFO  (zkCallback-6-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 

[jira] [Updated] (LUCENE-7439) Should FuzzyQuery match short terms too?

[Michael McCandless (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless updated LUCENE-7439:
---
Attachment: LUCENE-7439.patch

I was struggling to understand the control flow in
FuzzyQuery/FuzzyTermsEnum, MultiTermQuery, TopTermsRewrite, etc., so
as a first step here I cleaned up deprecated code and tried to
simplify FuzzyTermsEnum somewhat.

The attached patch is just this cleanup; it doesn't change the
behavior on short terms.

All tests pass and I confirmed performance (on Wikipedia) is
unchanged.  I plan to first commit this cleanup (master only, removing
deprecations), and then separately tackle the short terms.


> Should FuzzyQuery match short terms too?
> 
>
> Key: LUCENE-7439
> URL: https://issues.apache.org/jira/browse/LUCENE-7439
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0), 6.3
>
> Attachments: LUCENE-7439.patch
>
>
> Today, if you ask {{FuzzyQuery}} to match {{abcd}} with edit distance 2, it 
> will fail to match the term {{ab}} even though it's 2 edits away.
> Its javadocs explain this:
> {noformat}
>  * NOTE: terms of length 1 or 2 will sometimes not match because of how 
> the scaled
>  * distance between two terms is computed.  For a term to match, the edit 
> distance between
>  * the terms must be less than the minimum length term (either the input 
> term, or
>  * the candidate term).  For example, FuzzyQuery on term "abcd" with 
> maxEdits=2 will
>  * not match an indexed term "ab", and FuzzyQuery on term "a" with maxEdits=2 
> will not
>  * match an indexed term "abc".
> {noformat}
> On the one hand, I can see that this behavior is sort of justified in that 
> 50% of the characters are different and so this is a very "weak" match, but 
> on the other hand, it's quite unexpected since edit distance is such an exact 
> measure so the terms should have matched.
> It seems like the behavior is caused by internal implementation details about 
> how the relative (floating point) score is computed.  I think we should fix 
> it, so that edit distance 2 does in fact match all terms with edit distance 
> <= 2.



--
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-9344) BasicAuthIntegrationTest test failures on update

[Alan Woodward (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15479478#comment-15479478
 ] 

Alan Woodward commented on SOLR-9344:
-

OK, this looks like a genuine bug.  The above exception is caused when trying 
to use an HttpClient configured by the PKIAuthenticationPlugin, in combination 
with SSL.  Tests using SSL set a static HttpClientConfigurer on HttpClientUtil, 
but this is then replaced by the PKIAuthenticationPlugin, so any clients 
created after this replacement don't get SSL support.  Maybe HttpClientUtil 
needs to maintain a list of configurers and run through them all, rather than 
just having a single one?

This only happens on 6.x, as the mechanism has changed in master.

> BasicAuthIntegrationTest test failures on update
> 
>
> Key: SOLR-9344
> URL: https://issues.apache.org/jira/browse/SOLR-9344
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security, Tests
>Affects Versions: trunk
>Reporter: Gregory Chanan
>Assignee: Alan Woodward
> Fix For: 6.3
>
> Attachments: SOLR-9344.patch
>
>
> I've seen this a number of times while developing SOLR-9200 and SOLR-9324; 
> there's also a public failure here: 
> http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17372/
> {code}
> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: IOException 
> occured when talking to server at: 
> http://127.0.0.1:45882/solr/testSolrCloudCollection_shard1_replica2
>   at 
> __randomizedtesting.SeedInfo.seed([99BB0D0378978FA8:A463A32F4079D1D8]:0)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:760)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
>   at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
>   at 
> org.apache.solr.security.BasicAuthIntegrationTest.doExtraTests(BasicAuthIntegrationTest.java:193)
>   at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testCollectionCreateSearchDelete(TestMiniSolrCloudClusterBase.java:196)
>   at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testBasics(TestMiniSolrCloudClusterBase.java:79)
>   at 
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
> Method)
>   at 
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
>   at 
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>   at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
>   at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
>   at 
> 

RE: Is "solr.AnalyzerName" expansion supposed to work for Analyzers?

[Uwe Schindler]

Hallo Alexandre,

> I can't see a reason why it should be different, but:
> 
> This works
> 
> 
> 
> 
>
> 
> This does not:
> 
> 
> 
> 
> This does work again:
> 
> 
> 
> 
> Both LowerCaseTokenizerFactory and SimpleAnalyzer are in the same
> package.
> 
> Is this a bug or some sort of legacy decision?

There is a long history behind that and there is also a *fundamental* 
difference between the factories used for building custom analyzers in XML code 
and just referring to an Analyzer!

Let me start with some history: From the early beginning there was the concept 
of factories in Solr, so implementation classes are initialized from a map of 
properties given in the XML. Those factories were specified by Java binary 
class name ("org.apache.solr.foo.bar.MyFactory"). This is used at many places 
in Solr. The problem is that those class names could be quite long, so the 
SolrResourceLoader has a "hack" to allow short names (IMHO, which was a 
horrible decision). When it sees a class starting with name "solr.", it tris to 
lookup different possibilities. See code here: https://goo.gl/P24ZU3 
(subpackages is generally a list like "o.a.solr.something",...).

In the early days (before Lucene/Solr 4.0), those factories were *all* part of 
Solr, so the lookup with the "solr." short name prefix was easy and the 
subpackages list was short. So it "just worked" and many people had those class 
names in their config files.

The Analyzers (2nd example) were always referred to by their full name, because 
they were part of Lucene and not Solr. Using a "solr." Short name was never 
ever possible because of that.

Now a change in 4.0 comes into the game: To make the concept of building 
"custom" analyzers easier to use for non-Solr users, and to make the whole 
concept easier to maintain, the factories for tokenstream components were moved 
out of Solr into Lucene (https://issues.apache.org/jira/browse/LUCENE-2510). 
The analysis parts got new package names below the Lucene namespace. The effect 
of this would have been that all people have to change their config files, 
because the "solr." Shortcut won't work with Lucene classes.

Now you might ask why the "solr." Prefix still works? The reason is a second 
fundamental change with Lucene 4. We no longer use class names in Lucene to 
refer to stuff like Codecs, PostingFormats - we use the java concept of SPI. 
All components get a name, the implementation class is not exposed to outside. 
Like with Codecs, where you use Codec.forName("Lucene70") to instantiate it, 
the same was done for TokenStream components. This allows now to create 
StandardTokenizerFactory using the following code: 
TokenizerFactory.forName("standard"). Or LowercaseFilter with 
TokenFilterFactory.forName("lowercase"). There is no such concept for Analyzers 
(no SPI) [this explains your original question].

Now we have the two pieces to put together: Refactoring of class names and 
adding of SPI concept. The "correct" fix in Solr would have been to remove the 
"class=" attribute in the fieldType and replace by something called "name" or 
"type", so the XML would look like (https://goo.gl/Dr3gpO):


   
  
   


Similar to those examples of the corresponding class to build Analyzers from 
those SPI names in Lucene: 
https://lucene.apache.org/core/6_2_0/analyzers-common/org/apache/lucene/analysis/custom/CustomAnalyzer.html

The above syntax is wonderful, but again this caused lots of complaints from 
Solr developers, that people are unable to understand this WTF :-) It may also 
have to do with those short names look more like   
analysis component names (no idea, although its completely unrelated). The 
issue with more history is here: 
https://issues.apache.org/jira/browse/LUCENE-4044

Because of that there was a second hack added so all schema.xml files worked 
like before (in LUCENE-4044). This hack is the only way to configure 
tokenstream components up to this day - which is a desaster, IMHO! The hack is 
a fancy regular expression that tries to convert the old 
"solr.FoobarTokenFilterFactory" to the nice reading "names" like above: 
https://goo.gl/mtWmjm
The factory is then loaded using SPI: https://goo.gl/EwDtQr
IMHO, the hack should be deprecated and removed and the new syntax, as 
described above, should be introduced.

Analyzer class names would still (and will for sure stay like that - as used 
seldom in Solr) be *full* class names. There is no way to change that!

Now you have a bit of history and you might see that there is absolutely no 
relationship between the class name / package name and the configured "class" 
in schema.xml. In fact, the thing above cannot be fixed. Instead, the issue 
mentioned before should finally be fixed and the "class" attribute in token 
stream components be deprecated and removed and the above "name" (or maybe 
"type") syntax be used.

Uwe