[JENKINS] Lucene-Solr-Tests-5.5-Java8 - Build # 17 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.5-Java8/17/

2 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasics

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


FAILED:  
junit.framework.TestSuite.org.apache.solr.security.BasicAuthIntegrationTest

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

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




Build Log:
[...truncated 12460 lines...]
   [junit4] Suite: org.apache.solr.security.BasicAuthIntegrationTest
   [junit4]   2> 892966 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[DEAF2CE2912C3338]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 892966 INFO  (Thread-2152) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 892966 INFO  (Thread-2152) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 893066 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[DEAF2CE2912C3338]) [] 
o.a.s.c.ZkTestServer start zk server on port:40701
   [junit4]   2> 893067 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[DEAF2CE2912C3338]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 893069 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[DEAF2CE2912C3338]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 893073 INFO  (zkCallback-743-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@7f85b78b 
name:ZooKeeperConnection Watcher:127.0.0.1:40701 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 893073 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[DEAF2CE2912C3338]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 893073 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[DEAF2CE2912C3338]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 893073 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[DEAF2CE2912C3338]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr/solr.xml
   [junit4]   2> 893081 INFO  (jetty-launcher-742-thread-2) [] 
o.e.j.s.Server jetty-9.2.13.v20150730
   [junit4]   2> 893081 INFO  (jetty-launcher-742-thread-4) [] 
o.e.j.s.Server jetty-9.2.13.v20150730
   [junit4]   2> 893081 INFO  (jetty-launcher-742-thread-1) [] 
o.e.j.s.Server jetty-9.2.13.v20150730
   [junit4]   2> 893082 INFO  (jetty-launcher-742-thread-1) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@58182408{/solr,null,AVAILABLE}
   [junit4]   2> 893090 INFO  (jetty-launcher-742-thread-4) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@f39c11d{/solr,null,AVAILABLE}
   [junit4]   2> 893091 INFO  (jetty-launcher-742-thread-2) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@36eec050{/solr,null,AVAILABLE}
   [junit4]   2> 893091 INFO  (jetty-launcher-742-thread-2) [] 
o.e.j.s.ServerConnector Started 
ServerConnector@459aaa0{HTTP/1.1}{127.0.0.1:34824}
   [junit4]   2> 893091 INFO  (jetty-launcher-742-thread-2) [] 
o.e.j.s.Server Started @895052ms
   [junit4]   2> 893091 INFO  (jetty-launcher-742-thread-2) [] 
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr, 
hostPort=34824}
   [junit4]   2> 893091 INFO  (jetty-launcher-742-thread-2) [] 
o.a.s.s.SolrDispatchFilter SolrDispatchFilter.init(): 
sun.misc.Launcher$AppClassLoader@73d16e93
   [junit4]   2> 893091 INFO  (jetty-launcher-742-thread-2) [] 
o.a.s.c.SolrResourceLoader new SolrResourceLoader for directory: 
'/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5-Java8/solr/build/solr-core/test/J0/temp/solr.security.BasicAuthIntegrationTest_DEAF2CE2912C3338-001/tempDir-001/node1'
   [junit4]   2> 893091 INFO  (jetty-launcher-742-thread-2) [] 
o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 893091 INFO  (jetty-launcher-742-thread-2) [] 
o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find 
system property or JNDI)
   [junit4]   2> 893091 INFO  (jetty-launcher-742-thread-2) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 893092 INFO  (jetty-launcher-742-thread-2) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 893092 INFO  (jetty-launcher-742-thread-1) [] 
o.e.j.s.ServerConnector Started 
ServerConnector@2c75f4db{HTTP/1.1}{127.0.0.1:49051}
   [junit4]   2> 893092 INFO  (jetty-launcher-742-thread-1) [] 
o.e.j.s.Server Started @895053ms
   [junit4]   2> 893092 INFO  (jetty-launcher-742-thread-1) [] 

[jira] [Commented] (SOLR-9038) Ability to create/delete/list snapshots for a solr collection

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9038:


Perhaps another way to view this feature proposed here is to have a commit 
optionally include a persistent name (or variable name-value metadata for that 
matter) that will be included with the IndexCommit that is persisted.  That 
would be a somewhat simple way to think of this feature, and needn't involve 
any SolrCloud related stuff.  Of course this data would need to flow-through in 
all the places commit boolean does, which is a lot of places, but I don't think 
it would be hard/complicated.

A separate issue might be a custom deletion policy that treats commits with 
certain special name-value pairs specially, like keeping them around forever 
and letting another API/process expressly delete them when asked.  Perhaps only 
the latest commit that has a certain "name" is kept if there is an older one by 
the same name.

> Ability to create/delete/list snapshots for a solr collection
> -
>
> Key: SOLR-9038
> URL: https://issues.apache.org/jira/browse/SOLR-9038
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Hrishikesh Gadre
>
> Currently work is under-way to implement backup/restore API for Solr cloud 
> (SOLR-5750). SOLR-5750 is about providing an ability to "copy" index files 
> and collection metadata to a configurable location. 
> In addition to this, we should also provide a facility to create "named" 
> snapshots for Solr collection. Here by "snapshot" I mean configuring the 
> underlying Lucene IndexDeletionPolicy to not delete a specific commit point 
> (e.g. using PersistentSnapshotIndexDeletionPolicy). This should not be 
> confused with SOLR-5340 which implements core level "backup" functionality.
> The primary motivation of this feature is to decouple recording/preserving a 
> known consistent state of a collection from actually "copying" the relevant 
> files to a physically separate location. This decoupling have number of 
> advantages
> - We can use specialized data-copying tools for transferring Solr index 
> files. e.g. in Hadoop environment, typically 
> [distcp|https://hadoop.apache.org/docs/r1.2.1/distcp2.html] tool is used to 
> copy files from one location to other. This tool provides various options to 
> configure degree of parallelism, bandwidth usage as well as integration with 
> different types and versions of file systems (e.g. AWS S3, Azure Blob store 
> etc.)
> - This separation of concern would also help Solr to focus on the key 
> functionality (i.e. querying and indexing) while delegating the copy 
> operation to the tools built for that purpose.
> - Users can decide if/when to copy the data files as against creating a 
> snapshot. e.g. a user may want to create a snapshot of a collection before 
> making an experimental change (e.g. updating/deleting docs, schema change 
> etc.). If the experiment is successful, he can delete the snapshot (without 
> having to copy the files). If the experiment is failed, then he can copy the 
> files associated with the snapshot and restore.
> Note that Apache Blur project is also providing a similar feature 
> [BLUR-132|https://issues.apache.org/jira/browse/BLUR-132]



--
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-5750) Backup/Restore API for SolrCloud

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-5750:


I commented on SOLR-9038.  Should that issue come to pass, you're right that we 
need to differentiate a "backup" from a "snapshot" in our terminology, assuming 
we even want these names.  As it is, in some of the code I used "snapshotName" 
as a nod to the existing snapshooter code using such terminology.

> Backup/Restore API for SolrCloud
> 
>
> Key: SOLR-5750
> URL: https://issues.apache.org/jira/browse/SOLR-5750
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Varun Thacker
> Fix For: 5.2, master
>
> Attachments: SOLR-5750.patch, SOLR-5750.patch, SOLR-5750.patch, 
> SOLR-5750.patch, SOLR-5750.patch, SOLR-5750.patch, SOLR-5750.patch
>
>
> We should have an easy way to do backups and restores in SolrCloud. The 
> ReplicationHandler supports a backup command which can create snapshots of 
> the index but that is too little.
> The command should be able to backup:
> # Snapshots of all indexes or indexes from the leader or the shards
> # Config set
> # Cluster state
> # Cluster properties
> # Aliases
> # Overseer work queue?
> A restore should be able to completely restore the cloud i.e. no manual steps 
> required other than bringing nodes back up or setting up a new cloud cluster.
> SOLR-5340 will be a part of this issue.



--
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-6399) Implement unloadCollection in the Collections API

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-6399:


I _think_ this could be closed once SOLR-5750 (SolrCloud Collection 
Backup/Restore) is committed.  At least it addresses the use-case in the 
description.

> Implement unloadCollection in the Collections API
> -
>
> Key: SOLR-6399
> URL: https://issues.apache.org/jira/browse/SOLR-6399
> Project: Solr
>  Issue Type: New Feature
>Reporter: dfdeshom
>Assignee: Shalin Shekhar Mangar
> Fix For: master
>
>
> There is currently no way to unload a collection without deleting its 
> contents. There should be a way in the collections API to unload a collection 
> and reload it later, as needed.
> A use case for this is the following: you store logs by day, with each day 
> having its own collection. You are required to store up to 2 years of data, 
> which adds up to 730 collections.  Most of the time, you'll want to have 3 
> days of data loaded for search. Having just 3 collections loaded into memory, 
> instead of 730 will make managing Solr easier.



--
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-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9046:
-

I just noticed that all of you also backported to 5.x branch. So I 
cherry-picked the commit, too (from 5.5 to not conflict changes again)

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Uwe Schindler
> Fix For: master, 5.5.1, 6.1
>
> Attachments: SOLR-9045.patch, SOLR-9046.patch, SOLR-9046.patch, 
> SOLR-9046.patch, SOLR-9046.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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-9038) Ability to create/delete/list snapshots for a solr collection

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9038:


Cool.  So I presume by "snapshot", we're talking about named (or numbered) 
Lucene IndexCommit objects across all replicas of a Solr Collection?  And then, 
in SOLR-5750 or future patch, the "backup" capability might optionally make 
reference to a named snapshot instead of just taking the last IndexCommit?  And 
in some separate issue, a rollback ability, I presume.

> Ability to create/delete/list snapshots for a solr collection
> -
>
> Key: SOLR-9038
> URL: https://issues.apache.org/jira/browse/SOLR-9038
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Hrishikesh Gadre
>
> Currently work is under-way to implement backup/restore API for Solr cloud 
> (SOLR-5750). SOLR-5750 is about providing an ability to "copy" index files 
> and collection metadata to a configurable location. 
> In addition to this, we should also provide a facility to create "named" 
> snapshots for Solr collection. Here by "snapshot" I mean configuring the 
> underlying Lucene IndexDeletionPolicy to not delete a specific commit point 
> (e.g. using PersistentSnapshotIndexDeletionPolicy). This should not be 
> confused with SOLR-5340 which implements core level "backup" functionality.
> The primary motivation of this feature is to decouple recording/preserving a 
> known consistent state of a collection from actually "copying" the relevant 
> files to a physically separate location. This decoupling have number of 
> advantages
> - We can use specialized data-copying tools for transferring Solr index 
> files. e.g. in Hadoop environment, typically 
> [distcp|https://hadoop.apache.org/docs/r1.2.1/distcp2.html] tool is used to 
> copy files from one location to other. This tool provides various options to 
> configure degree of parallelism, bandwidth usage as well as integration with 
> different types and versions of file systems (e.g. AWS S3, Azure Blob store 
> etc.)
> - This separation of concern would also help Solr to focus on the key 
> functionality (i.e. querying and indexing) while delegating the copy 
> operation to the tools built for that purpose.
> - Users can decide if/when to copy the data files as against creating a 
> snapshot. e.g. a user may want to create a snapshot of a collection before 
> making an experimental change (e.g. updating/deleting docs, schema change 
> etc.). If the experiment is successful, he can delete the snapshot (without 
> having to copy the files). If the experiment is failed, then he can copy the 
> files associated with the snapshot and restore.
> Note that Apache Blur project is also providing a similar feature 
> [BLUR-132|https://issues.apache.org/jira/browse/BLUR-132]



--
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-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-9046:
---

Commit 391872065980bda690e61ee8757eefedc722e2fe in lucene-solr's branch 
refs/heads/branch_5x from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3918720 ]

SOLR-9046: Fix solr.cmd that wrongly assumes Jetty will always listen on 0.0.0.0

# Conflicts:
#   solr/CHANGES.txt


> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Uwe Schindler
> Fix For: master, 5.5.1, 6.1
>
> Attachments: SOLR-9045.patch, SOLR-9046.patch, SOLR-9046.patch, 
> SOLR-9046.patch, SOLR-9046.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9046:
-

I did not commit to 5.x branch, because this one was declared "dead" - only 5.5 
is alive.

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Uwe Schindler
> Fix For: master, 5.5.1, 6.1
>
> Attachments: SOLR-9045.patch, SOLR-9046.patch, SOLR-9046.patch, 
> SOLR-9046.patch, SOLR-9046.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9046:
-

Sorry, of course I committed to:
- master
- 6.x
- 5.5

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Uwe Schindler
> Fix For: master, 5.5.1, 6.1
>
> Attachments: SOLR-9045.patch, SOLR-9046.patch, SOLR-9046.patch, 
> SOLR-9046.patch, SOLR-9046.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



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

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

[jira] [Comment Edited] (SOLR-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-9046 at 4/28/16 4:21 AM:
--

Thanks Uwe. I believe you meant 5x and 5.5 instead of 5.0.


was (Author: anshumg):
bq. Thanks Uwe. I believe you meant 5x and 5.5 instead of 5.0.

- master
- 6.x
- 5.5

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Uwe Schindler
> Fix For: master, 5.5.1, 6.1
>
> Attachments: SOLR-9045.patch, SOLR-9046.patch, SOLR-9046.patch, 
> SOLR-9046.patch, SOLR-9046.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



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

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

[jira] [Comment Edited] (SOLR-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-9046 at 4/28/16 4:20 AM:
--

bq. Thanks Uwe. I believe you meant 5x and 5.5 instead of 5.0.

- master
- 6.x
- 5.5


was (Author: anshumg):
Thanks Uwe. I believe you meant 5x and 5.5 instead of 5.0.

- master
- 6.x
- 5.5

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Uwe Schindler
> Fix For: master, 5.5.1, 6.1
>
> Attachments: SOLR-9045.patch, SOLR-9046.patch, SOLR-9046.patch, 
> SOLR-9046.patch, SOLR-9046.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



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

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

[jira] [Comment Edited] (SOLR-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-9046 at 4/28/16 4:20 AM:
--

Thanks Uwe. I believe you meant 5x and 5.5 instead of 5.0.

- master
- 6.x
- 5.5


was (Author: anshumg):
Thanks Uwe. I believe you meant 5x and 5.5 instead of 5.0.

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Uwe Schindler
> Fix For: master, 5.5.1, 6.1
>
> Attachments: SOLR-9045.patch, SOLR-9046.patch, SOLR-9046.patch, 
> SOLR-9046.patch, SOLR-9046.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



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

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

[jira] [Resolved] (SOLR-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Uwe Schindler (JIRA)]

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

Uwe Schindler resolved SOLR-9046.
-
Resolution: Fixed
  Assignee: Uwe Schindler  (was: Timothy Potter)

I committed/cherrypicked the patch:
- master
- branch_6x
- branch_5_5

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Uwe Schindler
> Fix For: master, 5.5.1, 6.1
>
> Attachments: SOLR-9045.patch, SOLR-9046.patch, SOLR-9046.patch, 
> SOLR-9046.patch, SOLR-9046.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated SOLR-9046:

Fix Version/s: 6.1
   master

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Timothy Potter
> Fix For: master, 5.5.1, 6.1
>
> Attachments: SOLR-9045.patch, SOLR-9046.patch, SOLR-9046.patch, 
> SOLR-9046.patch, SOLR-9046.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-9046:
---

Commit 95c985be0aed654a0bc293b72f75270603130f75 in lucene-solr's branch 
refs/heads/branch_5_5 from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=95c985b ]

SOLR-9046: Fix solr.cmd that wrongly assumes Jetty will always listen on 0.0.0.0

# Conflicts:
#   solr/CHANGES.txt


> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Timothy Potter
> Fix For: 5.5.1
>
> Attachments: SOLR-9045.patch, SOLR-9046.patch, SOLR-9046.patch, 
> SOLR-9046.patch, SOLR-9046.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-9046:
---

Commit 9e34d3137f6b5a90a207c86b88cdd6ba17f0553e in lucene-solr's branch 
refs/heads/branch_6x from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9e34d31 ]

SOLR-9046: Fix solr.cmd that wrongly assumes Jetty will always listen on 0.0.0.0


> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Timothy Potter
> Fix For: 5.5.1
>
> Attachments: SOLR-9045.patch, SOLR-9046.patch, SOLR-9046.patch, 
> SOLR-9046.patch, SOLR-9046.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-9046:
---

Commit 3e6de6059ff8e42731e6acd52623e4f5d3e23fca in lucene-solr's branch 
refs/heads/master from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3e6de60 ]

SOLR-9046: Fix solr.cmd that wrongly assumes Jetty will always listen on 0.0.0.0


> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Timothy Potter
> Fix For: 5.5.1
>
> Attachments: SOLR-9045.patch, SOLR-9046.patch, SOLR-9046.patch, 
> SOLR-9046.patch, SOLR-9046.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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: Feature list of Lucene 5

[Jack Krupansky]

The Solr release announcements summarize the highlights as well:
http://lucene.apache.org/solr/news.html

Some of the Jira jargon is translated into plain English.

-- Jack Krupansky

On Wed, Apr 27, 2016 at 11:46 PM, Thomas Pan 
wrote:

>
> Alexandre,
>
> Thanks for your prompt response!
>
>
> Best,
> Thomas
>
>
>
> --
> The journey of a thousand miles begins with one step. -- Lao Tzu
> Do not go where the path may lead, go instead where there is no path and
> leave a trail. -- Ralph Waldo Emerson
>
> On Wed, Apr 27, 2016 at 5:34 PM, Alexandre Rafalovitch  > wrote:
>
>>
>> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/5.0.0/lucene/CHANGES.txt
>>
>> Changes list is probably the easiest source.
>>
>> Regards,
>>Alex.
>> 
>> Newsletter and resources for Solr beginners and intermediates:
>> http://www.solr-start.com/
>>
>>
>> On 28 April 2016 at 10:20, Thomas Pan  wrote:
>> >
>> > Hi,
>> >
>> > Where can I find the feature list with features introduced between
>> Lucene
>> > 4.5 and Lucene 5?
>> >
>> >
>> > Best,
>> > Thomas
>> >
>> >
>> > --
>> > The journey of a thousand miles begins with one step. -- Lao Tzu
>> > Do not go where the path may lead, go instead where there is no path and
>> > leave a trail. -- Ralph Waldo Emerson
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>

Re: Feature list of Lucene 5

[Thomas Pan]

Alexandre,

Thanks for your prompt response!


Best,
Thomas



--
The journey of a thousand miles begins with one step. -- Lao Tzu
Do not go where the path may lead, go instead where there is no path and
leave a trail. -- Ralph Waldo Emerson

On Wed, Apr 27, 2016 at 5:34 PM, Alexandre Rafalovitch 
wrote:

>
> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/5.0.0/lucene/CHANGES.txt
>
> Changes list is probably the easiest source.
>
> Regards,
>Alex.
> 
> Newsletter and resources for Solr beginners and intermediates:
> http://www.solr-start.com/
>
>
> On 28 April 2016 at 10:20, Thomas Pan  wrote:
> >
> > Hi,
> >
> > Where can I find the feature list with features introduced between Lucene
> > 4.5 and Lucene 5?
> >
> >
> > Best,
> > Thomas
> >
> >
> > --
> > The journey of a thousand miles begins with one step. -- Lao Tzu
> > Do not go where the path may lead, go instead where there is no path and
> > leave a trail. -- Ralph Waldo Emerson
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (LUCENE-6968) LSH Filter

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on LUCENE-6968:
--

Thanks, that make sense!

> LSH Filter
> --
>
> Key: LUCENE-6968
> URL: https://issues.apache.org/jira/browse/LUCENE-6968
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Cao Manh Dat
> Attachments: LUCENE-6968.patch, LUCENE-6968.patch, LUCENE-6968.patch
>
>
> I'm planning to implement LSH. Which support query like this
> {quote}
> Find similar documents that have 0.8 or higher similar score with a given 
> document. Similarity measurement can be cosine, jaccard, euclid..
> {quote}
> For example. Given following corpus
> {quote}
> 1. Solr is an open source search engine based on Lucene
> 2. Solr is an open source enterprise search engine based on Lucene
> 3. Solr is an popular open source enterprise search engine based on Lucene
> 4. Apache Lucene is a high-performance, full-featured text search engine 
> library written entirely in Java
> {quote}
> We wanna find documents that have 0.6 score in jaccard measurement with this 
> doc
> {quote}
> Solr is an open source search engine
> {quote}
> It will return only docs 1,2 and 3 (MoreLikeThis will also return doc 4)



--
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-9028) fix bugs in (add sanity checks for) SSL clientAuth testing

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-9028:
---
Attachment: SOLR-9028.patch

Updated patch...

bq. I want to cleanup some of the SSLTestConfig methods that only exist in 
master and have weird side effects (introduced in SOLR-4509)

done.

bq. I think it might makes sense to promote the the 
SSLContext.getDefault/setDefault preservation to SolrTestCaseJ4 ... but i'm not 
100% certain yet. Need to think it through more.

I decided this is probably not a good idea -- no reason to add to the number of 
things SolrTestCaseJ4 is doing automagically w/o a need for it.



I think this is basically ready ... I'm going to hammer on tests w/it for a bit.

> fix bugs in (add sanity checks for) SSL clientAuth testing
> --
>
> Key: SOLR-9028
> URL: https://issues.apache.org/jira/browse/SOLR-9028
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-9028.patch, SOLR-9028.patch, SOLR-9028.patch, 
> SOLR-9028.patch, SOLR-9028.patch, SOLR-9028.patch, os.x.failure.txt
>
>
> While looking into SOLR-8970 i realized there was a whole heap of problems 
> with how clientAuth was being handled in tests.  Notably: it wasn't actaully 
> being used when the randomization selects it (aparently due to a copy/paste 
> mistake in SOLR-7166).  But there are few other misc issues (improper usage 
> of sysprops overrides for tests, missuage of keystore/truststore in test 
> clients, etc..)
> I'm working up a patch to fix all of this, and add some much needed tests to 
> *explicitly* verify both SSL and clientAuth that will include some "false 
> positive" verifications, and some "test the test" checks.



--
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] [Issue Comment Deleted] (SOLR-8812) ExtendedDismaxQParser (edismax) ignores Boolean OR when q.op=AND

[Ryan Steinberg (JIRA)]

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

Ryan Steinberg updated SOLR-8812:
-
Comment: was deleted

(was: I am out of the office until Monday, May 2nd and will reply to your email
when I return.

)

> ExtendedDismaxQParser (edismax) ignores Boolean OR when q.op=AND
> 
>
> Key: SOLR-8812
> URL: https://issues.apache.org/jira/browse/SOLR-8812
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 5.5
>Reporter: Ryan Steinberg
>Assignee: Erick Erickson
> Fix For: 6.0, 5.5.1
>
> Attachments: SOLR-8812-barbie.patch, SOLR-8812.patch, SOLR-8812.patch
>
>
> The edismax parser ignores Boolean OR in queries when q.op=AND. This behavior 
> is new to Solr 5.5.0 and an unexpected major change.
> Example:
>   "q": "id:12345 OR zz",
>   "defType": "edismax",
>   "q.op": "AND",
> where "12345" is a known document ID and "zz" is a string NOT present 
> in my data
> Version 5.5.0 produces zero results:
> "rawquerystring": "id:12345 OR zz",
> "querystring": "id:12345 OR zz",
> "parsedquery": "(+((id:12345 
> DisjunctionMaxQuery((text:zz)))~2))/no_coord",
> "parsedquery_toString": "+((id:12345 (text:zz))~2)",
> "explain": {},
> "QParser": "ExtendedDismaxQParser"
> Version 5.4.0 produces one result as expected
>   "rawquerystring": "id:12345 OR zz",
> "querystring": "id:12345 OR zz",
> "parsedquery": "(+(id:12345 
> DisjunctionMaxQuery((text:zz/no_coord",
> "parsedquery_toString": "+(id:12345 (text:zz))"
> "explain": {},
> "QParser": "ExtendedDismaxQParser"



--
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-8208) DocTransformer executes sub-queries

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-8208:
---
Attachment: SOLR-8208.patch

Make distrib test pass.

> DocTransformer executes sub-queries
> ---
>
> Key: SOLR-8208
> URL: https://issues.apache.org/jira/browse/SOLR-8208
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>  Labels: features, newbie
> Attachments: SOLR-8208.diff, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch
>
>
> The initial idea was to return "from" side of query time join via 
> doctransformer. I suppose it isn't  query-time join specific, thus let to 
> specify any query and parameters for them, let's call them sub-query. But it 
> might be problematic to escape subquery parameters, including local ones, 
> e.g. what if subquery needs to specify own doctransformer in =\[..\] ?
> I suppose we can allow to specify subquery parameter prefix:
> {code}
> ..=id,[subquery paramPrefix=subq1. 
> fromIndex=othercore],score,..={!term f=child_id 
> v=$subq1.row.id}=3=price&..
> {code}   
> * {{paramPrefix=subq1.}} shifts parameters for subquery: {{subq1.q}} turns to 
> {{q}} for subquery, {{subq1.rows}} to {{rows}}
> * {{fromIndex=othercore}} optional param allows to run subquery on other 
> core, like it works on query time join
> * the itchiest one is to reference to document field from subquery 
> parameters, here I propose to use local param {{v}} and param deference 
> {{v=$param}} thus every document field implicitly introduces parameter for 
> subquery $\{paramPrefix\}row.$\{fieldName\}, thus above subquery is 
> q=child_id:, presumably we can drop "row." in the middle 
> (reducing to v=$subq1.id), until someone deal with {{rows}}, {{sort}} fields. 
> * \[subquery\], or \[query\], or ? 
> Caveat: it should be a way slow; it handles only search result page, not 
> entire result set. 



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

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

[JENKINS] Lucene-Solr-NightlyTests-5.5 - Build # 5 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.5/5/

10 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CollectionsAPIDistributedZkTest

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

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


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CollectionsAPIDistributedZkTest

Error Message:
Captured an uncaught exception in thread: Thread[id=5532, name=collection4, 
state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=5532, name=collection4, state=RUNNABLE, 
group=TGRP-CollectionsAPIDistributedZkTest]
Caused by: java.lang.RuntimeException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:38628, http://127.0.0.1:60704, 
http://127.0.0.1:44277, http://127.0.0.1:57002, http://127.0.0.1:54905]
at __randomizedtesting.SeedInfo.seed([CB98B72D926300F0]:0)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:994)
Caused by: org.apache.solr.client.solrj.SolrServerException: No live 
SolrServers available to handle this request:[http://127.0.0.1:38628, 
http://127.0.0.1:60704, http://127.0.0.1:44277, http://127.0.0.1:57002, 
http://127.0.0.1:54905]
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1100)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1575)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1596)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:984)
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:57002: KeeperErrorCode = Session expired for 
/overseer/collection-queue-work/qnr-
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:577)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:372)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:325)
... 7 more


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CollectionsAPIDistributedZkTest

Error Message:
Captured an uncaught exception in thread: Thread[id=5533, name=collection5, 
state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=5533, name=collection5, state=RUNNABLE, 
group=TGRP-CollectionsAPIDistributedZkTest]
Caused by: java.lang.RuntimeException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:38628, http://127.0.0.1:60704, 
http://127.0.0.1:44277, http://127.0.0.1:57002, http://127.0.0.1:54905]
at __randomizedtesting.SeedInfo.seed([CB98B72D926300F0]:0)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:994)
Caused by: org.apache.solr.client.solrj.SolrServerException: No live 
SolrServers available to handle this request:[http://127.0.0.1:38628, 
http://127.0.0.1:60704, http://127.0.0.1:44277, http://127.0.0.1:57002, 
http://127.0.0.1:54905]
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1100)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1575)
at 

[jira] [Commented] (SOLR-9047) zkcli should allow alternative locations for log4j configuration

[Gregory Chanan (JIRA)]

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

Gregory Chanan commented on SOLR-9047:
--

bq. is it time to just kill zkcli and move it's functionality into bin/solr ?

probably :).  In any case that would be a 7.x change, right?  This would be 
useful in 6.x imo.

> zkcli should allow alternative locations for log4j configuration
> 
>
> Key: SOLR-9047
> URL: https://issues.apache.org/jira/browse/SOLR-9047
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools, SolrCloud
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
>Priority: Minor
>
> zkcli uses the log4j configuration in the local directory:
> {code}
> sdir="`dirname \"$0\"`"
> PATH=$JAVA_HOME/bin:$PATH $JVM 
> -Dlog4j.configuration=file:$sdir/log4j.properties -classpath 
> "$sdir/../../solr-webapp/webapp/WEB-INF/lib/*:$sdir/../../lib/ext/*" 
> org.apache.solr.cloud.ZkCLI ${1+"$@"}
> {code}
> which is a reasonable default, but often people want to use a "global" log4j 
> configuration.  For example, one may define a log4j configuration that writes 
> to an external log directory and want to point to this rather than copying it 
> to each source checkout.



--
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-9047) zkcli should allow alternative locations for log4j configuration

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-9047:


is it time to just kill zkcli and move it's functionality into bin/solr ?

> zkcli should allow alternative locations for log4j configuration
> 
>
> Key: SOLR-9047
> URL: https://issues.apache.org/jira/browse/SOLR-9047
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools, SolrCloud
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
>Priority: Minor
>
> zkcli uses the log4j configuration in the local directory:
> {code}
> sdir="`dirname \"$0\"`"
> PATH=$JAVA_HOME/bin:$PATH $JVM 
> -Dlog4j.configuration=file:$sdir/log4j.properties -classpath 
> "$sdir/../../solr-webapp/webapp/WEB-INF/lib/*:$sdir/../../lib/ext/*" 
> org.apache.solr.cloud.ZkCLI ${1+"$@"}
> {code}
> which is a reasonable default, but often people want to use a "global" log4j 
> configuration.  For example, one may define a log4j configuration that writes 
> to an external log directory and want to point to this rather than copying it 
> to each source checkout.



--
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-9027) Add GraphTermsQuery to limit traversal on high frequency nodes

[Kevin Watters (JIRA)]

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

Kevin Watters commented on SOLR-9027:
-

no specific use case.. but if doc frequency is 0 for a given term in a 
"node/from" field,  there's not much point in traversing it,or querying for it 
in the first place.   I'm not sure if that's even possible, but you might have 
edges that point to a document that doesn't exist, in such a case, it's an easy 
optimization to avoid that traversal.   (similar to the leafNodesOnly parameter 
on the GraphQuery.)


> Add GraphTermsQuery to limit traversal on high frequency nodes
> --
>
> Key: SOLR-9027
> URL: https://issues.apache.org/jira/browse/SOLR-9027
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Priority: Minor
> Attachments: SOLR-9027.patch, SOLR-9027.patch, SOLR-9027.patch, 
> SOLR-9027.patch
>
>
> The gatherNodes() Streaming Expression is currently using a basic disjunction 
> query to perform the traversals. This ticket is to create a specific 
> GraphTermsQuery for performing the traversals. 
> The GraphTermsQuery will be based off of the TermsQuery, but will also 
> include an option for a docFreq cutoff. Terms that are above the docFreq 
> cutoff will not be included in the query. This will help users do a more 
> precise and efficient traversal.



--
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-9027) Add GraphTermsQuery to limit traversal on high frequency nodes

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9027:
--

Sure, this would be easy to add. I was having a hard time thinking of the use 
cases though. Are there scenarios where nodes with low document frequencies are 
better to skip?

> Add GraphTermsQuery to limit traversal on high frequency nodes
> --
>
> Key: SOLR-9027
> URL: https://issues.apache.org/jira/browse/SOLR-9027
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Priority: Minor
> Attachments: SOLR-9027.patch, SOLR-9027.patch, SOLR-9027.patch, 
> SOLR-9027.patch
>
>
> The gatherNodes() Streaming Expression is currently using a basic disjunction 
> query to perform the traversals. This ticket is to create a specific 
> GraphTermsQuery for performing the traversals. 
> The GraphTermsQuery will be based off of the TermsQuery, but will also 
> include an option for a docFreq cutoff. Terms that are above the docFreq 
> cutoff will not be included in the query. This will help users do a more 
> precise and efficient traversal.



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

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

[jira] [Created] (SOLR-9047) zkcli should allow alternative locations for log4j configuration

[Gregory Chanan (JIRA)]

Gregory Chanan created SOLR-9047:


 Summary: zkcli should allow alternative locations for log4j 
configuration
 Key: SOLR-9047
 URL: https://issues.apache.org/jira/browse/SOLR-9047
 Project: Solr
  Issue Type: Improvement
  Components: scripts and tools, SolrCloud
Reporter: Gregory Chanan
Assignee: Gregory Chanan
Priority: Minor


zkcli uses the log4j configuration in the local directory:
{code}
sdir="`dirname \"$0\"`"

PATH=$JAVA_HOME/bin:$PATH $JVM 
-Dlog4j.configuration=file:$sdir/log4j.properties -classpath 
"$sdir/../../solr-webapp/webapp/WEB-INF/lib/*:$sdir/../../lib/ext/*" 
org.apache.solr.cloud.ZkCLI ${1+"$@"}
{code}

which is a reasonable default, but often people want to use a "global" log4j 
configuration.  For example, one may define a log4j configuration that writes 
to an external log directory and want to point to this rather than copying it 
to each source checkout.



--
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-8962) Add sort Streaming Expression

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8962:
--

I've been thinking a little bit about this ticket. One of this nice things it 
provides is a the ability to re-sort a set following a join. So we could 
innerJoin->sort-rollup, which is a key use case. We can also 
innerJoin->sort->innerJoin which is also a key use case.

I did a quick test to see how many random strings could be sorted per-second. I 
used the Random class to pick random longs and turned the longs into Strings 
for the test set. 

I was seeing sort times of 1 second for 1.5 million random strings, using 
Collections.sort(). 

So with 50 workers that translates to roughly 75 million records per second. 

With fork/join merge sort we should be able to scale nearly linearly until we 
hit the number of processors on the server. This is because of the tight memory 
locality of sorting, which won't saturate the memory bus. So with 8 threads we 
can expect to sort close to 12 million records per second on each worker. Now 
we're talking some big numbers. With 50 workers we'd be sorting 600,000,000 
records per-second. 

What's nice about the fork/join is it gives us two levels of parallelism. We 
get the first level a of parallelism by having multiple workers and then we get 
the second level by threading. I see some very fast operations following joins 
in the future.



> Add sort Streaming Expression
> -
>
> Key: SOLR-8962
> URL: https://issues.apache.org/jira/browse/SOLR-8962
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Dennis Gove
>Priority: Critical
> Fix For: master, 6.1
>
> Attachments: SOLR-8962.patch, SOLR-8962.patch
>
>
> The sort Streaming Expression does an in memory sort of the Tuples returned 
> by it's underlying stream. This is intended to be used for sorting sets 
> gathered during local graph traversals. This will make it easy to gather sets 
> during a traversal and use all of the sort based set operations (merge, 
> innerJoin, outerJoin, reduce, complement, intersect). 
> This will be particularly useful with the gatherNodes expression (SOLR-8925). 
> Sample syntax:
> {code}
> intersect(
>sort(gatherNodes(...), "fieldA asc"),
>sort(gatherNodes(...), "fieldA asc"),
>on)
> {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-7260) StandardQueryParser is over 100 times slower in v5 compared to v3

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on LUCENE-7260:
--

It may be BooleanQuery construction and not the parser.  Stuff like LUCENE-6305 
made constructing one a more heavy-weight operation.

> StandardQueryParser is over 100 times slower in v5 compared to v3
> -
>
> Key: LUCENE-7260
> URL: https://issues.apache.org/jira/browse/LUCENE-7260
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/queryparser
>Affects Versions: 5.4.1
> Environment: Java 8u51
>Reporter: Trejkaz
>  Labels: performance
>
> The following test code times parsing a large query.
> {code}
> import org.apache.lucene.analysis.KeywordAnalyzer;
> //import org.apache.lucene.analysis.core.KeywordAnalyzer;
> import org.apache.lucene.queryParser.standard.StandardQueryParser;
> //import org.apache.lucene.queryparser.flexible.standard.StandardQueryParser;
> import org.apache.lucene.search.BooleanQuery;
> public class LargeQueryTest {
> public static void main(String[] args) throws Exception {
> BooleanQuery.setMaxClauseCount(50_000);
> StringBuilder builder = new StringBuilder(50_000*10);
> builder.append("id:( ");
> boolean first = true;
> for (int i = 0; i < 50_000; i++) {
> if (first) {
> first = false;
> } else {
> builder.append(" OR ");
> }
> builder.append(String.valueOf(i));
> }
> builder.append(" )");
> String queryString = builder.toString();
> StandardQueryParser parser2 = new StandardQueryParser(new 
> KeywordAnalyzer());
> for (int i = 0; i < 10; i++) {
> long t0 = System.currentTimeMillis();
> parser2.parse(queryString, "nope");
> long t1 = System.currentTimeMillis();
> System.out.println(t1-t0);
> }
> }
> }
> {code}
> For Lucene 3.6.2, the timings settle down to 200~300 with the fastest being 
> 207.
> For Lucene 5.4.1, the timings settle down to 2~3 with the fastest 
> being 22444.
> So at some point, some change made the query parser 100 times slower. I would 
> suspect that it has something to do with how the list of children is now 
> handled. Every time someone gets the children, it copies the list. Every time 
> someone sets the children, it walks through to detach parent references and 
> then reattaches them all again.
> If it were me, I would probably make these collections immutable so that I 
> didn't have to defensively copy them.



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

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

[jira] [Created] (LUCENE-7260) StandardQueryParser is over 100 times slower in v5 compared to v3

[Trejkaz (JIRA)]

Trejkaz created LUCENE-7260:
---

 Summary: StandardQueryParser is over 100 times slower in v5 
compared to v3
 Key: LUCENE-7260
 URL: https://issues.apache.org/jira/browse/LUCENE-7260
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/queryparser
Affects Versions: 5.4.1
 Environment: Java 8u51
Reporter: Trejkaz


The following test code times parsing a large query.

{code}
import org.apache.lucene.analysis.KeywordAnalyzer;
//import org.apache.lucene.analysis.core.KeywordAnalyzer;
import org.apache.lucene.queryParser.standard.StandardQueryParser;
//import org.apache.lucene.queryparser.flexible.standard.StandardQueryParser;
import org.apache.lucene.search.BooleanQuery;

public class LargeQueryTest {
public static void main(String[] args) throws Exception {
BooleanQuery.setMaxClauseCount(50_000);
StringBuilder builder = new StringBuilder(50_000*10);
builder.append("id:( ");
boolean first = true;
for (int i = 0; i < 50_000; i++) {
if (first) {
first = false;
} else {
builder.append(" OR ");
}
builder.append(String.valueOf(i));
}
builder.append(" )");
String queryString = builder.toString();

StandardQueryParser parser2 = new StandardQueryParser(new 
KeywordAnalyzer());

for (int i = 0; i < 10; i++) {
long t0 = System.currentTimeMillis();
parser2.parse(queryString, "nope");
long t1 = System.currentTimeMillis();
System.out.println(t1-t0);
}
}
}
{code}

For Lucene 3.6.2, the timings settle down to 200~300 with the fastest being 207.
For Lucene 5.4.1, the timings settle down to 2~3 with the fastest being 
22444.

So at some point, some change made the query parser 100 times slower. I would 
suspect that it has something to do with how the list of children is now 
handled. Every time someone gets the children, it copies the list. Every time 
someone sets the children, it walks through to detach parent references and 
then reattaches them all again.

If it were me, I would probably make these collections immutable so that I 
didn't have to defensively copy them.




--
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-7475) Value of Heap Memory Usage display

[wei wang (JIRA)]

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

wei wang commented on SOLR-7475:


Still seeing the issue in version 5.4.0. 

> Value of Heap Memory Usage display
> --
>
> Key: SOLR-7475
> URL: https://issues.apache.org/jira/browse/SOLR-7475
> Project: Solr
>  Issue Type: Bug
>  Components: UI, web gui
>Affects Versions: 5.0
> Environment: Windows 7 operating system, Solr-5.0, zookeeper-3.4.6
>Reporter: Yeo Zheng Lin
>  Labels: memory, solr, ui
> Attachments: Heap Memory Usage.png
>
>
> In the Solr-5.0 admin UI, select a collection, click on Overview. This will 
> show the statistics of the collection. 
> For the Heap Memory Usage, it is showing the value -1 instead of the Heap 
> Memory Usage for that collection. It was said to be working on the previous 
> versions of Solr, and in version 5.0 it was showing -1.



--
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-9027) Add GraphTermsQuery to limit traversal on high frequency nodes

[Kevin Watters (JIRA)]

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

Kevin Watters commented on SOLR-9027:
-

Yes, sorry for the typo, minDocFreq :)  avoid sparse edges .. could be a useful 
use case.. (especially in a distributed use case)

> Add GraphTermsQuery to limit traversal on high frequency nodes
> --
>
> Key: SOLR-9027
> URL: https://issues.apache.org/jira/browse/SOLR-9027
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Priority: Minor
> Attachments: SOLR-9027.patch, SOLR-9027.patch, SOLR-9027.patch, 
> SOLR-9027.patch
>
>
> The gatherNodes() Streaming Expression is currently using a basic disjunction 
> query to perform the traversals. This ticket is to create a specific 
> GraphTermsQuery for performing the traversals. 
> The GraphTermsQuery will be based off of the TermsQuery, but will also 
> include an option for a docFreq cutoff. Terms that are above the docFreq 
> cutoff will not be included in the query. This will help users do a more 
> precise and efficient traversal.



--
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-9027) Add GraphTermsQuery to limit traversal on high frequency nodes

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9027:
--

Thanks!

The GraphTermsQuery has a maxDocFreq param, did you mean a minDocFreq?

> Add GraphTermsQuery to limit traversal on high frequency nodes
> --
>
> Key: SOLR-9027
> URL: https://issues.apache.org/jira/browse/SOLR-9027
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Priority: Minor
> Attachments: SOLR-9027.patch, SOLR-9027.patch, SOLR-9027.patch, 
> SOLR-9027.patch
>
>
> The gatherNodes() Streaming Expression is currently using a basic disjunction 
> query to perform the traversals. This ticket is to create a specific 
> GraphTermsQuery for performing the traversals. 
> The GraphTermsQuery will be based off of the TermsQuery, but will also 
> include an option for a docFreq cutoff. Terms that are above the docFreq 
> cutoff will not be included in the query. This will help users do a more 
> precise and efficient traversal.



--
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: Feature list of Lucene 5

[Alexandre Rafalovitch]

https://github.com/apache/lucene-solr/blob/releases/lucene-solr/5.0.0/lucene/CHANGES.txt

Changes list is probably the easiest source.

Regards,
   Alex.

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


On 28 April 2016 at 10:20, Thomas Pan  wrote:
>
> Hi,
>
> Where can I find the feature list with features introduced between Lucene
> 4.5 and Lucene 5?
>
>
> Best,
> Thomas
>
>
> --
> The journey of a thousand miles begins with one step. -- Lao Tzu
> Do not go where the path may lead, go instead where there is no path and
> leave a trail. -- Ralph Waldo Emerson

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

[JENKINS] Lucene-Solr-5.5-Windows (64bit/jdk1.8.0_92) - Build # 58 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Windows/58/
Java: 64bit/jdk1.8.0_92 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.lucene.store.TestSimpleFSDirectory

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-5.5-Windows\lucene\build\core\test\J0\temp\lucene.store.TestSimpleFSDirectory_BA75157CCC80915B-001\testThreadSafety-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-5.5-Windows\lucene\build\core\test\J0\temp\lucene.store.TestSimpleFSDirectory_BA75157CCC80915B-001\testThreadSafety-001

C:\Users\jenkins\workspace\Lucene-Solr-5.5-Windows\lucene\build\core\test\J0\temp\lucene.store.TestSimpleFSDirectory_BA75157CCC80915B-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-5.5-Windows\lucene\build\core\test\J0\temp\lucene.store.TestSimpleFSDirectory_BA75157CCC80915B-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-5.5-Windows\lucene\build\core\test\J0\temp\lucene.store.TestSimpleFSDirectory_BA75157CCC80915B-001\testThreadSafety-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-5.5-Windows\lucene\build\core\test\J0\temp\lucene.store.TestSimpleFSDirectory_BA75157CCC80915B-001\testThreadSafety-001
   
C:\Users\jenkins\workspace\Lucene-Solr-5.5-Windows\lucene\build\core\test\J0\temp\lucene.store.TestSimpleFSDirectory_BA75157CCC80915B-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-5.5-Windows\lucene\build\core\test\J0\temp\lucene.store.TestSimpleFSDirectory_BA75157CCC80915B-001

at __randomizedtesting.SeedInfo.seed([BA75157CCC80915B]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:295)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:217)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
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 738 lines...]
   [junit4] Suite: org.apache.lucene.store.TestSimpleFSDirectory
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene54): {}, 
docValues:{}, sim=DefaultSimilarity, locale=ja, timezone=Asia/Novokuznetsk
   [junit4]   2> NOTE: Windows 10 10.0 amd64/Oracle Corporation 1.8.0_92 
(64-bit)/cpus=3,threads=1,free=70534840,total=174731264
   [junit4]   2> NOTE: All tests run in this JVM: [TestVersion, 
TestQueryBuilder, TestSimpleSearchEquivalence, TestIndexWriterDeleteByQuery, 
TestCachingTokenFilter, TestReusableStringReader, TestSegmentInfos, 
TestParallelTermEnum, TestFieldValueFilter, TestSortRescorer, 
TestFlushByRamOrCountsPolicy, TestIndexWriterFromReader, TestOperations, 
TestCharTermAttributeImpl, TestTryDelete, TestField, Test2BNumericDocValues, 
TestStressIndexing2, LimitedFiniteStringsIteratorTest, TestIndexWriterDelete, 
TestDocsAndPositions, TestArrayUtil, TestPackedTokenAttributeImpl, 
TestHugeRamFile, TestPrefixCodedTerms, TestNumericDocValuesUpdates, 
TestComplexExplanations, TestDefaultSimilarity, TestIndexFileDeleter, 
TestDocumentsWriterDeleteQueue, TestSparseFixedBitDocIdSet, 
TestIndexWriterThreadsToSegments, TestSimpleExplanationsOfNonMatches, 
TestFrequencyTrackingRingBuffer, TestIndexInput, 
TestBooleanQueryVisitSubscorers, TestSingleInstanceLockFactory, TestTerms, 
TestPayloadsOnVectors, TestDirectPacked, TestMultiPhraseQuery, 
TestSloppyPhraseQuery2, TestCodecUtil, TestBasics, 
TestLucene50StoredFieldsFormat, TestMmapDirectory, TestPerFieldPostingsFormat, 
TestCloseableThreadLocal, TestFilterLeafReader, TestIndexWriterNRTIsCurrent, 
TestIndexWriterOnVMError, TestBooleanRewrites, TestLSBRadixSorter, 
TestDeletionPolicy, TestTopDocsMerge, TestIndexWriterUnicode, 
TestParallelCompositeReader, TestOmitPositions, TestSimilarityBase, 
TestLucene50TermVectorsFormat, TestEarlyTermination, 
Test2BSortedDocValuesFixedSorted, TestTermVectorsWriter, 

Feature list of Lucene 5

[Thomas Pan]

Hi,

Where can I find the feature list with features introduced between Lucene
4.5 and Lucene 5?


Best,
Thomas


--
The journey of a thousand miles begins with one step. -- Lao Tzu
Do not go where the path may lead, go instead where there is no path and
leave a trail. -- Ralph Waldo Emerson

[jira] [Closed] (SOLR-8865) real-time get does not retrieve values from docValues

[Yonik Seeley (JIRA)]

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

Yonik Seeley closed SOLR-8865.
--

> real-time get does not retrieve values from docValues
> -
>
> Key: SOLR-8865
> URL: https://issues.apache.org/jira/browse/SOLR-8865
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Blocker
> Fix For: 6.0, 5.5.1, 5.6
>
> Attachments: SOLR-8865.patch, SOLR-8865.patch, SOLR-8865.patch, 
> SOLR-8865.patch, SOLR-8865.patch, SOLR-8865.patch
>
>
> Uncovered during ad-hoc testing... the _version_ field, which has 
> stored=false docValues=true is not retrieved with realtime-get



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

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

[jira] [Closed] (SOLR-8891) StrField issues with docValues

[Yonik Seeley (JIRA)]

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

Yonik Seeley closed SOLR-8891.
--

> StrField issues with docValues
> --
>
> Key: SOLR-8891
> URL: https://issues.apache.org/jira/browse/SOLR-8891
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 6.0, 5.5.1, 5.6
>
> Attachments: SOLR-8891.patch
>
>
> - StrField.toObject and toExternal don't work with docValue IndexableField 
> instances
> - StrField.createFields needlessly adds nulls to the list of returned 
> IndexableFields (not strictly a bug, but not needed), and creates an 
> arraylist that is bigger than needed.



--
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-8865) real-time get does not retrieve values from docValues

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-8865:
---
Fix Version/s: 5.6
   5.5.1

> real-time get does not retrieve values from docValues
> -
>
> Key: SOLR-8865
> URL: https://issues.apache.org/jira/browse/SOLR-8865
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Blocker
> Fix For: 6.0, 5.5.1, 5.6
>
> Attachments: SOLR-8865.patch, SOLR-8865.patch, SOLR-8865.patch, 
> SOLR-8865.patch, SOLR-8865.patch, SOLR-8865.patch
>
>
> Uncovered during ad-hoc testing... the _version_ field, which has 
> stored=false docValues=true is not retrieved with realtime-get



--
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-8891) StrField issues with docValues

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-8891:
---
Fix Version/s: 5.6
   5.5.1

> StrField issues with docValues
> --
>
> Key: SOLR-8891
> URL: https://issues.apache.org/jira/browse/SOLR-8891
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 6.0, 5.5.1, 5.6
>
> Attachments: SOLR-8891.patch
>
>
> - StrField.toObject and toExternal don't work with docValue IndexableField 
> instances
> - StrField.createFields needlessly adds nulls to the list of returned 
> IndexableFields (not strictly a bug, but not needed), and creates an 
> arraylist that is bigger than needed.



--
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-8865) real-time get does not retrieve values from docValues

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8865:
---

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

SOLR-8865: Real-time get sometimes fails to retrieve stored fields from 
docValues


> real-time get does not retrieve values from docValues
> -
>
> Key: SOLR-8865
> URL: https://issues.apache.org/jira/browse/SOLR-8865
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Blocker
> Fix For: 6.0
>
> Attachments: SOLR-8865.patch, SOLR-8865.patch, SOLR-8865.patch, 
> SOLR-8865.patch, SOLR-8865.patch, SOLR-8865.patch
>
>
> Uncovered during ad-hoc testing... the _version_ field, which has 
> stored=false docValues=true is not retrieved with realtime-get



--
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: Lucene/Solr 5.5.1

[Steve Rowe]

Anshum,

FYI, I finished backporting SOLR-8082.

--
Steve
www.lucidworks.com

> On Apr 27, 2016, at 6:58 PM, Anshum Gupta  wrote:
> 
> FYI, I'll wait until Uwe commits SOLR-9046 and then have the RC out.
> 
> On Wed, Apr 27, 2016 at 1:08 PM, Anshum Gupta  wrote:
> Thanks for clarifying Steve. I'll try it out when I'm ready. There are still 
> 2 issues I'm waiting on.
> 
> 
> On Wed, Apr 27, 2016 at 12:55 PM, Steve Rowe  wrote:
> So the general idea is to add the version-to-be-released on every branch from 
> which a version will likely be cut in the future.  In this case that includes 
> 5_5, 5x, 6_0, 6x, and master.
> 
> I think you should run addVersion.py on 6_0, since a 6.0.1 release seems 
> quite likely, but the script itself may need changes to make that work.
> 
> And I think you’re right: there are two stable branches: 5x and 6x.  There 
> should be no problem on 5x, but again, 6x may require script changes to make 
> it work.
> 
> Sorry I can’t be more specific; you’re treading new ground here.
> 
> --
> Steve
> www.lucidworks.com
> 
> > On Apr 27, 2016, at 3:18 PM, Anshum Gupta  wrote:
> >
> > I looked at it Steve but it's unclear in cases of release like this one 
> > i.e. 5x release going out when 6.0 is already out.
> > The stable branch as per definition is 6x (and I guess 5x?).
> >
> > On Wed, Apr 27, 2016 at 11:43 AM, Steve Rowe  wrote:
> > Anshum,
> >
> > Have you seen 
> > https://wiki.apache.org/lucene-java/ReleaseTodo#Update_Version_Numbers_in_the_Source_Code
> >  ?
> >
> > --
> > Steve
> > www.lucidworks.com
> >
> > > On Apr 27, 2016, at 2:33 PM, Anshum Gupta  wrote:
> > >
> > > Can someone confirm the steps to update version numbers in source code 
> > > for the 5.5.1 release? Here's my understanding:
> > > * on branch_5_5: addVersion.py 5.5.1
> > > * Using the commit id from previous step, run addVersion.py on branch_5x
> > >
> > > * Should we also be running this on master, 6x, and 6.0  branches?
> > >
> > >
> > > On Wed, Apr 27, 2016 at 11:28 AM, Anshum Gupta  
> > > wrote:
> > > Hi Steve,
> > >
> > > Yes, I missed the JIRA comment. Do you want to take it up?
> > >
> > > On Wed, Apr 27, 2016 at 9:08 AM, Steve Rowe  wrote:
> > > Anshum, is it okay to backport SOLR-8082 to 5.5.1? - Steve
> > >
> > > > On Apr 27, 2016, at 11:46 AM, Anshum Gupta  
> > > > wrote:
> > > >
> > > > Thanks Yonik. I'll wait for this.
> > > >
> > > > On Tue, Apr 26, 2016 at 9:42 PM, Yonik Seeley  wrote:
> > > > On Tue, Apr 26, 2016 at 11:57 PM, Anshum Gupta  
> > > > wrote:
> > > > > Hey Tim, Sorry about going slow but there were a ton of back-ports.
> > > > > I'm just waiting on Yonik or someone else who understands things 
> > > > > better to
> > > > > back-port SOLR-8886
> > > >
> > > > Ha, I saw that scroll past. but didn't realize I was being pinged.
> > > > I'll take a look at it tomorrow.
> > > >
> > > > -Yonik
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Anshum Gupta
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > >
> > >
> > >
> > >
> > > --
> > > Anshum Gupta
> > >
> > >
> > >
> > > --
> > > Anshum Gupta
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
> >
> >
> >
> > --
> > Anshum Gupta
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> 
> 
> 
> -- 
> Anshum Gupta
> 
> 
> 
> -- 
> Anshum Gupta


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

[jira] [Commented] (SOLR-8891) StrField issues with docValues

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8891:
---

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

SOLR-8891: Fix StrField.toObject and toExternal to work with docValue 
IndexableField instances, optimize createFields


> StrField issues with docValues
> --
>
> Key: SOLR-8891
> URL: https://issues.apache.org/jira/browse/SOLR-8891
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 6.0
>
> Attachments: SOLR-8891.patch
>
>
> - StrField.toObject and toExternal don't work with docValue IndexableField 
> instances
> - StrField.createFields needlessly adds nulls to the list of returned 
> IndexableFields (not strictly a bug, but not needed), and creates an 
> arraylist that is bigger than needed.



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

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

[jira] [Resolved] (SOLR-8082) can't query against negative float or double values when indexed="false" docValues="true" multiValued="false"

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-8082.
--
   Resolution: Fixed
Fix Version/s: 5.6
   5.5.1

In backporting to branch_5x I had to convert some lambdas to functors (for 
Java7), and was all ready to push, but when I pulled and got Yonik’s SOLR-8886 
changes, there were conflicts, and attempts at merging brought in a shitload of 
extraneous crap, so I changed strategies: I applied the commit diffs from the 
two master commits on this issue with {{patch}} and fixed up the rejects 
manually.

> can't query against negative float or double values when indexed="false" 
> docValues="true" multiValued="false"
> -
>
> Key: SOLR-8082
> URL: https://issues.apache.org/jira/browse/SOLR-8082
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: master, 6.0, 5.5.1, 6.1, 5.6
>
> Attachments: SOLR-8082.patch, SOLR-8082.patch, SOLR-8082.patch, 
> SOLR-8082.patch, SOLR-8082.patch, SOLR-8082.patch, SOLR-8082.patch, 
> SOLR-8082.patch
>
>
> Haven't dug into this yet, but something is evidently wrong in how the 
> DocValues based queries get build for single valued float or double fields 
> when negative numbers are involved.
> Steps to reproduce...
> {noformat}
> $ bin/solr -e schemaless -noprompt
> ...
> $ curl -X POST -H 'Content-type:application/json' --data-binary '{ 
> "add-field":{ "name":"f_dv_multi", "type":"tfloat", "stored":"true", 
> "indexed":"false", "docValues":"true", "multiValued":"true" }, "add-field":{ 
> "name":"f_dv_single", "type":"tfloat", "stored":"true", "indexed":"false", 
> "docValues":"true", "multiValued":"false" } }' 
> http://localhost:8983/solr/gettingstarted/schema
> {
>   "responseHeader":{
> "status":0,
> "QTime":84}}
> $ curl -X POST -H 'Content-type:application/json' --data-binary 
> '[{"id":"test", "f_dv_multi":-4.3, "f_dv_single":-4.3}]' 
> 'http://localhost:8983/solr/gettingstarted/update/json/docs?commit=true'
> {"responseHeader":{"status":0,"QTime":57}}
> $ curl 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_multi:"-4.3;'
> {
>   "responseHeader":{
> "status":0,
> "QTime":5,
> "params":{
>   "q":"f_dv_multi:\"-4.3\""}},
>   "response":{"numFound":1,"start":0,"docs":[
>   {
> "id":"test",
> "f_dv_multi":[-4.3],
> "f_dv_single":-4.3,
> "_version_":1512962117004689408}]
>   }}
> $ curl 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_single:"-4.3;'
> {
>   "responseHeader":{
> "status":0,
> "QTime":5,
> "params":{
>   "q":"f_dv_single:\"-4.3\""}},
>   "response":{"numFound":0,"start":0,"docs":[]
>   }}
> {noformat}
> Explicit range queries (which is how numeric "field" queries are implemented 
> under the cover) are equally problematic...
> {noformat}
> $ curl 
> 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_multi:%5B-4.3+TO+-4.3%5D'
> {
>   "responseHeader":{
> "status":0,
> "QTime":0,
> "params":{
>   "q":"f_dv_multi:[-4.3 TO -4.3]"}},
>   "response":{"numFound":1,"start":0,"docs":[
>   {
> "id":"test",
> "f_dv_multi":[-4.3],
> "f_dv_single":-4.3,
> "_version_":1512962117004689408}]
>   }}
> $ curl 
> 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_single:%5B-4.3+TO+-4.3%5D'
> {
>   "responseHeader":{
> "status":0,
> "QTime":0,
> "params":{
>   "q":"f_dv_single:[-4.3 TO -4.3]"}},
>   "response":{"numFound":0,"start":0,"docs":[]
>   }}
> {noformat}



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

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

[jira] [Commented] (SOLR-8082) can't query against negative float or double values when indexed="false" docValues="true" multiValued="false"

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8082:
---

Commit f0f9081e345030dd8946fb0141b4315c193a88ce in lucene-solr's branch 
refs/heads/branch_5_5 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f0f9081 ]

SOLR-8082: Can't query against negative float or double values when 
indexed='false' docValues='true' multiValued='false'


> can't query against negative float or double values when indexed="false" 
> docValues="true" multiValued="false"
> -
>
> Key: SOLR-8082
> URL: https://issues.apache.org/jira/browse/SOLR-8082
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: master, 6.0, 5.5.1, 6.1, 5.6
>
> Attachments: SOLR-8082.patch, SOLR-8082.patch, SOLR-8082.patch, 
> SOLR-8082.patch, SOLR-8082.patch, SOLR-8082.patch, SOLR-8082.patch, 
> SOLR-8082.patch
>
>
> Haven't dug into this yet, but something is evidently wrong in how the 
> DocValues based queries get build for single valued float or double fields 
> when negative numbers are involved.
> Steps to reproduce...
> {noformat}
> $ bin/solr -e schemaless -noprompt
> ...
> $ curl -X POST -H 'Content-type:application/json' --data-binary '{ 
> "add-field":{ "name":"f_dv_multi", "type":"tfloat", "stored":"true", 
> "indexed":"false", "docValues":"true", "multiValued":"true" }, "add-field":{ 
> "name":"f_dv_single", "type":"tfloat", "stored":"true", "indexed":"false", 
> "docValues":"true", "multiValued":"false" } }' 
> http://localhost:8983/solr/gettingstarted/schema
> {
>   "responseHeader":{
> "status":0,
> "QTime":84}}
> $ curl -X POST -H 'Content-type:application/json' --data-binary 
> '[{"id":"test", "f_dv_multi":-4.3, "f_dv_single":-4.3}]' 
> 'http://localhost:8983/solr/gettingstarted/update/json/docs?commit=true'
> {"responseHeader":{"status":0,"QTime":57}}
> $ curl 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_multi:"-4.3;'
> {
>   "responseHeader":{
> "status":0,
> "QTime":5,
> "params":{
>   "q":"f_dv_multi:\"-4.3\""}},
>   "response":{"numFound":1,"start":0,"docs":[
>   {
> "id":"test",
> "f_dv_multi":[-4.3],
> "f_dv_single":-4.3,
> "_version_":1512962117004689408}]
>   }}
> $ curl 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_single:"-4.3;'
> {
>   "responseHeader":{
> "status":0,
> "QTime":5,
> "params":{
>   "q":"f_dv_single:\"-4.3\""}},
>   "response":{"numFound":0,"start":0,"docs":[]
>   }}
> {noformat}
> Explicit range queries (which is how numeric "field" queries are implemented 
> under the cover) are equally problematic...
> {noformat}
> $ curl 
> 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_multi:%5B-4.3+TO+-4.3%5D'
> {
>   "responseHeader":{
> "status":0,
> "QTime":0,
> "params":{
>   "q":"f_dv_multi:[-4.3 TO -4.3]"}},
>   "response":{"numFound":1,"start":0,"docs":[
>   {
> "id":"test",
> "f_dv_multi":[-4.3],
> "f_dv_single":-4.3,
> "_version_":1512962117004689408}]
>   }}
> $ curl 
> 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_single:%5B-4.3+TO+-4.3%5D'
> {
>   "responseHeader":{
> "status":0,
> "QTime":0,
> "params":{
>   "q":"f_dv_single:[-4.3 TO -4.3]"}},
>   "response":{"numFound":0,"start":0,"docs":[]
>   }}
> {noformat}



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

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

[jira] [Commented] (SOLR-8891) StrField issues with docValues

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8891:
---

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

SOLR-8891: Fix StrField.toObject and toExternal to work with docValue 
IndexableField instances, optimize createFields


> StrField issues with docValues
> --
>
> Key: SOLR-8891
> URL: https://issues.apache.org/jira/browse/SOLR-8891
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 6.0
>
> Attachments: SOLR-8891.patch
>
>
> - StrField.toObject and toExternal don't work with docValue IndexableField 
> instances
> - StrField.createFields needlessly adds nulls to the list of returned 
> IndexableFields (not strictly a bug, but not needed), and creates an 
> arraylist that is bigger than needed.



--
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-8865) real-time get does not retrieve values from docValues

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8865:
---

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

SOLR-8865: Real-time get sometimes fails to retrieve stored fields from 
docValues


> real-time get does not retrieve values from docValues
> -
>
> Key: SOLR-8865
> URL: https://issues.apache.org/jira/browse/SOLR-8865
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Blocker
> Fix For: 6.0
>
> Attachments: SOLR-8865.patch, SOLR-8865.patch, SOLR-8865.patch, 
> SOLR-8865.patch, SOLR-8865.patch, SOLR-8865.patch
>
>
> Uncovered during ad-hoc testing... the _version_ field, which has 
> stored=false docValues=true is not retrieved with realtime-get



--
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-8715) New Admin UI's Schema screen fails for some fields

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-8715:
-

Is there anything else we need for this one? Would be nice if it could be 
pushed into 5.5.1 as well, given how trivial the fix is.

> New Admin UI's Schema screen fails for some fields
> --
>
> Key: SOLR-8715
> URL: https://issues.apache.org/jira/browse/SOLR-8715
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 5.5, 6.0
> Environment: mac, firefox
>Reporter: Alexandre Rafalovitch
>Assignee: Upayavira
>  Labels: admin-interface
> Attachments: Problem shown in the released 5.5 version.png
>
>
> In techproducts example, using new Admin UI and trying to load the Schema for 
> text field causes blank screen and the Javascript error in the developer 
> console:
> {noformat}
> Error: row.flags is undefined
> getFieldProperties@http://localhost:8983/solr/js/angular/controllers/schema.js:482:40
> $scope.refresh/http://localhost:8983/solr/js/angular/controllers/schema.js:76:38
> 
> {noformat}
> Tested with 5.5rc3



--
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-8082) can't query against negative float or double values when indexed="false" docValues="true" multiValued="false"

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8082:
---

Commit 79636a73fc1543fa69bdc5081f3fb20e108fce75 in lucene-solr's branch 
refs/heads/branch_5x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=79636a7 ]

SOLR-8082: Can't query against negative float or double values when 
indexed='false' docValues='true' multiValued='false'


> can't query against negative float or double values when indexed="false" 
> docValues="true" multiValued="false"
> -
>
> Key: SOLR-8082
> URL: https://issues.apache.org/jira/browse/SOLR-8082
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: master, 6.0, 6.1
>
> Attachments: SOLR-8082.patch, SOLR-8082.patch, SOLR-8082.patch, 
> SOLR-8082.patch, SOLR-8082.patch, SOLR-8082.patch, SOLR-8082.patch, 
> SOLR-8082.patch
>
>
> Haven't dug into this yet, but something is evidently wrong in how the 
> DocValues based queries get build for single valued float or double fields 
> when negative numbers are involved.
> Steps to reproduce...
> {noformat}
> $ bin/solr -e schemaless -noprompt
> ...
> $ curl -X POST -H 'Content-type:application/json' --data-binary '{ 
> "add-field":{ "name":"f_dv_multi", "type":"tfloat", "stored":"true", 
> "indexed":"false", "docValues":"true", "multiValued":"true" }, "add-field":{ 
> "name":"f_dv_single", "type":"tfloat", "stored":"true", "indexed":"false", 
> "docValues":"true", "multiValued":"false" } }' 
> http://localhost:8983/solr/gettingstarted/schema
> {
>   "responseHeader":{
> "status":0,
> "QTime":84}}
> $ curl -X POST -H 'Content-type:application/json' --data-binary 
> '[{"id":"test", "f_dv_multi":-4.3, "f_dv_single":-4.3}]' 
> 'http://localhost:8983/solr/gettingstarted/update/json/docs?commit=true'
> {"responseHeader":{"status":0,"QTime":57}}
> $ curl 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_multi:"-4.3;'
> {
>   "responseHeader":{
> "status":0,
> "QTime":5,
> "params":{
>   "q":"f_dv_multi:\"-4.3\""}},
>   "response":{"numFound":1,"start":0,"docs":[
>   {
> "id":"test",
> "f_dv_multi":[-4.3],
> "f_dv_single":-4.3,
> "_version_":1512962117004689408}]
>   }}
> $ curl 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_single:"-4.3;'
> {
>   "responseHeader":{
> "status":0,
> "QTime":5,
> "params":{
>   "q":"f_dv_single:\"-4.3\""}},
>   "response":{"numFound":0,"start":0,"docs":[]
>   }}
> {noformat}
> Explicit range queries (which is how numeric "field" queries are implemented 
> under the cover) are equally problematic...
> {noformat}
> $ curl 
> 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_multi:%5B-4.3+TO+-4.3%5D'
> {
>   "responseHeader":{
> "status":0,
> "QTime":0,
> "params":{
>   "q":"f_dv_multi:[-4.3 TO -4.3]"}},
>   "response":{"numFound":1,"start":0,"docs":[
>   {
> "id":"test",
> "f_dv_multi":[-4.3],
> "f_dv_single":-4.3,
> "_version_":1512962117004689408}]
>   }}
> $ curl 
> 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_single:%5B-4.3+TO+-4.3%5D'
> {
>   "responseHeader":{
> "status":0,
> "QTime":0,
> "params":{
>   "q":"f_dv_single:[-4.3 TO -4.3]"}},
>   "response":{"numFound":0,"start":0,"docs":[]
>   }}
> {noformat}



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

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

Re: Lucene/Solr 5.5.1

[Anshum Gupta]

FYI, I'll wait until Uwe commits SOLR-9046 and then have the RC out.

On Wed, Apr 27, 2016 at 1:08 PM, Anshum Gupta 
wrote:

> Thanks for clarifying Steve. I'll try it out when I'm ready. There are
> still 2 issues I'm waiting on.
>
>
> On Wed, Apr 27, 2016 at 12:55 PM, Steve Rowe  wrote:
>
>> So the general idea is to add the version-to-be-released on every branch
>> from which a version will likely be cut in the future.  In this case that
>> includes 5_5, 5x, 6_0, 6x, and master.
>>
>> I think you should run addVersion.py on 6_0, since a 6.0.1 release seems
>> quite likely, but the script itself may need changes to make that work.
>>
>> And I think you’re right: there are two stable branches: 5x and 6x.
>> There should be no problem on 5x, but again, 6x may require script changes
>> to make it work.
>>
>> Sorry I can’t be more specific; you’re treading new ground here.
>>
>> --
>> Steve
>> www.lucidworks.com
>>
>> > On Apr 27, 2016, at 3:18 PM, Anshum Gupta 
>> wrote:
>> >
>> > I looked at it Steve but it's unclear in cases of release like this one
>> i.e. 5x release going out when 6.0 is already out.
>> > The stable branch as per definition is 6x (and I guess 5x?).
>> >
>> > On Wed, Apr 27, 2016 at 11:43 AM, Steve Rowe  wrote:
>> > Anshum,
>> >
>> > Have you seen
>> https://wiki.apache.org/lucene-java/ReleaseTodo#Update_Version_Numbers_in_the_Source_Code
>> ?
>> >
>> > --
>> > Steve
>> > www.lucidworks.com
>> >
>> > > On Apr 27, 2016, at 2:33 PM, Anshum Gupta 
>> wrote:
>> > >
>> > > Can someone confirm the steps to update version numbers in source
>> code for the 5.5.1 release? Here's my understanding:
>> > > * on branch_5_5: addVersion.py 5.5.1
>> > > * Using the commit id from previous step, run addVersion.py on
>> branch_5x
>> > >
>> > > * Should we also be running this on master, 6x, and 6.0  branches?
>> > >
>> > >
>> > > On Wed, Apr 27, 2016 at 11:28 AM, Anshum Gupta <
>> ans...@anshumgupta.net> wrote:
>> > > Hi Steve,
>> > >
>> > > Yes, I missed the JIRA comment. Do you want to take it up?
>> > >
>> > > On Wed, Apr 27, 2016 at 9:08 AM, Steve Rowe  wrote:
>> > > Anshum, is it okay to backport SOLR-8082 to 5.5.1? - Steve
>> > >
>> > > > On Apr 27, 2016, at 11:46 AM, Anshum Gupta 
>> wrote:
>> > > >
>> > > > Thanks Yonik. I'll wait for this.
>> > > >
>> > > > On Tue, Apr 26, 2016 at 9:42 PM, Yonik Seeley 
>> wrote:
>> > > > On Tue, Apr 26, 2016 at 11:57 PM, Anshum Gupta <
>> ans...@anshumgupta.net> wrote:
>> > > > > Hey Tim, Sorry about going slow but there were a ton of
>> back-ports.
>> > > > > I'm just waiting on Yonik or someone else who understands things
>> better to
>> > > > > back-port SOLR-8886
>> > > >
>> > > > Ha, I saw that scroll past. but didn't realize I was being pinged.
>> > > > I'll take a look at it tomorrow.
>> > > >
>> > > > -Yonik
>> > > >
>> > > >
>> -
>> > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > > > For additional commands, e-mail: dev-h...@lucene.apache.org
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Anshum Gupta
>> > >
>> > >
>> > > -
>> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > > For additional commands, e-mail: dev-h...@lucene.apache.org
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > > Anshum Gupta
>> > >
>> > >
>> > >
>> > > --
>> > > Anshum Gupta
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>> >
>> >
>> >
>> > --
>> > Anshum Gupta
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
>
> --
> Anshum Gupta
>



-- 
Anshum Gupta

[jira] [Commented] (SOLR-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-9046:


Thanks Uwe. I believe you meant 5x and 5.5 instead of 5.0.

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Timothy Potter
> Fix For: 5.5.1
>
> Attachments: SOLR-9045.patch, SOLR-9046.patch, SOLR-9046.patch, 
> SOLR-9046.patch, SOLR-9046.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



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

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

[jira] [Resolved] (SOLR-9040) bin/solr SSL support for client->server communcation (as well as default SSL behavior in 'new HttpSolrClient(String)') broken on master

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-9040.

   Resolution: Fixed
Fix Version/s: master

> bin/solr SSL support for client->server communcation (as well as default SSL 
> behavior in 'new HttpSolrClient(String)') broken on master
> ---
>
> Key: SOLR-9040
> URL: https://issues.apache.org/jira/browse/SOLR-9040
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master
>
> Attachments: SOLR-9040.patch, SOLR-9040.patch
>
>
> Working on SOLR-9028 lead me to realize that {{bin/solr}} actions which 
> require communicating with solr over HTTP are broken on master when SSL is 
> enabled.  My testing suggests that this doesn't affect branch 6x or 6.0.
> (Long) detailed steps to reproduce to follow in first  comment
> Further investigation indicates this is a general problem with HTTP based 
> SolrClient initialization when standard {{javax.net.ssl.*}} sys properties 
> are expected to be used for initializing the underlying HTTP client 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] (SOLR-9040) bin/solr SSL support for client->server communcation (as well as default SSL behavior in 'new HttpSolrClient(String)') broken on master

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-9040:
---

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

SOLR-9040 / SOLR-4509: Fix default SchemaRegistryProvider so javax.net.ssl.* 
system properties are respected by default


> bin/solr SSL support for client->server communcation (as well as default SSL 
> behavior in 'new HttpSolrClient(String)') broken on master
> ---
>
> Key: SOLR-9040
> URL: https://issues.apache.org/jira/browse/SOLR-9040
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-9040.patch, SOLR-9040.patch
>
>
> Working on SOLR-9028 lead me to realize that {{bin/solr}} actions which 
> require communicating with solr over HTTP are broken on master when SSL is 
> enabled.  My testing suggests that this doesn't affect branch 6x or 6.0.
> (Long) detailed steps to reproduce to follow in first  comment
> Further investigation indicates this is a general problem with HTTP based 
> SolrClient initialization when standard {{javax.net.ssl.*}} sys properties 
> are expected to be used for initializing the underlying HTTP client 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] (SOLR-4509) Move to non deprecated HttpClient impl classes to remove stale connection check on every request and move connection lifecycle management towards the client.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-4509:
---

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

SOLR-9040 / SOLR-4509: Fix default SchemaRegistryProvider so javax.net.ssl.* 
system properties are respected by default


> Move to non deprecated HttpClient impl classes to remove stale connection 
> check on every request and move connection lifecycle management towards the 
> client.
> -
>
> Key: SOLR-4509
> URL: https://issues.apache.org/jira/browse/SOLR-4509
> Project: Solr
>  Issue Type: Improvement
> Environment: 5 node SmartOS cluster (all nodes living in same global 
> zone - i.e. same physical machine)
>Reporter: Ryan Zezeski
>Assignee: Mark Miller
>Priority: Minor
> Fix For: master
>
> Attachments: 
> 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, 
> 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, 
> 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, 
> 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, 
> 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, 
> 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, 
> IsStaleTime.java, SOLR-4509-4_4_0.patch, SOLR-4509.patch, SOLR-4509.patch, 
> SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, 
> SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, 
> baremetal-stale-nostale-med-latency.dat, 
> baremetal-stale-nostale-med-latency.svg, 
> baremetal-stale-nostale-throughput.dat, baremetal-stale-nostale-throughput.svg
>
>
> By disabling the Apache HTTP Client stale check I've witnessed a 2-4x 
> increase in throughput and reduction of over 100ms.  This patch was made in 
> the context of a project I'm leading, called Yokozuna, which relies on 
> distributed search.
> Here's the patch on Yokozuna: https://github.com/rzezeski/yokozuna/pull/26
> Here's a write-up I did on my findings: 
> http://www.zinascii.com/2013/solr-distributed-search-and-the-stale-check.html
> I'm happy to answer any questions or make changes to the patch to make it 
> acceptable.
> ReviewBoard: https://reviews.apache.org/r/28393/



--
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-8886) TrieField.toObject(IndexableField) can't handle docValues

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-8886:


Ah OK... yeah, I'll look into that and SOLR-8891

> TrieField.toObject(IndexableField) can't handle docValues
> -
>
> Key: SOLR-8886
> URL: https://issues.apache.org/jira/browse/SOLR-8886
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 6.0, 5.5.1
>
> Attachments: SOLR-8886.patch, SOLR-8886.patch
>
>
> multiValued docValues numeric fields currently use SortedSet for some reason, 
> but toObject throws an exception in that case.



--
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-master-Windows (64bit/jdk1.8.0_92) - Build # 5804 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/5804/
Java: 64bit/jdk1.8.0_92 -XX:+UseCompressedOops -XX:+UseParallelGC

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

Error Message:
Index: 0, Size: 0

Stack Trace:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at 
__randomizedtesting.SeedInfo.seed([B2CDAAABBE2C88D6:45BE44F378C42730]:0)
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1248)
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 java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11559 lines...]
   [junit4] Suite: org.apache.solr.handler.TestReplicationHandler
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (SOLR-8886) TrieField.toObject(IndexableField) can't handle docValues

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8886:


I meant, SOLR-8865. The one that was blocked by this particular issue.

> TrieField.toObject(IndexableField) can't handle docValues
> -
>
> Key: SOLR-8886
> URL: https://issues.apache.org/jira/browse/SOLR-8886
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 6.0, 5.5.1
>
> Attachments: SOLR-8886.patch, SOLR-8886.patch
>
>
> multiValued docValues numeric fields currently use SortedSet for some reason, 
> but toObject throws an exception in that case.



--
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-8886) TrieField.toObject(IndexableField) can't handle docValues

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-8886:


"Update JS lib versions"? I don't know anything about that one.

> TrieField.toObject(IndexableField) can't handle docValues
> -
>
> Key: SOLR-8886
> URL: https://issues.apache.org/jira/browse/SOLR-8886
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 6.0, 5.5.1
>
> Attachments: SOLR-8886.patch, SOLR-8886.patch
>
>
> multiValued docValues numeric fields currently use SortedSet for some reason, 
> but toObject throws an exception in that case.



--
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-8689) Solr 5/6 does not start with recent Verona builds of Java 9 because of version parsing issue

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated SOLR-8689:

Affects Version/s: 6.0

> Solr 5/6 does not start with recent Verona builds of Java 9 because of 
> version parsing issue
> 
>
> Key: SOLR-8689
> URL: https://issues.apache.org/jira/browse/SOLR-8689
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.5, master, 6.0
> Environment: Windows 7
>Reporter: Uwe Schindler
>  Labels: Java9
>
> At least on Windows, Solr 5.5 does not start with the shell script using a 
> Verona-Java-9 JDK:
> {noformat}
> *
> JAVA_HOME = C:\Program Files\Java\jdk-9
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc)
> Java HotSpot(TM) 64-Bit Server VM (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc, mixed mode)
> *
> C:\Users\Uwe Schindler\Desktop\solr-5.5.0\bin>solr start
> ERROR: Java 1.7 or later is required to run Solr. Current Java version is: 
> 9-ea
> {noformat}
> I don't know if this is better with Linux, but I assume the version parsing 
> is broken (e.g., String#startsWith, interpret as floating point number,...)
> We should fix this before Java 9 gets released! The version numbering scheme 
> changed completely: http://openjdk.java.net/jeps/223



--
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-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9046:
-

I will now go to bed and I will commit this tomorrow morning to master, 6.x and 
5.0.

As I am now familar with the "FOR /F" logic, I may also be able to fix 
SOLR-8689.

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Timothy Potter
> Fix For: 5.5.1
>
> Attachments: SOLR-9045.patch, SOLR-9046.patch, SOLR-9046.patch, 
> SOLR-9046.patch, SOLR-9046.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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-9027) Add GraphTermsQuery to limit traversal on high frequency nodes

[Kevin Watters (JIRA)]

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

Kevin Watters commented on SOLR-9027:
-

Nice stuff Joel!  Just a thought, it might be nice to also provide a 
"maxDocFreq"  on the GraphTermsQuery...  relatively easy to add now, and it 
would allow graph traversal that ignore sparse edges...  

Either way, this is very cool,  It seems like this would be a natural 
enhancement for the GraphQuery when it builds the frontier.

> Add GraphTermsQuery to limit traversal on high frequency nodes
> --
>
> Key: SOLR-9027
> URL: https://issues.apache.org/jira/browse/SOLR-9027
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Priority: Minor
> Attachments: SOLR-9027.patch, SOLR-9027.patch, SOLR-9027.patch, 
> SOLR-9027.patch
>
>
> The gatherNodes() Streaming Expression is currently using a basic disjunction 
> query to perform the traversals. This ticket is to create a specific 
> GraphTermsQuery for performing the traversals. 
> The GraphTermsQuery will be based off of the TermsQuery, but will also 
> include an option for a docFreq cutoff. Terms that are above the docFreq 
> cutoff will not be included in the query. This will help users do a more 
> precise and efficient traversal.



--
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-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated SOLR-9046:

Attachment: SOLR-9046.patch

New patch. I missed to fix "solr -i" and the startup check. Now all usages are 
fixed.

I think it is ready. It would still be good if somebody would review the 
variable name disaster! :-)

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Timothy Potter
> Fix For: 5.5.1
>
> Attachments: SOLR-9045.patch, SOLR-9046.patch, SOLR-9046.patch, 
> SOLR-9046.patch, SOLR-9046.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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_92) - Build # 512 - Failure!

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test

Error Message:
Captured an uncaught exception in thread: Thread[id=4682, name=collection0, 
state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=4682, name=collection0, state=RUNNABLE, 
group=TGRP-CollectionsAPIDistributedZkTest]
at 
__randomizedtesting.SeedInfo.seed([DA339391C3A8918:85F706E3B2C6E4E0]:0)
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:42980: collection already exists: 
awholynewstresscollection_collection0_0
at __randomizedtesting.SeedInfo.seed([DA339391C3A8918]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:404)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:357)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1192)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1595)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1616)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:987)


FAILED:  org.apache.solr.handler.TestReplicationHandlerBackup.doTestBackup

Error Message:
expected:<1> but was:<2>

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([DA339391C3A8918:4C28195C3B847A57]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.handler.TestReplicationHandlerBackup.doTestBackup(TestReplicationHandlerBackup.java:245)
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 

[jira] [Commented] (SOLR-8297) Allow join query over 2 sharded collections: enhance functionality and exception handling

[Shikha Somani (JIRA)]

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

Shikha Somani commented on SOLR-8297:
-

We have been facing this issue and the point#B is main area of concern. We have 
identified it's fix. To work further I would like the defect to be assigned to 
me so I can provide it's patch for review.



> Allow join query over 2 sharded collections: enhance functionality and 
> exception handling
> -
>
> Key: SOLR-8297
> URL: https://issues.apache.org/jira/browse/SOLR-8297
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.3
>Reporter: Paul Blanchaert
>
> Enhancement based on SOLR-4905. New Jira issue raised as suggested by Mikhail 
> Khludnev.
> A) exception handling:
> The exception "SolrCloud join: multiple shards not yet supported" thrown in 
> the function findLocalReplicaForFromIndex of JoinQParserPlugin is not 
> triggered correctly: In my use-case, I've a join on a facet.query and when my 
> results are only found in 1 shard and the facet.query with the join is 
> querying the last replica of the last slice, then the exception is not thrown.
> I believe it's better to verify the nr of slices when we want to verify the  
> "multiple shards not yet supported" exception (so exception is thrown when 
> zkController.getClusterState().getSlices(fromIndex).size()>1).
> B) functional enhancement:
> I would expect that there is no problem to perform a cross-core join over 
> sharded collections when the following conditions are met:
> 1) both collections are sharded with the same replicationFactor and numShards
> 2) router.field of the collections is set to the same "key-field" (collection 
> of "fromindex" has router.field = "from" field and collection joined to has 
> router.field = "to" field)
> The router.field setup ensures that documents with the same "key-field" are 
> routed to the same node. 
> So the combination based on the "key-field" should always be available within 
> the same node.
> From a user perspective, I believe these assumptions seem to be a "normal" 
> use-case in the cross-core join in SolrCloud.
> Hope this helps



--
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-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9046:
-

Timothy, you wrote the original code - I think? Does it look correct for you? 
The "FOR /F" pattern with implicit variable names for tokens is just horrible 
:-) Whoever invented this syntax should be shot by the Unicode Policeman. :-)

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Timothy Potter
> Fix For: 5.5.1
>
> Attachments: SOLR-9045.patch, SOLR-9046.patch, SOLR-9046.patch, 
> SOLR-9046.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-9046:
--

[~thetaphi] do you want to commit this one to 5.5.1 for us? I picked it up to 
help out Anshum, but looks as though you have a better handle on the code 
changes and testing than I do ;-) If so please re-assign to yourself. Thanks.

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Timothy Potter
> Fix For: 5.5.1
>
> Attachments: SOLR-9045.patch, SOLR-9046.patch, SOLR-9046.patch, 
> SOLR-9046.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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-9028) fix bugs in (add sanity checks for) SSL clientAuth testing

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-9028:
---
Attachment: SOLR-9028.patch


Working on SOLR-9040 helped me discover some stuff about when/how exactly the 
JVM reads in the {{javax.net.ssl.*}} sys props to build the default 
{{SSLContext}} -- notably: it's a singleton, so we can't change the sysprops 
after startup and expect it to do what is expected.  (And there doesn't appear 
to be ably convinience classes/methods for loading a "custom" {{SSLContext}} 
that obeys those properties by default unless/until you override them)

In this updated patch, I've added test code to preserve the 
{{SSLContext.getDefault()}} on test class init, and use 
{{SSLContext.setDefaul()}} during testing to _mimic_ the effects of how the JVM 
should behave if the corisponding {{javax.net.ssl.*}} properties had been set. 
(then restore the preserved default in an {{@After}} method)

This seems to be working well.

I briefly considered eliminating all of the explicit modifications of 
HttpCiientUtil's HttpClientBuilder / SchemaRegistryProvider in these tests, so 
we were always mimicing how a solrj code will behave by default when these 
props are set, but ultimately I think the current mix of both styles of getting 
an SSLContext are better -- it helps us test both the "solrj client expects to 
use standard javax sys properties" approach, and the "solrj client code 
explicitly using HttpCiientUtil to say 'use these options for ssl'" approach.

There's still a handful of nocommits, that fall into two categories:
* I want to cleanup some of the SSLTestConfig methods that only exist in master 
and have weird side effects (introduced in SOLR-4509)
* I think it might makes sense to promote the the 
SSLContext.getDefault/setDefault preservation to SolrTestCaseJ4 ... but i'm not 
100% certain yet.  Need to think it through more.



> fix bugs in (add sanity checks for) SSL clientAuth testing
> --
>
> Key: SOLR-9028
> URL: https://issues.apache.org/jira/browse/SOLR-9028
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-9028.patch, SOLR-9028.patch, SOLR-9028.patch, 
> SOLR-9028.patch, SOLR-9028.patch, os.x.failure.txt
>
>
> While looking into SOLR-8970 i realized there was a whole heap of problems 
> with how clientAuth was being handled in tests.  Notably: it wasn't actaully 
> being used when the randomization selects it (aparently due to a copy/paste 
> mistake in SOLR-7166).  But there are few other misc issues (improper usage 
> of sysprops overrides for tests, missuage of keystore/truststore in test 
> clients, etc..)
> I'm working up a patch to fix all of this, and add some much needed tests to 
> *explicitly* verify both SSL and clientAuth that will include some "false 
> positive" verifications, and some "test the test" checks.



--
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-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated SOLR-9046:

Attachment: SOLR-9046.patch

Small documentation updates.

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Timothy Potter
> Fix For: 5.5.1
>
> Attachments: SOLR-9045.patch, SOLR-9046.patch, SOLR-9046.patch, 
> SOLR-9046.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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-9040) bin/solr SSL support for client->server communcation (as well as default SSL behavior in 'new HttpSolrClient(String)') broken on master

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-9040:
---
Attachment: SOLR-9040.patch


Ok, so the underlying problem with the old patch was that 
PoolingHttpClientConnectionManager's default behavior is to use 
{{SSLConnectionSocketFactory.getSocketFactory()}} which uses 
{{SSLContexts.createDefault()}} under the hood.  
{{SSLContexts.createDefault()}} constructs an explicit SSLCOntext that ignores 
any system properties.

Instead we want {{SSLConnectionSocketFactory.getSystemSocketFactory()}}, which 
does pay attention to some sys properties directly, and usees the standard 
{{SSLSocketFactory.getDefault()}} under the hood -- ensuring that the 
{{javax.net.ssl.*}} system properties are also respected.

The only problem is that the way {{SSLSocketFactory.getDefault()}} works 
involves using {{SSLContext.getDefault()}}, which loads the deafault SSLContext 
(and reads the system properties) only once and then treats it as a singleton 
-- making it a bit tricky to actually unit test diff sys prop options after the 
JVM has already started.

I'll comment more on this in SOLR-9028 where it makes more sense.

in any case, here's a patch that seems to fix {{bin/solr}} (and any {{new 
HttpSolrClient(String)}} usage that expects the various SSL sys props to affect 
the keystore/truststore).

I've punted on the earlier questions i raised about the 
{{SchemaRegistryProvider}} API -- I'll leave it to mark to decide if he thinks 
it's worth opening an issue to improve this.


> bin/solr SSL support for client->server communcation (as well as default SSL 
> behavior in 'new HttpSolrClient(String)') broken on master
> ---
>
> Key: SOLR-9040
> URL: https://issues.apache.org/jira/browse/SOLR-9040
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-9040.patch, SOLR-9040.patch
>
>
> Working on SOLR-9028 lead me to realize that {{bin/solr}} actions which 
> require communicating with solr over HTTP are broken on master when SSL is 
> enabled.  My testing suggests that this doesn't affect branch 6x or 6.0.
> (Long) detailed steps to reproduce to follow in first  comment
> Further investigation indicates this is a general problem with HTTP based 
> SolrClient initialization when standard {{javax.net.ssl.*}} sys properties 
> are expected to be used for initializing the underlying HTTP client 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-7258) Tune DocIdSetBuilder allocation rate

[Jeff Wartes (JIRA)]

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

Jeff Wartes commented on LUCENE-7258:
-

I'd be interested in trying TimSort, or something like [~yo...@apache.org] 
suggested where an ExpandingIntArray-style array of arrays is fed directly into 
the Radix sort, but I'm not sure I'm going to be able to commit much more time 
to this for a bit.

That said, in the process of thinking about this, I do have a few git stashes 
saved off with sketches for things like using TimSort and using 
ExpandingIntArray that I could try to clean and post if anyone is interested. 

I also have one sketch I started for using a loose pool mechanism to front 
acquiring a FixedBitSet, but I didn't get deep enough to be able to tell with 
confidence that a FBS was actually not being used anymore. Things like the 
public FixedBitSet.getBits() method make it scary, although I'm convinced even 
a very small pool of large FixedBitSets could be extremely advantageous. There 
aren't that many in use at any given time, and a large FBS can still be used 
for a small use-case. If anyone has some pointers around the lifecycle here, 
I'd love to hear them.

> Tune DocIdSetBuilder allocation rate
> 
>
> Key: LUCENE-7258
> URL: https://issues.apache.org/jira/browse/LUCENE-7258
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Reporter: Jeff Wartes
> Attachments: 
> LUCENE-7258-Tune-memory-allocation-rate-for-Intersec.patch, 
> LUCENE-7258-Tune-memory-allocation-rate-for-Intersec.patch, 
> allocation_plot.jpg
>
>
> LUCENE-7211 converted IntersectsPrefixTreeQuery to use DocIdSetBuilder, but 
> didn't actually reduce garbage generation for my Solr index.
> Since something like 40% of my garbage (by space) is now attributed to 
> DocIdSetBuilder.growBuffer, I charted a few different allocation strategies 
> to see if I could tune things more. 
> See here: http://i.imgur.com/7sXLAYv.jpg 
> The jump-then-flatline at the right would be where DocIdSetBuilder gives up 
> and allocates a FixedBitSet for a 100M-doc index. (The 1M-doc index 
> curve/cutoff looked similar)
> Perhaps unsurprisingly, the 1/8th growth factor in ArrayUtil.oversize is 
> terrible from an allocation standpoint if you're doing a lot of expansions, 
> and is especially terrible when used to build a short-lived data structure 
> like this one.
> By the time it goes with the FBS, it's allocated around twice as much memory 
> for the buffer as it would have needed for just the FBS.



--
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-9040) bin/solr SSL support for client->server communcation (as well as default SSL behavior in 'new HttpSolrClient(String)') broken on master

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-9040:
---
Description: 
Working on SOLR-9028 lead me to realize that {{bin/solr}} actions which require 
communicating with solr over HTTP are broken on master when SSL is enabled.  My 
testing suggests that this doesn't affect branch 6x or 6.0.

(Long) detailed steps to reproduce to follow in first  comment

Further investigation indicates this is a general problem with HTTP based 
SolrClient initialization when standard {{javax.net.ssl.*}} sys properties are 
expected to be used for initializing the underlying HTTP client code.

  was:
Working on SOLR-9028 lead me to realize that {{bin/solr}} actions which require 
communicating with solr over HTTP are broken on master when SSL is enabled.  My 
testing suggests that this doesn't affect branch 6x or 6.0.

(Long) detailed steps to reproduce to follow in first  comment

Summary: bin/solr SSL support for client->server communcation (as well 
as default SSL behavior in 'new HttpSolrClient(String)') broken on master  
(was: bin/solr SSL support for client->server communcation broken on master)

updating summary to note this isn't just a bin/solr problem, it affects any 
solrj code that expects standard {{javax.net.ssl.*}} properties to be used when 
SolrClient impls take responsibility for creating HttpClient instances.

> bin/solr SSL support for client->server communcation (as well as default SSL 
> behavior in 'new HttpSolrClient(String)') broken on master
> ---
>
> Key: SOLR-9040
> URL: https://issues.apache.org/jira/browse/SOLR-9040
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-9040.patch
>
>
> Working on SOLR-9028 lead me to realize that {{bin/solr}} actions which 
> require communicating with solr over HTTP are broken on master when SSL is 
> enabled.  My testing suggests that this doesn't affect branch 6x or 6.0.
> (Long) detailed steps to reproduce to follow in first  comment
> Further investigation indicates this is a general problem with HTTP based 
> SolrClient initialization when standard {{javax.net.ssl.*}} sys properties 
> are expected to be used for initializing the underlying HTTP client 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] [Comment Edited] (SOLR-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-9046 at 4/27/16 9:13 PM:
--

New patch that works with IPv6. The trick is actually a simplification: Instead 
of trying to split host name and port, we keep them together (so we spare one 
"FOR /F" and just compare the whole host:port token).

I tried with IPv4 addresses and IPv6 addresses and both variants "solr stop 
-all" and "solr stop -p 8983".


was (Author: thetaphi):
New patch that works with IPv6. The trick is actually a simplification. Instead 
of trying to split host name and port, we keep them together (so we spare one 
"FOR /F" and just compare the whole host:port token.

I tried with IPv4 addresses and IPv6 addresses and both variants "solr stop 
-all" and "solr stop -p 8983".

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Timothy Potter
> Fix For: 5.5.1
>
> Attachments: SOLR-9045.patch, SOLR-9046.patch, SOLR-9046.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated SOLR-9046:

Attachment: SOLR-9046.patch

New patch that works with IPv6. The trick is actually a simplification. Instead 
of trying to split host name and port, we keep them together (so we spare one 
"FOR /F" and just compare the whole host:port token.

I tried with IPv4 addresses and IPv6 addresses and both variants "solr stop 
-all" and "solr stop -p 8983".

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Timothy Potter
> Fix For: 5.5.1
>
> Attachments: SOLR-9045.patch, SOLR-9046.patch, SOLR-9046.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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-7258) Tune DocIdSetBuilder allocation rate

[Jeff Wartes (JIRA)]

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

Jeff Wartes updated LUCENE-7258:

Attachment: LUCENE-7258-Tune-memory-allocation-rate-for-Intersec.patch

After 24 hours, I found I could discern a penalty to cpu on my patched node. I 
removed the change in sort algorithm, and that seems to have resolved it 
without too significantly changing the allocation savings.

> Tune DocIdSetBuilder allocation rate
> 
>
> Key: LUCENE-7258
> URL: https://issues.apache.org/jira/browse/LUCENE-7258
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Reporter: Jeff Wartes
> Attachments: 
> LUCENE-7258-Tune-memory-allocation-rate-for-Intersec.patch, 
> LUCENE-7258-Tune-memory-allocation-rate-for-Intersec.patch, 
> allocation_plot.jpg
>
>
> LUCENE-7211 converted IntersectsPrefixTreeQuery to use DocIdSetBuilder, but 
> didn't actually reduce garbage generation for my Solr index.
> Since something like 40% of my garbage (by space) is now attributed to 
> DocIdSetBuilder.growBuffer, I charted a few different allocation strategies 
> to see if I could tune things more. 
> See here: http://i.imgur.com/7sXLAYv.jpg 
> The jump-then-flatline at the right would be where DocIdSetBuilder gives up 
> and allocates a FixedBitSet for a 100M-doc index. (The 1M-doc index 
> curve/cutoff looked similar)
> Perhaps unsurprisingly, the 1/8th growth factor in ArrayUtil.oversize is 
> terrible from an allocation standpoint if you're doing a lot of expansions, 
> and is especially terrible when used to build a short-lived data structure 
> like this one.
> By the time it goes with the FBS, it's allocated around twice as much memory 
> for the buffer as it would have needed for just the FBS.



--
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-Solaris (64bit/jdk1.8.0) - Build # 99 - Failure!

[Policeman Jenkins Server]

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

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

Error Message:
[/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_1ED0A6C51BD916E0-001/solr-instance-004/./collection1/data,
 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_1ED0A6C51BD916E0-001/solr-instance-004/./collection1/data/index.20160428050434986,
 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_1ED0A6C51BD916E0-001/solr-instance-004/./collection1/data/index.20160428050435137]
 expected:<2> but was:<3>

Stack Trace:
java.lang.AssertionError: 
[/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_1ED0A6C51BD916E0-001/solr-instance-004/./collection1/data,
 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_1ED0A6C51BD916E0-001/solr-instance-004/./collection1/data/index.20160428050434986,
 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_1ED0A6C51BD916E0-001/solr-instance-004/./collection1/data/index.20160428050435137]
 expected:<2> but was:<3>
at 
__randomizedtesting.SeedInfo.seed([1ED0A6C51BD916E0:E9A3489DDD31B906]: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:824)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1254)
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 

[jira] [Updated] (SOLR-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated SOLR-9046:

Attachment: SOLR-9046.patch

Here is the updated patch with the additional comment in solr.cmd.in.

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Timothy Potter
> Fix For: 5.5.1
>
> Attachments: SOLR-9045.patch, SOLR-9046.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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-5750) Backup/Restore API for SolrCloud

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-5750:


Ok please ignore the last point regarding the API naming. I see that we are 
already using BACKUP/RESTORE as API names...

> Backup/Restore API for SolrCloud
> 
>
> Key: SOLR-5750
> URL: https://issues.apache.org/jira/browse/SOLR-5750
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Varun Thacker
> Fix For: 5.2, master
>
> Attachments: SOLR-5750.patch, SOLR-5750.patch, SOLR-5750.patch, 
> SOLR-5750.patch, SOLR-5750.patch, SOLR-5750.patch, SOLR-5750.patch
>
>
> We should have an easy way to do backups and restores in SolrCloud. The 
> ReplicationHandler supports a backup command which can create snapshots of 
> the index but that is too little.
> The command should be able to backup:
> # Snapshots of all indexes or indexes from the leader or the shards
> # Config set
> # Cluster state
> # Cluster properties
> # Aliases
> # Overseer work queue?
> A restore should be able to completely restore the cloud i.e. no manual steps 
> required other than bringing nodes back up or setting up a new cloud cluster.
> SOLR-5340 will be a part of this issue.



--
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 (64bit/jdk-9-ea+115) - Build # 16597 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16597/
Java: 64bit/jdk-9-ea+115 -XX:+UseCompressedOops -XX:+UseParallelGC

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

Error Message:
Error from server at http://127.0.0.1:39923/solr/testschemaapi_shard1_replica1: 
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:39923/solr/testschemaapi_shard1_replica1: ERROR: 
[doc=2] unknown field 'myNewField1'
at 
__randomizedtesting.SeedInfo.seed([ADFDD54241CCA071:25A9EA98EF30CD89]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:661)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at 
org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:86)
at 
org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:55)
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:531)
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 

[jira] [Commented] (SOLR-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9046:
-

Otherwise patch looks OK. I just added a comment in solr.cmd.in to tell user to 
use IP address. Otherwise one may use "localhost" as SOLR_JETTY_HOST.

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Timothy Potter
> Fix For: 5.5.1
>
> Attachments: SOLR-9045.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9046:
-

The reason why it does not work is the way how it splits the port number from 
the address. It looks like this here:

{noformat}
  TCP[::1]:8983 [::]:0 LISTEN 5116
{noformat}

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Timothy Potter
> Fix For: 5.5.1
>
> Attachments: SOLR-9045.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



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

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

[jira] [Comment Edited] (SOLR-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-9046 at 4/27/16 8:28 PM:
--

OK status:
This works correct for starting up, but fails on stopping with Solr bound to 
IPv6 - it always tells you that it cannot find a process - I had to kill Solr 
on my own. The problem is the regular expression / find pattern. I'll try to 
fix it (first understand what Bram's changes around there mean).

Quick test is:
{noformat}
set SOLR_JETTY_HOST=[::1]
{noformat}

The Server starts up correctly and can be accessed with curl and web browser.


was (Author: thetaphi):
OK status:
This works correct for starting up, but fails on stopping with Solr bound to 
IPv6 - it always tells you that it cannot find a process - I had to kill Solr 
on my own. The problem is the regular expression / find pattern. I'll try to 
fix it (first understand what Bram's changes around there mean).

Quick test is:
{noformat}
set SOLR_JETTY_HOST=[::1]
{noformat}


> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Timothy Potter
> Fix For: 5.5.1
>
> Attachments: SOLR-9045.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9046:
-

OK status:
This works correct for starting up, but fails on stopping with Solr bound to 
IPv6 - it always tells you that it cannot find a process - I had to kill Solr 
on my own. The problem is the regular expression / find pattern. I'll try to 
fix it (first understand what Bram's changes around there mean).

Quick test is:
{noformat}
set SOLR_JETTY_HOST=[::1]
{noformat}


> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Timothy Potter
> Fix For: 5.5.1
>
> Attachments: SOLR-9045.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9046:
-

Hi,
I patched my checkout (master) locally. I am already testing (including all 
"bad" things like whitespace in path name). There are two thing that might not 
work - I am checking this, too:
- It assumes that JETTY_HOST is an ip address. You can always also give a 
hostname. It should be documented in the new solr.cmd.in, that you have to use 
an IP address
- It might not work with IPv6. As I am working in an IPv6 environment - IPv4 
works, but is not preferred here anymore, I will report on bugs, too.

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Timothy Potter
> Fix For: 5.5.1
>
> Attachments: SOLR-9045.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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-8792) ZooKeeper ACL not restricting access to zkcli

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-8792:


Maybe the boat has already sailed for 5.5.1, but I would still like to bring 
this issue to your attention, [~anshumg].
At this point, I think this issue to land in 5.5.1 looks difficult since this 
has not been reviewed yet, but I still believe this issue is critical enough to 
be fixed in some 5x version. 

> ZooKeeper ACL not restricting access to zkcli
> -
>
> Key: SOLR-8792
> URL: https://issues.apache.org/jira/browse/SOLR-8792
> Project: Solr
>  Issue Type: Bug
>  Components: Authentication, documentation
>Affects Versions: 5.0
>Reporter: Esther Quansah
>  Labels: acl, authentication, security, zkcli, zkcli.sh, zookeeper
> Fix For: 5.5.1, 6.1
>
> Attachments: SOLR-8792.patch
>
>
> The documentation presented here: 
> https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control
> details the process of securing Solr content in ZooKeeper using ACLs. In the 
> example usages, it is mentioned that access to zkcli can be restricted by 
> adding credentials to the zkcli.sh script in addition to adding the 
> appropriate classnames to solr.xml. With the scripts in zkcli.sh, another 
> machine should not be able to read or write from the host ZK without the 
> necessary credentials. At this time, machines are able to read/write from the 
> host ZK with or without these credentials.



--
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: Lucene/Solr 5.5.1

[Anshum Gupta]

Thanks for clarifying Steve. I'll try it out when I'm ready. There are
still 2 issues I'm waiting on.


On Wed, Apr 27, 2016 at 12:55 PM, Steve Rowe  wrote:

> So the general idea is to add the version-to-be-released on every branch
> from which a version will likely be cut in the future.  In this case that
> includes 5_5, 5x, 6_0, 6x, and master.
>
> I think you should run addVersion.py on 6_0, since a 6.0.1 release seems
> quite likely, but the script itself may need changes to make that work.
>
> And I think you’re right: there are two stable branches: 5x and 6x.  There
> should be no problem on 5x, but again, 6x may require script changes to
> make it work.
>
> Sorry I can’t be more specific; you’re treading new ground here.
>
> --
> Steve
> www.lucidworks.com
>
> > On Apr 27, 2016, at 3:18 PM, Anshum Gupta 
> wrote:
> >
> > I looked at it Steve but it's unclear in cases of release like this one
> i.e. 5x release going out when 6.0 is already out.
> > The stable branch as per definition is 6x (and I guess 5x?).
> >
> > On Wed, Apr 27, 2016 at 11:43 AM, Steve Rowe  wrote:
> > Anshum,
> >
> > Have you seen
> https://wiki.apache.org/lucene-java/ReleaseTodo#Update_Version_Numbers_in_the_Source_Code
> ?
> >
> > --
> > Steve
> > www.lucidworks.com
> >
> > > On Apr 27, 2016, at 2:33 PM, Anshum Gupta 
> wrote:
> > >
> > > Can someone confirm the steps to update version numbers in source code
> for the 5.5.1 release? Here's my understanding:
> > > * on branch_5_5: addVersion.py 5.5.1
> > > * Using the commit id from previous step, run addVersion.py on
> branch_5x
> > >
> > > * Should we also be running this on master, 6x, and 6.0  branches?
> > >
> > >
> > > On Wed, Apr 27, 2016 at 11:28 AM, Anshum Gupta 
> wrote:
> > > Hi Steve,
> > >
> > > Yes, I missed the JIRA comment. Do you want to take it up?
> > >
> > > On Wed, Apr 27, 2016 at 9:08 AM, Steve Rowe  wrote:
> > > Anshum, is it okay to backport SOLR-8082 to 5.5.1? - Steve
> > >
> > > > On Apr 27, 2016, at 11:46 AM, Anshum Gupta 
> wrote:
> > > >
> > > > Thanks Yonik. I'll wait for this.
> > > >
> > > > On Tue, Apr 26, 2016 at 9:42 PM, Yonik Seeley 
> wrote:
> > > > On Tue, Apr 26, 2016 at 11:57 PM, Anshum Gupta <
> ans...@anshumgupta.net> wrote:
> > > > > Hey Tim, Sorry about going slow but there were a ton of back-ports.
> > > > > I'm just waiting on Yonik or someone else who understands things
> better to
> > > > > back-port SOLR-8886
> > > >
> > > > Ha, I saw that scroll past. but didn't realize I was being pinged.
> > > > I'll take a look at it tomorrow.
> > > >
> > > > -Yonik
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Anshum Gupta
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > >
> > >
> > >
> > >
> > > --
> > > Anshum Gupta
> > >
> > >
> > >
> > > --
> > > Anshum Gupta
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
> >
> >
> >
> > --
> > Anshum Gupta
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
Anshum Gupta

[jira] [Commented] (SOLR-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-9046:


Thanks Tim!

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Timothy Potter
> Fix For: 5.5.1
>
> Attachments: SOLR-9045.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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: Lucene/Solr 5.5.1

[Steve Rowe]

So the general idea is to add the version-to-be-released on every branch from 
which a version will likely be cut in the future.  In this case that includes 
5_5, 5x, 6_0, 6x, and master.
 
I think you should run addVersion.py on 6_0, since a 6.0.1 release seems quite 
likely, but the script itself may need changes to make that work.

And I think you’re right: there are two stable branches: 5x and 6x.  There 
should be no problem on 5x, but again, 6x may require script changes to make it 
work.

Sorry I can’t be more specific; you’re treading new ground here.

--
Steve
www.lucidworks.com

> On Apr 27, 2016, at 3:18 PM, Anshum Gupta  wrote:
> 
> I looked at it Steve but it's unclear in cases of release like this one i.e. 
> 5x release going out when 6.0 is already out.
> The stable branch as per definition is 6x (and I guess 5x?).
> 
> On Wed, Apr 27, 2016 at 11:43 AM, Steve Rowe  wrote:
> Anshum,
> 
> Have you seen 
> https://wiki.apache.org/lucene-java/ReleaseTodo#Update_Version_Numbers_in_the_Source_Code
>  ?
> 
> --
> Steve
> www.lucidworks.com
> 
> > On Apr 27, 2016, at 2:33 PM, Anshum Gupta  wrote:
> >
> > Can someone confirm the steps to update version numbers in source code for 
> > the 5.5.1 release? Here's my understanding:
> > * on branch_5_5: addVersion.py 5.5.1
> > * Using the commit id from previous step, run addVersion.py on branch_5x
> >
> > * Should we also be running this on master, 6x, and 6.0  branches?
> >
> >
> > On Wed, Apr 27, 2016 at 11:28 AM, Anshum Gupta  
> > wrote:
> > Hi Steve,
> >
> > Yes, I missed the JIRA comment. Do you want to take it up?
> >
> > On Wed, Apr 27, 2016 at 9:08 AM, Steve Rowe  wrote:
> > Anshum, is it okay to backport SOLR-8082 to 5.5.1? - Steve
> >
> > > On Apr 27, 2016, at 11:46 AM, Anshum Gupta  wrote:
> > >
> > > Thanks Yonik. I'll wait for this.
> > >
> > > On Tue, Apr 26, 2016 at 9:42 PM, Yonik Seeley  wrote:
> > > On Tue, Apr 26, 2016 at 11:57 PM, Anshum Gupta  
> > > wrote:
> > > > Hey Tim, Sorry about going slow but there were a ton of back-ports.
> > > > I'm just waiting on Yonik or someone else who understands things better 
> > > > to
> > > > back-port SOLR-8886
> > >
> > > Ha, I saw that scroll past. but didn't realize I was being pinged.
> > > I'll take a look at it tomorrow.
> > >
> > > -Yonik
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > >
> > >
> > >
> > >
> > > --
> > > Anshum Gupta
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
> >
> >
> >
> > --
> > Anshum Gupta
> >
> >
> >
> > --
> > Anshum Gupta
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> 
> 
> 
> -- 
> Anshum Gupta


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

[jira] [Commented] (SOLR-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-9046:
--

I'll take up it [~anshumg] ... I'm spinning up a Windows box in EC2 today 
anyway.

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Timothy Potter
> Fix For: 5.5.1
>
> Attachments: SOLR-9045.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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] [Assigned] (SOLR-9046) solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0

[Timothy Potter (JIRA)]

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

Timothy Potter reassigned SOLR-9046:


Assignee: Timothy Potter

> solr.cmd wrongly assumes Jetty will always listen on 0.0.0.0
> 
>
> Key: SOLR-9046
> URL: https://issues.apache.org/jira/browse/SOLR-9046
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
> Environment: Windows
>Reporter: Bram Van Dam
>Assignee: Timothy Potter
> Fix For: 5.5.1
>
> Attachments: SOLR-9045.patch
>
>
> The Windows solr.cmd script makes the (incorrect) assumption that Solr will 
> always be listening on 0.0.0.0 (all interfaces). When you change the interface
> address, say to 127.0.0.1, then the status and stop commands will fail.
> This patch adds a property in solr.in.cmd, which is passed to SOLR_OPTS as 
> -Djetty.host, and replaces the instances of 0.0.0.0 in solr.cmd.
> The patch includes some changes in the netstat logic used in solr.cmd to find 
> the correct Solr process(es). 
> Tested on Solr 5.5 on Windows 7 and 10. 
> Note: Untested on Solr 6. Currently using Solr 5.5



--
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-8886) TrieField.toObject(IndexableField) can't handle docValues

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8886:


Thanks Yonik. Are you also looking at SOLR-8885 ?

> TrieField.toObject(IndexableField) can't handle docValues
> -
>
> Key: SOLR-8886
> URL: https://issues.apache.org/jira/browse/SOLR-8886
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 6.0, 5.5.1
>
> Attachments: SOLR-8886.patch, SOLR-8886.patch
>
>
> multiValued docValues numeric fields currently use SortedSet for some reason, 
> but toObject throws an exception in that case.



--
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: Lucene/Solr 5.5.1

[Anshum Gupta]

Hi Karthik,

I would like to have the fixes as part of 5.5.1 but I also wouldn't want to
block a release for non-critical open issues.

Both of those issues have no commits and I'm almost done with my back
ports. So, unless someone speaks about about actively working on these and
makes a case for this being a blocker, I'll continue with my 5.5.1 process
without including these.


On Wed, Apr 27, 2016 at 12:39 PM, Karthik Ramachandran <
kramachand...@commvault.com> wrote:

> Hey Anshum,
>
>
>
> Can you check if you can take SOLR-9034 for 5.5.1?
>
>
>
> Will SOLR-8812 make it for 5.5.1?
>
>
>
> With Thanks & Regards
> Karthik Ramachandran
> CommVault
> P Please don't print this e-mail unless you really need to
>
>
> ***Legal Disclaimer***
> "This communication may contain confidential and privileged material for the
> sole use of the intended recipient. Any unauthorized review, use or 
> distribution
> by others is strictly prohibited. If you have received the message by mistake,
> please advise the sender by reply email and delete the message. Thank you."
> **
>
>


-- 
Anshum Gupta

[jira] [Closed] (SOLR-8886) TrieField.toObject(IndexableField) can't handle docValues

[Yonik Seeley (JIRA)]

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

Yonik Seeley closed SOLR-8886.
--
   Resolution: Fixed
Fix Version/s: 5.5.1

> TrieField.toObject(IndexableField) can't handle docValues
> -
>
> Key: SOLR-8886
> URL: https://issues.apache.org/jira/browse/SOLR-8886
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 6.0, 5.5.1
>
> Attachments: SOLR-8886.patch, SOLR-8886.patch
>
>
> multiValued docValues numeric fields currently use SortedSet for some reason, 
> but toObject throws an exception in that case.



--
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: Lucene/Solr 5.5.1

[Karthik Ramachandran]

Hey Anshum,

Can you check if you can take SOLR-9034 for 5.5.1?

Will SOLR-8812 make it for 5.5.1?

With Thanks & Regards
Karthik Ramachandran
CommVault
P Please don't print this e-mail unless you really need to



***Legal Disclaimer***
"This communication may contain confidential and privileged material for the
sole use of the intended recipient. Any unauthorized review, use or distribution
by others is strictly prohibited. If you have received the message by mistake,
please advise the sender by reply email and delete the message. Thank you."
**

[jira] [Commented] (SOLR-8886) TrieField.toObject(IndexableField) can't handle docValues

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8886:
---

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

SOLR-8886: fix TrieField.toObject(IndexableField) for docValues


> TrieField.toObject(IndexableField) can't handle docValues
> -
>
> Key: SOLR-8886
> URL: https://issues.apache.org/jira/browse/SOLR-8886
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 6.0
>
> Attachments: SOLR-8886.patch, SOLR-8886.patch
>
>
> multiValued docValues numeric fields currently use SortedSet for some reason, 
> but toObject throws an exception in that case.



--
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-8886) TrieField.toObject(IndexableField) can't handle docValues

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8886:
---

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

SOLR-8886: fix TrieField.toObject(IndexableField) for docValues


> TrieField.toObject(IndexableField) can't handle docValues
> -
>
> Key: SOLR-8886
> URL: https://issues.apache.org/jira/browse/SOLR-8886
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 6.0
>
> Attachments: SOLR-8886.patch, SOLR-8886.patch
>
>
> multiValued docValues numeric fields currently use SortedSet for some reason, 
> but toObject throws an exception in that case.



--
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-5750) Backup/Restore API for SolrCloud

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-5750:


[~dsmiley] [~shalinmangar] I am refactoring the the backup/restore 
implementation in the Overseer primarily to make it extensible. Although we can 
do that as part of a separate JIRA, it would be nice if we can get it done as 
part of this patch itself. I should be able to complete this in next day or two.

Also I filed [SOLR-9038|https://issues.apache.org/jira/browse/SOLR-9038] to 
provide a lightweight alternative to the "full" backup solution implemented by 
this JIRA. Both these JIRAs need following functionality
- Backing up collection metadata
- Restore the collection (both index data and collection metadata).

Since the APIs defined in this patch use the name "snapshot", I wonder how 
should we reconcile these two features? I could think of following options,
- provide a way to override the behavior (e.g. as an API parameter OR some 
other global configuration)
- rename the APIs here to indicate that its a "full" backup (e.g. 
CREATEBACKUP/DELETEBACKUP). This will be consistent with the current core level 
operations (BACKUP/RESTORE).

Please let me know your thoughts on this...

> Backup/Restore API for SolrCloud
> 
>
> Key: SOLR-5750
> URL: https://issues.apache.org/jira/browse/SOLR-5750
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Varun Thacker
> Fix For: 5.2, master
>
> Attachments: SOLR-5750.patch, SOLR-5750.patch, SOLR-5750.patch, 
> SOLR-5750.patch, SOLR-5750.patch, SOLR-5750.patch, SOLR-5750.patch
>
>
> We should have an easy way to do backups and restores in SolrCloud. The 
> ReplicationHandler supports a backup command which can create snapshots of 
> the index but that is too little.
> The command should be able to backup:
> # Snapshots of all indexes or indexes from the leader or the shards
> # Config set
> # Cluster state
> # Cluster properties
> # Aliases
> # Overseer work queue?
> A restore should be able to completely restore the cloud i.e. no manual steps 
> required other than bringing nodes back up or setting up a new cloud cluster.
> SOLR-5340 will be a part of this issue.



--
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-master-Solaris (64bit/jdk1.8.0) - Build # 547 - Failure!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.update.AutoCommitTest.testCommitWithin

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([8C193A8B1F6E705B:36CB55F39C409E4E]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:780)
at 
org.apache.solr.update.AutoCommitTest.testCommitWithin(AutoCommitTest.java:325)
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 java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:529=standard=0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:773)
... 40 more




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

Re: Lucene/Solr 5.5.1

[Anshum Gupta]

Hi Bram,

Sure, as long as someone who understands and has access to Windows can take
a look at it and commit it.

On Wed, Apr 27, 2016 at 12:11 PM, Bram Van Dam  wrote:

> Hey Anshum,
>
> Can you have a look at SOLR-9046 as well? It's something that's been
> bugging me in 5.5. It's fine if it doesn't make it to 5.5.1, but it
> would be really nice if it did!
>
> Thx,
>
>  - Bram
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
Anshum Gupta