[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16909125#comment-16909125 ] Steve Davids commented on SOLR-13452: - I just noticed that this was being worked on via the mailing list and am glad that the build system is being modernized. I have been working with Gradle for quite some time now and have found that moving to gradle's kotlin script to be very nice for code completion + static analysis (IntelliJ support is fantastic). I wanted to provide an example of two files of what a build.gradle vs build.gradle.kts file would like like here: [https://github.com/apache/lucene-solr/compare/jira/SOLR-13452_gradle_5...sdavids13:jira/SOLR-13452_gradle_5] If you would like to move towards adopting Kotlin script I can help out (I have migrated all of my work builds over to kts so have some experience doing so). The nice thing being is that you can migrate one file at a time as both the older style `build.gradle` and newer style `build.gradle.kts` can co-exist in the same repository as migrations take place. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4907) Discuss and create instructions for taking Solr from the example to robust multi-server production
[ https://issues.apache.org/jira/browse/SOLR-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15489470#comment-15489470 ] Steve Davids commented on SOLR-4907: Thanks, I just updated the repo to move solr.in.sh to /etc/default/. In an ideal world the current Lucene/Solr build system would be modernized a bit (LUCENE-5755) and would then allow you to build the RPM + DEB packages along with the ZIP and TAR files which would all be uploaded to the mirrors with a standard release. The nice thing with using a native package installer is that clients can easily uninstall the package if they don't want it and during upgrades old items are cleaned up and removed appropriately since all of the files are being tracked. I personally think it's just one less barrier to entry and much more natural than: `wget http://apache.claz.org/lucene/solr/6.2.0/solr-6.2.0-src.tgz && tar xzf solr-6.2.0.tgz solr-6.2.0/bin/install_solr_service.sh --strip-components=2`. > Discuss and create instructions for taking Solr from the example to robust > multi-server production > -- > > Key: SOLR-4907 > URL: https://issues.apache.org/jira/browse/SOLR-4907 > Project: Solr > Issue Type: Improvement >Reporter: Shawn Heisey > Attachments: SOLR-4907-install.sh > > > There are no good step-by-step instructions for taking the Solr example and > producing a robust production setup on multiple servers. -- 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-6741) IPv6 Field Type
[ https://issues.apache.org/jira/browse/SOLR-6741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15186415#comment-15186415 ] Steve Davids commented on SOLR-6741: Any updates on this ticket regarding rolling with IPv4 support with IPv6 being added later? > IPv6 Field Type > --- > > Key: SOLR-6741 > URL: https://issues.apache.org/jira/browse/SOLR-6741 > Project: Solr > Issue Type: Improvement >Reporter: Lloyd Ramey > Attachments: SOLR-6741.patch > > > It would be nice if Solr had a field type which could be used to index IPv6 > data and supported efficient range queries. -- 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-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15015143#comment-15015143
]
Steve Davids commented on SOLR-7887:
I believe the best argument for logback is that it is a native implementation
for SLF4j since it is developed by the same group. Though, from both a
configuration and performance perspective the two are very similar. It does
seem the logging .properties files have been frowned upon with the preferred
configuration method being the xml configuration (log4j2 xml is pretty similar
to the logback xml configuration).
This is a pretty useful tool to convert the existing log4j.properties files
over to a logback.xml configuration: http://logback.qos.ch/translator/
So, the
[log4j.properties|https://github.com/apache/lucene-solr/blob/639710b2958ed958f977c64a5fe3bbd5b0b0aa23/solr/server/resources/log4j.properties]
translates to:
{code}
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
> Issue Type: Task
>Affects Versions: 5.2.1
>Reporter: Shawn Heisey
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final
> logging destination, so the admin UI has a log watcher that actually uses
> log4j and java.util.logging classes. That will need to be extended to add
> log4j2. I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j. Figuring out exactly which
> jars need to be in the lib/ext directory will take some research.
--
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-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[ https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15015198#comment-15015198 ] Steve Davids commented on SOLR-7887: Looks like there is also a converter for log4j 1.x properties -> log4j 1.x xml here: http://log4j-props2xml.appspot.com/ Then perform the xml migration as defined here: https://logging.apache.org/log4j/2.x/manual/migration.html > Upgrade Solr to use log4j2 -- log4j 1 now officially end of life > > > Key: SOLR-7887 > URL: https://issues.apache.org/jira/browse/SOLR-7887 > Project: Solr > Issue Type: Task >Affects Versions: 5.2.1 >Reporter: Shawn Heisey > > The logging services project has officially announced the EOL of log4j 1: > https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces > In the official binary jetty deployment, we use use log4j 1.2 as our final > logging destination, so the admin UI has a log watcher that actually uses > log4j and java.util.logging classes. That will need to be extended to add > log4j2. I think that might be the largest pain point to this upgrade. > There is some crossover between log4j2 and slf4j. Figuring out exactly which > jars need to be in the lib/ext directory will take some research. -- 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-8313) Migrate to new slf4j logging implementation (log4j 1.x is EOL)
Steve Davids created SOLR-8313: -- Summary: Migrate to new slf4j logging implementation (log4j 1.x is EOL) Key: SOLR-8313 URL: https://issues.apache.org/jira/browse/SOLR-8313 Project: Solr Issue Type: Improvement Components: Server Reporter: Steve Davids Log4j 1.x was declared dead (EOL) in August 2015: https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces Solr should migrate to a new slf4j logging implementation, the popular choices these days seem to be either log4j2 or logback. -- 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-5748) Introduce autoManageReplicas collection property
[ https://issues.apache.org/jira/browse/SOLR-5748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14939199#comment-14939199 ] Steve Davids commented on SOLR-5748: Due to the continued comments about an impending "ZK as truth" switch for the 5.x branch, I went ahead and attempted to start using the Collection API and found it to be be a bit more burdensome than the classic mode. This particular ticket would go a long way to making the adding/removing replica process easy. I documented some of the annoyances in this thread: http://markmail.org/message/qungxgiab6njslpu As for the previous comment: bq. It would be good to have some kind of control over where the additional replicas will be so that the installation could decide that based on the disk space, memory availability etc. That is now taken care of via SOLR-6220 > Introduce autoManageReplicas collection property > > > Key: SOLR-5748 > URL: https://issues.apache.org/jira/browse/SOLR-5748 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: Shalin Shekhar Mangar > Fix For: Trunk > > > I propose to introduce a collection property called autoManageReplicas. This > will be used only with the ZK as truth mode. > If set to true, then whenever the number of replicas for a shard fall below > the replicationFactor and the down nodes do not come back up for a > configurable amount of time, additional replicas will be started up > automatically. Similarly, if the actual number of replicas is equal to or > greater than replicationFactor then if old (previously down) nodes come back > up then they will not be allowed to join the shard and will be unloaded > instead. > I think we should not unload running shards if number of replicas are more > for now. We can change that later if 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-7577) Add support for rules in CREATESHARD and ADDREPLICA
[ https://issues.apache.org/jira/browse/SOLR-7577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936869#comment-14936869 ] Steve Davids commented on SOLR-7577: After looking at the test for this issue, why would anyone need to specify a shardName when a rule is available, doesn't that defeat the entire purpose of being smart with the replica placement via rules? > Add support for rules in CREATESHARD and ADDREPLICA > --- > > Key: SOLR-7577 > URL: https://issues.apache.org/jira/browse/SOLR-7577 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 5.2, Trunk > > Attachments: SOLR-7577.patch > > -- 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-7613) solrcore.properties file should be loaded if it resides in ZooKeeper
[
https://issues.apache.org/jira/browse/SOLR-7613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14735665#comment-14735665
]
Steve Davids commented on SOLR-7613:
I went ahead and swapped our {{solrcore.properties}} over to
{{configoverlay.json}} and it worked like a champ. Using the API we had the
chicken before the egg problem where the core wouldn't come up unless we had
some properties specified but we couldn't specify the properties without having
the core up and running. Thanks for the suggestion [~noble.paul], I think this
ticket is safe to be withdrawn.
> solrcore.properties file should be loaded if it resides in ZooKeeper
>
>
> Key: SOLR-7613
> URL: https://issues.apache.org/jira/browse/SOLR-7613
> Project: Solr
> Issue Type: Bug
>Reporter: Steve Davids
> Fix For: Trunk, 5.4
>
>
> The solrcore.properties file is used to load user defined properties for use
> primarily in the solrconfig.xml file, though this properties file will only
> load if it is resident in the core/conf directory on the physical disk, it
> will not load if it is in ZK's core/conf directory. There should be a
> mechanism to allow a core properties file to be specified in ZK and can be
> updated appropriately along with being able to reload the properties when the
> file changes (or via a core reload).
--
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-7831) Allow a configurable stack size (-Xss)
Steve Davids created SOLR-7831: -- Summary: Allow a configurable stack size (-Xss) Key: SOLR-7831 URL: https://issues.apache.org/jira/browse/SOLR-7831 Project: Solr Issue Type: Improvement Reporter: Steve Davids Fix For: 5.3, Trunk The Java stack size should be a configuration option in the solr.in.sh and solr.in.cmd instead of being set specifically within the startup script. -- 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-7831) Allow a configurable stack size (-Xss)
[ https://issues.apache.org/jira/browse/SOLR-7831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-7831: --- Attachment: SOLR-7831.patch Added patch that preserves the previously set -Xss256k value in the appropriate solr.in.sh and solr.in.cmd files. Allow a configurable stack size (-Xss) -- Key: SOLR-7831 URL: https://issues.apache.org/jira/browse/SOLR-7831 Project: Solr Issue Type: Improvement Reporter: Steve Davids Labels: easyfix, patch Fix For: 5.3, Trunk Attachments: SOLR-7831.patch The Java stack size should be a configuration option in the solr.in.sh and solr.in.cmd instead of being set specifically within the startup script. -- 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-4907) Discuss and create instructions for taking Solr from the example to robust multi-server production
[ https://issues.apache.org/jira/browse/SOLR-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14619695#comment-14619695 ] Steve Davids commented on SOLR-4907: I created a Solr RPM (yum) and DEB (apt-get) package builder here: https://github.com/sdavids13/solr-os-packager. It would be great if those packages can be built and pushed out with new Solr releases to make life a bit easier for clients to install and update to newer versions of Solr. The real meat is happening in the Gradle build file which uses Netflix's gradle-os-package plugin: https://github.com/sdavids13/solr-os-packager/blob/master/build.gradle. Discuss and create instructions for taking Solr from the example to robust multi-server production -- Key: SOLR-4907 URL: https://issues.apache.org/jira/browse/SOLR-4907 Project: Solr Issue Type: Improvement Reporter: Shawn Heisey Attachments: SOLR-4907-install.sh There are no good step-by-step instructions for taking the Solr example and producing a robust production setup on multiple servers. -- 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-7613) solrcore.properties file should be loaded if it resides in ZooKeeper
Steve Davids created SOLR-7613: -- Summary: solrcore.properties file should be loaded if it resides in ZooKeeper Key: SOLR-7613 URL: https://issues.apache.org/jira/browse/SOLR-7613 Project: Solr Issue Type: Bug Reporter: Steve Davids Fix For: 5.3 The solrcore.properties file is used to load user defined properties for use primarily in the solrconfig.xml file, though this properties file will only load if it is resident in the core/conf directory on the physical disk, it will not load if it is in ZK's core/conf directory. There should be a mechanism to allow a core properties file to be specified in ZK and can be updated appropriately along with being able to reload the properties when the file changes (or via a core reload). -- 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-7480) Allow AtomicUpdateDocumentMerger subclasses to override the doAdd method
[ https://issues.apache.org/jira/browse/SOLR-7480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-7480: --- Attachment: SOLR-7480.patch Allow AtomicUpdateDocumentMerger subclasses to override the doAdd method Key: SOLR-7480 URL: https://issues.apache.org/jira/browse/SOLR-7480 Project: Solr Issue Type: Improvement Reporter: Steve Davids Fix For: Trunk, 5.2 Attachments: SOLR-7480.patch I had a slight oversight with the patch I provided on SOLR-6909 where I didn't make the doAdd method on the AtomicUpdateDocumentMerger protected to allow subclasses to override that specific implementation (oops). This is a trivial change to allow clients to subclass and override this specific implementation. -- 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-7474) Remove protocol name from base_url in cluster state
[ https://issues.apache.org/jira/browse/SOLR-7474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14516197#comment-14516197 ] Steve Davids commented on SOLR-7474: The base url should be generated by the node when it joins the cluster (or at least that's how it used to work), so the sequence of events that you describe will work upon restart without having to touch the cluster state. The purpose of the SSLMigrationTest is to do just that - update ZK, restart all nodes, then verify the base_url was updated appropriately with the proper URL scheme. Remove protocol name from base_url in cluster state --- Key: SOLR-7474 URL: https://issues.apache.org/jira/browse/SOLR-7474 Project: Solr Issue Type: Wish Components: SolrCloud Reporter: Shalin Shekhar Mangar Fix For: Trunk, 5.2 In order to setup SSL, a user must add a cluster property which enables HTTPS instead of HTTP. This property is used to create the base_url which is stored for every node in the cluster. The above works fine if we assume that a user decides to enable SSL before creating the cluster. However, if a user with an existing cluster wants to start using SSL, he will need to manually edit his cluster state to switch the protocol stored inside base_url for every node from http to https. If we remove the protocol from the base_url, a user can shutdown the cluster, setup the certificates, add the cluster property and start the cluster thereby re-using the same cluster state which existed without manual modifications. Alternately, an extension to zkcli can be provided to change the cluster state. Thoughts? -- 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-7480) Allow AtomicUpdateDocumentMerger subclasses to override the doAdd method
Steve Davids created SOLR-7480: -- Summary: Allow AtomicUpdateDocumentMerger subclasses to override the doAdd method Key: SOLR-7480 URL: https://issues.apache.org/jira/browse/SOLR-7480 Project: Solr Issue Type: Improvement Reporter: Steve Davids Fix For: Trunk, 5.2 I had a slight oversight with the patch I provided on SOLR-6909 where I didn't make the doAdd method on the AtomicUpdateDocumentMerger protected to allow subclasses to override that specific implementation (oops). This is a trivial change to allow clients to subclass and override this specific implementation. -- 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-4839) Jetty 9
[
https://issues.apache.org/jira/browse/SOLR-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510329#comment-14510329
]
Steve Davids commented on SOLR-4839:
Looks good, though we might want to think about *not* reusing the
javax.net.ssl.* for the jetty key/trust store configuration. I could think of a
few cases where you might want to make the two different, ie one value for the
client request and one value for the jetty connector, unless of course the
recommendation is to only use self-signed certs for both client and server.
Though, maybe the solr.in.sh could have something like:
{code}
SOLR_SSL_KEY_STORE=etc/solr-ssl.keystore.jks
SOLR_SSL_KEY_STORE_PASSWORD=secret
SOLR_SSL_TRUST_STORE=etc/solr-ssl.keystore.jks
SOLR_SSL_TRUST_STORE_PASSWORD=secret
OVERRIDE PREVIOUSLY DEFINED SSL VALUES FOR HTTP CLIENT IF NECESSARY ##
#SOLR_SSL_CLIENT_KEY_STORE=
#SOLR_SSL_CLIENT_KEY_STORE_PASSWORD=
#SOLR_SSL_CLIENT_TRUST_STORE=
#SOLR_SSL_CLIENT_TRUST_STORE_PASSWORD=
{code}
Then the solr startup script can set the javax.net.ssl.* system properties for
the client side + create something like jetty.ssl.truststore/keystore/etc on
the jetty server side. This would allow a little bit more flexibility for
people who might want to use a different certificate or trust store between the
http client and server, though this really is getting more on a fringe use
case.
Jetty 9
---
Key: SOLR-4839
URL: https://issues.apache.org/jira/browse/SOLR-4839
Project: Solr
Issue Type: Improvement
Reporter: Bill Bell
Assignee: Shalin Shekhar Mangar
Fix For: Trunk, 5.2
Attachments: SOLR-4839-conform-jetty9_2_10.patch,
SOLR-4839-conform-jetty9_2_10.patch, SOLR-4839-fix-eclipse.patch,
SOLR-4839-jetty9.2.10, SOLR-4839-mod-JettySolrRunner.patch,
SOLR-4839-ssl-support_patch.patch, SOLR-4839-ssl-support_patch.patch,
SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch,
SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch,
SOLR-4839.patch
Implement Jetty 9
--
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-4839) Jetty 9
[
https://issues.apache.org/jira/browse/SOLR-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510387#comment-14510387
]
Steve Davids commented on SOLR-4839:
Also, if you want to use the javax.net.ssl.* stuff I believe you need to swap
{code}Property name=javax.net.ssl.keyStore
default=./etc/solr-ssl.keystore.jks/{code} with {code}SystemProperty
name=javax.net.ssl.keyStore default=./etc/solr-ssl.keystore.jks/{code}
(note the SystemProperty vs Property).
Jetty 9
---
Key: SOLR-4839
URL: https://issues.apache.org/jira/browse/SOLR-4839
Project: Solr
Issue Type: Improvement
Reporter: Bill Bell
Assignee: Shalin Shekhar Mangar
Fix For: Trunk, 5.2
Attachments: SOLR-4839-conform-jetty9_2_10.patch,
SOLR-4839-conform-jetty9_2_10.patch, SOLR-4839-fix-eclipse.patch,
SOLR-4839-jetty9.2.10, SOLR-4839-mod-JettySolrRunner.patch,
SOLR-4839-ssl-support_patch.patch, SOLR-4839-ssl-support_patch.patch,
SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch,
SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch,
SOLR-4839.patch
Implement Jetty 9
--
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-4839) Jetty 9
[ https://issues.apache.org/jira/browse/SOLR-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14506256#comment-14506256 ] Steve Davids commented on SOLR-4839: Any plans on porting this into the 5x branch? Also, do we know how this will behave with the fancy new startup scripts? It appears clients would need to configure a few things in both the start.in.sh file + the start.ini file as it is sitting right now. Additionally, here are a few potential issues I came across: # jetty-ssl.xml #* Has a bunch of properties that aren't prefixed with 'jetty' ie. 'ssl.port' 'ssl.timeout' vs 'jetty.ssl.port' 'jetty.ssl.timeout'. #* Keystore Truststore path are always relative to `Property name=jetty.base default=. /` which could get annoying for some people if they want to specify an absolute path Jetty 9 --- Key: SOLR-4839 URL: https://issues.apache.org/jira/browse/SOLR-4839 Project: Solr Issue Type: Improvement Reporter: Bill Bell Assignee: Shalin Shekhar Mangar Fix For: Trunk, 5.2 Attachments: SOLR-4839-fix-eclipse.patch, SOLR-4839-mod-JettySolrRunner.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch Implement Jetty 9 -- 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-4839) Jetty 9
[ https://issues.apache.org/jira/browse/SOLR-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14307578#comment-14307578 ] Steve Davids commented on SOLR-4839: I was creating a new MiniSolrCluster test because I needed to have the ability to define multiple cores and I was never able to get the test to work via eclipse, traced it down to be this issue. Sent from my iPhone Jetty 9 --- Key: SOLR-4839 URL: https://issues.apache.org/jira/browse/SOLR-4839 Project: Solr Issue Type: Improvement Reporter: Bill Bell Assignee: Shalin Shekhar Mangar Fix For: Trunk, 5.1 Attachments: SOLR-4839-fix-eclipse.patch, SOLR-4839-mod-JettySolrRunner.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch Implement Jetty 9 -- 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-4407) SSL Certificate based authentication for SolrCloud
[ https://issues.apache.org/jira/browse/SOLR-4407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14308429#comment-14308429 ] Steve Davids commented on SOLR-4407: Sorry for not being more specific. Yes, the instructions does allow for specifying your own self-signed certificate and importing that specific certificate in a new trust store that will be loaded by the container - this will lock it down to the specific certificate. The modification that I have done is to create a custom servlet container to openly accept client certificates within an organization, perform an LDAP lookup (via cert DN) to pull groups then grant access if they are apart of a specific group. With this capability we are able to grant access via LDAP groups which is a preferred route of client authentication for our specific use-case. So, to answer your question: bq. What aspect of SSL do you think isn't already configurable? SSL is configurable via trust stores but mechanisms for a customizable certificate based authentication system isn't in place, such as the case above (get cert DN + user lookup via LDAP to authorize). SSL Certificate based authentication for SolrCloud -- Key: SOLR-4407 URL: https://issues.apache.org/jira/browse/SOLR-4407 Project: Solr Issue Type: New Feature Components: SolrCloud Affects Versions: 4.1 Reporter: Sindre Fiskaa Assignee: Steve Rowe Labels: Authentication, Certificate, SSL Fix For: 4.7, Trunk I need to be able to secure sensitive information in solrnodes running in a SolrCloud with either SSL client/server certificates or http basic auth.. -- 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-4407) SSL Certificate based authentication for SolrCloud
[ https://issues.apache.org/jira/browse/SOLR-4407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14306490#comment-14306490 ] Steve Davids commented on SOLR-4407: Sorry for not replying back earlier. Yes, you can perform certificate based authentication through either built in servlet container mechanisms or custom servlet filters applied via Jetty's webdefault.xml file. So, for the time being it works, but if we move Solr away from users being able to customize their servlet containers (standalone app mode) then Solr will need to make this capability configurable somehow. SSL Certificate based authentication for SolrCloud -- Key: SOLR-4407 URL: https://issues.apache.org/jira/browse/SOLR-4407 Project: Solr Issue Type: New Feature Components: SolrCloud Affects Versions: 4.1 Reporter: Sindre Fiskaa Assignee: Steve Rowe Labels: Authentication, Certificate, SSL Fix For: 4.7, Trunk I need to be able to secure sensitive information in solrnodes running in a SolrCloud with either SSL client/server certificates or http basic auth.. -- 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-6449) Add first class support for Real Time Get in Solrj
[ https://issues.apache.org/jira/browse/SOLR-6449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14290404#comment-14290404 ] Steve Davids commented on SOLR-6449: Cool, thanks Shalin. Just a side note, we could optimize retrievals a little for the Cloud client since it would have knowledge of which shard to route the traffic to (similar to how doc updates are handled) - perhaps a new follow-up ticket is in order just to let people know we thought about it :). Add first class support for Real Time Get in Solrj -- Key: SOLR-6449 URL: https://issues.apache.org/jira/browse/SOLR-6449 Project: Solr Issue Type: Improvement Components: clients - java Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Labels: difficulty-medium, impact-medium Fix For: Trunk, 5.1 Attachments: SOLR-6449.patch, SOLR-6449.patch Any request handler can be queried by Solrj using a custom param map and the qt parameter but I think /get should get first-class support in the java client. -- 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-4839) Jetty 9
[ https://issues.apache.org/jira/browse/SOLR-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14290413#comment-14290413 ] Steve Davids commented on SOLR-4839: Anyone happen to see the same issue I was getting with the TestMiniSolrCloudCluster? I attached a patch but doesn't look like it was pulled in yet, just wondering if others were getting similar test failures. Jetty 9 --- Key: SOLR-4839 URL: https://issues.apache.org/jira/browse/SOLR-4839 Project: Solr Issue Type: Improvement Reporter: Bill Bell Assignee: Shalin Shekhar Mangar Fix For: Trunk, 5.1 Attachments: SOLR-4839-fix-eclipse.patch, SOLR-4839-mod-JettySolrRunner.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch Implement Jetty 9 -- 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-6840) Remove legacy solr.xml mode
[
https://issues.apache.org/jira/browse/SOLR-6840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14277067#comment-14277067
]
Steve Davids commented on SOLR-6840:
Something doesn't seem right here, there is a static http client builder method
that will generate an HttpClient instance in the correct state based on the
system properties of the current actively running test. You shouldn't need to
specify your own instance of HttpClient to build a Solr Client. I can take a
look at this later tonight if you want, was there a particular test failure
that I should hone in on?
Remove legacy solr.xml mode
---
Key: SOLR-6840
URL: https://issues.apache.org/jira/browse/SOLR-6840
Project: Solr
Issue Type: Task
Reporter: Steve Rowe
Assignee: Erick Erickson
Priority: Blocker
Fix For: 5.0
Attachments: SOLR-6840.patch, SOLR-6840.patch, SOLR-6840.patch,
SOLR-6840.patch
On the [Solr Cores and solr.xml
page|https://cwiki.apache.org/confluence/display/solr/Solr+Cores+and+solr.xml],
the Solr Reference Guide says:
{quote}
Starting in Solr 4.3, Solr will maintain two distinct formats for
{{solr.xml}}, the _legacy_ and _discovery_ modes. The former is the format we
have become accustomed to in which all of the cores one wishes to define in a
Solr instance are defined in {{solr.xml}} in
{{corescore/...core//cores}} tags. This format will continue to be
supported through the entire 4.x code line.
As of Solr 5.0 this form of solr.xml will no longer be supported. Instead
Solr will support _core discovery_. [...]
The new core discovery mode structure for solr.xml will become mandatory as
of Solr 5.0, see: Format of solr.xml.
{quote}
AFAICT, nothing has been done to remove legacy {{solr.xml}} mode from 5.0 or
trunk.
--
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-4839) Jetty 9
[ https://issues.apache.org/jira/browse/SOLR-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-4839: --- Attachment: SOLR-4839-mod-JettySolrRunner.patch I found that this broke the 'TestMiniSolrCloudCluster' test (or anything that doesn't specify a 'jetty.testMode' system property). If a test doesn't specify the 'jetty.testMode' property a null pointer exception is thrown by jetty because a ServerConnector is attempting to be created with a null Server. I attached a patch to fix the specific issue, though I'm not quite sure why we need to branch the code - couldn't we consolidate the two? Jetty 9 --- Key: SOLR-4839 URL: https://issues.apache.org/jira/browse/SOLR-4839 Project: Solr Issue Type: Improvement Reporter: Bill Bell Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-4839-fix-eclipse.patch, SOLR-4839-mod-JettySolrRunner.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch Implement Jetty 9 -- 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-6449) Add first class support for Real Time Get in Solrj
[ https://issues.apache.org/jira/browse/SOLR-6449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-6449: --- Attachment: SOLR-6449.patch Provided a simpler patch that doesn't create new GetByIdResponse GetByIdRequest classes. Also, added the ability to specify your own custom SolrParams (useful for specifying fields cores in SolrCloud): SolrDocument getById(String id) SolrDocument getById(String id, SolrParams params) SolrDocumentList getById(CollectionString ids) SolrDocumentList getById(CollectionString ids, SolrParams params) Add first class support for Real Time Get in Solrj -- Key: SOLR-6449 URL: https://issues.apache.org/jira/browse/SOLR-6449 Project: Solr Issue Type: Improvement Components: clients - java Reporter: Shalin Shekhar Mangar Labels: difficulty-medium, impact-medium Fix For: 5.0 Attachments: SOLR-6449.patch, SOLR-6449.patch Any request handler can be queried by Solrj using a custom param map and the qt parameter but I think /get should get first-class support in the java client. -- 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-6496) LBHttpSolrServer should stop server retries after the timeAllowed threshold is met
[ https://issues.apache.org/jira/browse/SOLR-6496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-6496: --- Attachment: SOLR-6496.patch Updated the patch to provide the same exiting functionality in the duplicate request implementation. I created SOLR-6949 to capture the refactoring that should be done to consolidate the two implementations. LBHttpSolrServer should stop server retries after the timeAllowed threshold is met -- Key: SOLR-6496 URL: https://issues.apache.org/jira/browse/SOLR-6496 Project: Solr Issue Type: Bug Affects Versions: 4.9 Reporter: Steve Davids Assignee: Anshum Gupta Priority: Critical Fix For: 5.0 Attachments: SOLR-6496.patch, SOLR-6496.patch, SOLR-6496.patch, SOLR-6496.patch, SOLR-6496.patch, SOLR-6496.patch The LBHttpSolrServer will continue to perform retries for each server it was given without honoring the timeAllowed request parameter. Once the threshold has been met, you should no longer perform retries and allow the exception to bubble up and allow the request to either error out or return partial results per the shards.tolerant request parameter. For a little more context on how this is can be extremely problematic please see the comment here: https://issues.apache.org/jira/browse/SOLR-5986?focusedCommentId=14100991page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14100991 (#2) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6949) Refactor LBHttpSolrClient to consolidate the two different request implementations
Steve Davids created SOLR-6949: -- Summary: Refactor LBHttpSolrClient to consolidate the two different request implementations Key: SOLR-6949 URL: https://issues.apache.org/jira/browse/SOLR-6949 Project: Solr Issue Type: Improvement Reporter: Steve Davids Fix For: 5.0, Trunk LBHttpSolrClient has two duplicate request implementations: 1. public Rsp request(Req req) throws SolrServerException, IOException 2. public NamedListObject request(final SolrRequest request) throws SolrServerException, IOException Refactor the client to provide a single implementation that both can use since they should be consistent and are non-trivial implementations which makes maintenance a bit more burdensome. -- 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-6496) LBHttpSolrServer should stop server retries after the timeAllowed threshold is met
[ https://issues.apache.org/jira/browse/SOLR-6496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14270996#comment-14270996 ] Steve Davids commented on SOLR-6496: The LB Client has duplicate implementations defined in both: 1. public Rsp request(Req req) throws SolrServerException, IOException 2. public NamedListObject request(final SolrRequest request) throws SolrServerException, IOException The original patch was only dealing with one of the two, we need to either a) copy the same code into the other or b) refactor the methods to have a single implementation that both methods call. Option B is my personal preference, though we might want to just do that in a separate ticket and go with option A to get it in as soon as possible. I can work on either tonight after I get back from work if anyone has a route they would like to go. LBHttpSolrServer should stop server retries after the timeAllowed threshold is met -- Key: SOLR-6496 URL: https://issues.apache.org/jira/browse/SOLR-6496 Project: Solr Issue Type: Bug Affects Versions: 4.9 Reporter: Steve Davids Assignee: Anshum Gupta Priority: Critical Fix For: 5.0 Attachments: SOLR-6496.patch, SOLR-6496.patch, SOLR-6496.patch, SOLR-6496.patch, SOLR-6496.patch The LBHttpSolrServer will continue to perform retries for each server it was given without honoring the timeAllowed request parameter. Once the threshold has been met, you should no longer perform retries and allow the exception to bubble up and allow the request to either error out or return partial results per the shards.tolerant request parameter. For a little more context on how this is can be extremely problematic please see the comment here: https://issues.apache.org/jira/browse/SOLR-5986?focusedCommentId=14100991page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14100991 (#2) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6909) Allow pluggable atomic update merging logic
[ https://issues.apache.org/jira/browse/SOLR-6909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-6909: --- Attachment: SOLR-6909.patch Updated patch to add a 'doSet' and 'doAdd' method which allows clients to override specific implementations of any atomic update command. Allow pluggable atomic update merging logic --- Key: SOLR-6909 URL: https://issues.apache.org/jira/browse/SOLR-6909 Project: Solr Issue Type: Improvement Reporter: Steve Davids Fix For: 5.0, Trunk Attachments: SOLR-6909.patch, SOLR-6909.patch Clients should be able to introduce their own specific merging logic by implementing a new class that will be used by the DistributedUpdateProcessor. This is particularly useful if you require a custom hook to interrogate the incoming document with the document that is already resident in the index as there isn't the ability to perform that operation nor can you currently extend the DistributedUpdateProcessor to provide the modifications. -- 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-6909) Allow pluggable atomic update merging logic
[ https://issues.apache.org/jira/browse/SOLR-6909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14270431#comment-14270431 ] Steve Davids commented on SOLR-6909: The javascript approach is interesting but would seem overly complex when you always want the merging logic to work a specific way all the time. Additionally, I have a user case where I download a document in an update processor, extract fields from downloaded content, and index that document. The interesting thing here is that if I can't download the document I set the doc's status to error, though this is only valid if a good document already exists in the index, so if an error doc is trying to be merged an exception is thrown and won't clobber the good document. As you can see with the approach taken in this ticket it allows you the added flexibility with a customizable AtomicUpdateDocumentMerger. Another added benefit is that it cleans up the DistributedUpdateProcessor a little. One modification I might want to make is to the attached patch is to make a `doSet` and `doAdd` which would be allow overrides of each specific merge type. Allow pluggable atomic update merging logic --- Key: SOLR-6909 URL: https://issues.apache.org/jira/browse/SOLR-6909 Project: Solr Issue Type: Improvement Reporter: Steve Davids Fix For: 5.0, Trunk Attachments: SOLR-6909.patch Clients should be able to introduce their own specific merging logic by implementing a new class that will be used by the DistributedUpdateProcessor. This is particularly useful if you require a custom hook to interrogate the incoming document with the document that is already resident in the index as there isn't the ability to perform that operation nor can you currently extend the DistributedUpdateProcessor to provide the modifications. -- 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-6909) Allow pluggable atomic update merging logic
[ https://issues.apache.org/jira/browse/SOLR-6909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14270431#comment-14270431 ] Steve Davids edited comment on SOLR-6909 at 1/9/15 2:28 AM: The javascript approach is interesting but would seem overly complex when you always want the merging logic to work a specific way all the time. Additionally, I have a user case where I download a document in an update processor, extract fields from downloaded content, and index that document. The interesting thing here is that if I can't download the document I set the doc's status to error, though this is only valid if a good document *doesn't* already exists in the index, so if an error doc is trying to be merged on top of an existing document an exception is thrown and won't clobber the good document. As you can see with the approach taken in this ticket it allows you the added flexibility with a customizable AtomicUpdateDocumentMerger. Another added benefit is that it cleans up the DistributedUpdateProcessor a little. One modification I might want to make is to the attached patch is to make a `doSet` and `doAdd` which would be allow overrides of each specific merge type. was (Author: sdavids): The javascript approach is interesting but would seem overly complex when you always want the merging logic to work a specific way all the time. Additionally, I have a user case where I download a document in an update processor, extract fields from downloaded content, and index that document. The interesting thing here is that if I can't download the document I set the doc's status to error, though this is only valid if a good document already exists in the index, so if an error doc is trying to be merged an exception is thrown and won't clobber the good document. As you can see with the approach taken in this ticket it allows you the added flexibility with a customizable AtomicUpdateDocumentMerger. Another added benefit is that it cleans up the DistributedUpdateProcessor a little. One modification I might want to make is to the attached patch is to make a `doSet` and `doAdd` which would be allow overrides of each specific merge type. Allow pluggable atomic update merging logic --- Key: SOLR-6909 URL: https://issues.apache.org/jira/browse/SOLR-6909 Project: Solr Issue Type: Improvement Reporter: Steve Davids Fix For: 5.0, Trunk Attachments: SOLR-6909.patch Clients should be able to introduce their own specific merging logic by implementing a new class that will be used by the DistributedUpdateProcessor. This is particularly useful if you require a custom hook to interrogate the incoming document with the document that is already resident in the index as there isn't the ability to perform that operation nor can you currently extend the DistributedUpdateProcessor to provide the modifications. -- 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-6909) Allow pluggable atomic update merging logic
Steve Davids created SOLR-6909: -- Summary: Allow pluggable atomic update merging logic Key: SOLR-6909 URL: https://issues.apache.org/jira/browse/SOLR-6909 Project: Solr Issue Type: Improvement Reporter: Steve Davids Fix For: 5.0, Trunk Clients should be able to introduce their own specific merging logic by implementing a new class that will be used by the DistributedUpdateProcessor. This is particularly useful if you require a custom hook to interrogate the incoming document with the document that is already resident in the index as there isn't the ability to perform that operation nor can you currently extend the DistributedUpdateProcessor to provide the modifications. -- 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-6909) Allow pluggable atomic update merging logic
[ https://issues.apache.org/jira/browse/SOLR-6909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-6909: --- Attachment: SOLR-6909.patch Attached a patch which pulls the current merging implementation out from the DistributedUpdateProcessor into a new AtomicUpdateDocumentMerger class. This DistributedUpdateProcessorFactory instantiates a new AtomicUpdateDocumentMerger and passes it to the DistributedUpdateProcessor. This approach allows clients to extend the DistributedUpdateProcessorFactory and instantiate their own custom AtomicUpdateDocumentMerger which is then passed along to the DistributedUpdateProcessor. One thing that I'm not thrilled about is having a static 'isAtomicUpdate' method (currently in the code), I tried to remove the static but a couple other classes require that static method to be there and having a merger member variable didn't quite make sense in those cases so I left it a static. Allow pluggable atomic update merging logic --- Key: SOLR-6909 URL: https://issues.apache.org/jira/browse/SOLR-6909 Project: Solr Issue Type: Improvement Reporter: Steve Davids Fix For: 5.0, Trunk Attachments: SOLR-6909.patch Clients should be able to introduce their own specific merging logic by implementing a new class that will be used by the DistributedUpdateProcessor. This is particularly useful if you require a custom hook to interrogate the incoming document with the document that is already resident in the index as there isn't the ability to perform that operation nor can you currently extend the DistributedUpdateProcessor to provide the modifications. -- 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-6735) CloneFieldUpdateProcessorFactory should be null safe
[ https://issues.apache.org/jira/browse/SOLR-6735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263734#comment-14263734 ] Steve Davids commented on SOLR-6735: Anyone willing to commit this? With the attached patch any null value is ignored, an alternative approach is to preserve the null by adding it to the destination field. Regardless the approach, it should be null safe. CloneFieldUpdateProcessorFactory should be null safe Key: SOLR-6735 URL: https://issues.apache.org/jira/browse/SOLR-6735 Project: Solr Issue Type: Bug Reporter: Steve Davids Fix For: 5.0, Trunk Attachments: SOLR-6735.patch If a source field value is null the CloneFieldUpdateProcessor throws a null pointer exception. -- 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-4839) Jetty 9
[ https://issues.apache.org/jira/browse/SOLR-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14254329#comment-14254329 ] Steve Davids commented on SOLR-4839: bq. Jetty 9 has this concept of modules which can be configured via property files and/or by xml. We could do away with XML configuration if we want. I actually like the module concept but I'm not sure how much of that you are going to want to bundle in Solr itself (copying module files). Let me know if you want a hand with any of the TODOs. Jetty 9 --- Key: SOLR-4839 URL: https://issues.apache.org/jira/browse/SOLR-4839 Project: Solr Issue Type: Improvement Reporter: Bill Bell Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-4839.patch, SOLR-4839.patch Implement Jetty 9 -- 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-4839) Jetty 9
[ https://issues.apache.org/jira/browse/SOLR-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14252919#comment-14252919 ] Steve Davids commented on SOLR-4839: The jetty.xml file is going to need to change: bq. Prior to Jetty 9, the type of the connector specified both the protocol and the implementation used (for example, selector-based non blocking I/O vs blocking I/O, or SSL connector vs non-SSL connector). Jetty 9 has only a selector-based non blocking I/O connector, and a collection of ConnectionFactories now configure the protocol on the connector. http://www.eclipse.org/jetty/documentation/current/configuring-connectors.html#jetty-connectors Jetty 9 --- Key: SOLR-4839 URL: https://issues.apache.org/jira/browse/SOLR-4839 Project: Solr Issue Type: Improvement Reporter: Bill Bell Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-4839.patch Implement Jetty 9 -- 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-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14239541#comment-14239541 ] Steve Davids commented on SOLR-6625: bq. See SOLR-4470. That makes use of SolrRequest.getPreemptiveAuthentication, so you'd need the actual SolrRequest I took a look at the patch but not quite sure any of that is actually necessary. Looking at the what detailed in SOLR-4470 they need to be able to lock down Solr Cloud via BasicAuth, you can easily do this via HttpClient's [BasicScheme| http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/auth/BasicScheme.html] authentication scheme. Likewise you can see all of the various other [authentication schemes| http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/auth/AuthScheme.html] HttpClient supports (SPNego included). This would seem to do the trick, except for perhaps propagating the authentication from the original request though this shouldn't really be a requirement since the challenge will be static in the web container that you can live with having static credentials in the solr distrib - if it changes deploy new config changes. For further information on authentication via HttpClient check out their help page here: http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html bq. See the discussion above about SolrDispatchFilter. In that case, the client needs to get the context of the SolrQueryRequest... For my case, in the SolrDispatchFilter, I need to get some information from the SolrQueryRequest or HttpServletRequest (basically, the authenticated user that's available in the HttpServletRequest.getAttribute or SolrQueryRequest.getContext() or SolrQueryRequest.getParams()) Are you using these credentials to execute distributed requests? Or would it make sense to have a certain user hit the frontend shard, then that shard will perform the distributed request on behalf of the system's authentication credentials? HttpClient callback in HttpSolrServer - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Gregory Chanan Priority: Minor Attachments: SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14238865#comment-14238865 ] Steve Davids commented on SOLR-6625: Is there any reason why we wouldn't just utilize HttpClient's [HttpRequestInterceptor| http://hc.apache.org/httpcomponents-core-4.3.x/httpcore/apidocs/org/apache/http/HttpRequestInterceptor.html] and [HttpResponseInterceptor| http://hc.apache.org/httpcomponents-core-4.3.x/httpcore/apidocs/org/apache/http/HttpResponseInterceptor.html]? It seems as though if we could just provide an HttpClientFactory that clients can implement/override it should provide enough hooks to have everyone customize HttpClient to their hearts delight. HttpClient callback in HttpSolrServer - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Gregory Chanan Priority: Minor Attachments: SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6741) IPv6 Field Type
[ https://issues.apache.org/jira/browse/SOLR-6741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-6741: --- Attachment: SOLR-6741.patch I attached a patch for IPv4 support which allows a prefix query, range queries, and CIDR notation which extends a TrieLongField. Hopefully this can serve as a good starting point. [~lnr0626] was also a contributor for this code. IPv6 Field Type --- Key: SOLR-6741 URL: https://issues.apache.org/jira/browse/SOLR-6741 Project: Solr Issue Type: Improvement Reporter: Lloyd Ramey Attachments: SOLR-6741.patch It would be nice if Solr had a field type which could be used to index IPv6 data and supported efficient range queries. -- 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-6735) CloneFieldUpdateProcessorFactory should be null safe
Steve Davids created SOLR-6735: -- Summary: CloneFieldUpdateProcessorFactory should be null safe Key: SOLR-6735 URL: https://issues.apache.org/jira/browse/SOLR-6735 Project: Solr Issue Type: Bug Reporter: Steve Davids Fix For: 5.0, Trunk If a source field value is null the CloneFieldUpdateProcessor throws a null pointer exception. -- 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-6735) CloneFieldUpdateProcessorFactory should be null safe
[ https://issues.apache.org/jira/browse/SOLR-6735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-6735: --- Attachment: SOLR-6735.patch Attached a trivial patch. CloneFieldUpdateProcessorFactory should be null safe Key: SOLR-6735 URL: https://issues.apache.org/jira/browse/SOLR-6735 Project: Solr Issue Type: Bug Reporter: Steve Davids Fix For: 5.0, Trunk Attachments: SOLR-6735.patch If a source field value is null the CloneFieldUpdateProcessor throws a null pointer exception. -- 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-4587) Implement Saved Searches a la ElasticSearch Percolator
[ https://issues.apache.org/jira/browse/SOLR-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14204028#comment-14204028 ] Steve Davids commented on SOLR-4587: I believe we are confusing what Luwak *is* - Luwak is just an optimized matching algorithm which really belongs in the Lucene package rather than the Solr package. Since this ticket is centered around Solr's implementation of the percolator this more has to deal with the registration of queries and providing an API to stream back saved search query ids back to the client that matched a particular document. From a black box perspective that external interface (Solr HTTP API) should be rather simple, though the internal workings could be marked as experimental and can be swapped out for better implementations in the future. Implement Saved Searches a la ElasticSearch Percolator -- Key: SOLR-4587 URL: https://issues.apache.org/jira/browse/SOLR-4587 Project: Solr Issue Type: New Feature Components: SearchComponents - other, SolrCloud Reporter: Otis Gospodnetic Fix For: Trunk Use Lucene MemoryIndex for this. -- 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-4587) Implement Saved Searches a la ElasticSearch Percolator
[ https://issues.apache.org/jira/browse/SOLR-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14202936#comment-14202936 ] Steve Davids commented on SOLR-4587: I agree that the Luwak approach provides clever performance optimizations by removing unnecessary queries upfront. Though, Luwak doesn't really solve providing percolator-like functionality, just provides an optimized matching algorithm. There is a decent amount of work here to allow clients to register queries in a Solr cluster and provide an API to pass a document and have it get matched against registered queries in a distributed manor, none of which is handled by Luwak. I personally believe this ticket can be implemented without Luwak's optimizations and provide value. We could provide a usage caveat that you might not want to register more than 20k queries per shard or so, or if they want to register more queries they can shard out their profiling/matcher collection to take advantage of additional hardware. We can provide an initial implementation then optimize the matching once Luwak dependencies are completed, but from an outside-in perspective the API would remain the same but matching would just be faster at a future point. Does it make sense to others to start with an initial approach then provide optimizations in future releases just as long as the API remains the same? Implement Saved Searches a la ElasticSearch Percolator -- Key: SOLR-4587 URL: https://issues.apache.org/jira/browse/SOLR-4587 Project: Solr Issue Type: New Feature Components: SearchComponents - other, SolrCloud Reporter: Otis Gospodnetic Fix For: Trunk Use Lucene MemoryIndex for this. -- 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-4587) Implement Saved Searches a la ElasticSearch Percolator
[ https://issues.apache.org/jira/browse/SOLR-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14199868#comment-14199868 ] Steve Davids commented on SOLR-4587: I don't think Luwak is really an implementation of this particular feature. It does perform percolating functionality but as a stand-alone library which isn't integrated into Solr. May I suggest that we take a stab at this without waiting around for Luwak since the implementation is dependent on LUCENE-2878 which seems to keep stalling over and over again. The initial approach can take the naive loop across all queries for each document request and at a later point the Luwak approach can be incorporated to provide some nice optimizations. Here are some initial thoughts on acceptance criteria / what can be done to incorporate this functionality into solr: # Able to register a query within a separate Solr core #* Should take advantage of Solr's sharding ability in Solr Cloud #* This can piggy-back off of the standard SolrInputDocument semantics with adding/deleting to perform query registration/deregistration. #* Schema would define various fields for the stored query: q, fq, defType, etc. # Able to specify which query parser should be used when matching docs (persisted w/ query) # Able to specify the other core that the document should be profiled against (this can be at request time if you would like to profile against multiple shards) #* Allows the profiling to know the fields, analysis chain, etc # Should allow queries to be cached in RAM so they don't need to be re-parsed continually # Custom response handler (perhaps a subclass of the search handler) should make a distributed request to all shards to gather all matching query profile ids and return to the client. This is one of those features that would provide a lot of value to users and would be fantastic if we can get incorporated sooner rather than later. Implement Saved Searches a la ElasticSearch Percolator -- Key: SOLR-4587 URL: https://issues.apache.org/jira/browse/SOLR-4587 Project: Solr Issue Type: New Feature Components: SearchComponents - other, SolrCloud Reporter: Otis Gospodnetic Fix For: Trunk Use Lucene MemoryIndex for this. -- 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-6449) Add first class support for Real Time Get in Solrj
[
https://issues.apache.org/jira/browse/SOLR-6449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14176051#comment-14176051
]
Steve Davids commented on SOLR-6449:
This issue is really providing yet another convenience method to perform CRUD
operations.
Create Update Operations:
{code}
UpdateResponse resp = solrServer.add(SolrInputDocument);
UpdateResponse resp = solrServer.add(CollectionSolrInputDocument);
//+ a couple variants
{code}
These methods don't necessarily need to align to the various REST HTTP method
semantics. The add action will perform a create or update clobbering the
document already in place with the ability to perform an atomic update
operation which will perform a merge with the document already in the index.
Delete Operations:
{code}
UpdateResponse resp = solrServer.deleteById(String id);
UpdateResponse resp = solrServer.deleteById(CollectionString id);
UpdateResponse resp = solrServer.deleteByQuery(String query);
//+ a couple variants
{code}
Read Operations:
{code}
QueryResponse resp = solrServer.query(SolrParams);
//+ a couple variants
{code}
As you can see the delete operation allows you to delete given a specific id or
delete by a query, whereas the retrieval only gives you query access. To be
consistent this ticket should provide the ability to retrieve by id as a
convenience to developers using the SolrJ API (not to mention the additional
benefits they will get from the RealTimeGetHandler).
Add first class support for Real Time Get in Solrj
--
Key: SOLR-6449
URL: https://issues.apache.org/jira/browse/SOLR-6449
Project: Solr
Issue Type: Improvement
Components: clients - java
Reporter: Shalin Shekhar Mangar
Labels: difficulty-medium, impact-medium
Fix For: 5.0
Any request handler can be queried by Solrj using a custom param map and the
qt parameter but I think /get should get first-class support in the java
client.
--
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-6449) Add first class support for Real Time Get in Solrj
[
https://issues.apache.org/jira/browse/SOLR-6449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14175587#comment-14175587
]
Steve Davids commented on SOLR-6449:
The current way of accessing the Real Time Get in SolrJ you need to do
something along the lines of:
{code}
SolrDocument doc = solrServer.query(params(qt, /get, id,
id)).getResponse().get(doc);
{code}
It would be convenient to provide a native method of (or similar variant):
{code}
SolrDocument doc = solrServer.get(id);
{code}
Add first class support for Real Time Get in Solrj
--
Key: SOLR-6449
URL: https://issues.apache.org/jira/browse/SOLR-6449
Project: Solr
Issue Type: Improvement
Components: clients - java
Reporter: Shalin Shekhar Mangar
Labels: difficulty-medium, impact-medium
Fix For: 5.0
Any request handler can be queried by Solrj using a custom param map and the
qt parameter but I think /get should get first-class support in the java
client.
--
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-5986) Don't allow runaway queries from harming Solr cluster health or search performance
[ https://issues.apache.org/jira/browse/SOLR-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14159212#comment-14159212 ] Steve Davids commented on SOLR-5986: Why wouldn't it return partial results? When sending a distributed request if all but one return results but one shard lags behind at query expansion one would think that you would get the appropriate partial results message. Unless this is partially related to SOLR-6496 which would retry a different replica in the shard group and thus *could* cause a timeout at the Solr distributed aggregation layer. Don't allow runaway queries from harming Solr cluster health or search performance -- Key: SOLR-5986 URL: https://issues.apache.org/jira/browse/SOLR-5986 Project: Solr Issue Type: Improvement Components: search Reporter: Steve Davids Assignee: Anshum Gupta Priority: Critical Fix For: 5.0 Attachments: SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch The intent of this ticket is to have all distributed search requests stop wasting CPU cycles on requests that have already timed out or are so complicated that they won't be able to execute. We have come across a case where a nasty wildcard query within a proximity clause was causing the cluster to enumerate terms for hours even though the query timeout was set to minutes. This caused a noticeable slowdown within the system which made us restart the replicas that happened to service that one request, the worst case scenario are users with a relatively low zk timeout value will have nodes start dropping from the cluster due to long GC pauses. [~amccurry] Built a mechanism into Apache Blur to help with the issue in BLUR-142 (see commit comment for code, though look at the latest code on the trunk for newer bug fixes). Solr should be able to either prevent these problematic queries from running by some heuristic (possibly estimated size of heap usage) or be able to execute a thread interrupt on all query threads once the time threshold is met. This issue mirrors what others have discussed on the mailing list: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200903.mbox/%3c856ac15f0903272054q2dbdbd19kea3c5ba9e105b...@mail.gmail.com%3E -- 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-6576) ModifiableSolrParams#add(SolrParams) is performing a set operation instead of an add
[
https://issues.apache.org/jira/browse/SOLR-6576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14155314#comment-14155314
]
Steve Davids commented on SOLR-6576:
Oops, I glanced at the code too fast last night and saw the suppress deprecated
warning:
{code}
@SuppressWarnings({deprecation})
public static SolrParams wrapAppended(SolrParams params, SolrParams defaults) {
{code}
which I mistook as @deprecated for some reason, my bad.
ModifiableSolrParams#add(SolrParams) is performing a set operation instead of
an add
Key: SOLR-6576
URL: https://issues.apache.org/jira/browse/SOLR-6576
Project: Solr
Issue Type: Bug
Reporter: Steve Davids
Fix For: 5.0, Trunk
Attachments: SOLR-6576.patch
Came across this bug by attempting to append multiple ModifiableSolrParam
objects together but found the last one was clobbering the previously set
values. The add operation should append the values to the previously defined
values, not perform a set operation.
--
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-6576) ModifiableSolrParams#add(SolrParams) is performing a set operation instead of an add
Steve Davids created SOLR-6576: -- Summary: ModifiableSolrParams#add(SolrParams) is performing a set operation instead of an add Key: SOLR-6576 URL: https://issues.apache.org/jira/browse/SOLR-6576 Project: Solr Issue Type: Bug Reporter: Steve Davids Fix For: 5.0, Trunk Came across this bug by attempting to append multiple ModifiableSolrParam objects together but found the last one was clobbering the previously set values. The add operation should append the values to the previously defined values, not perform a set operation. -- 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-6576) ModifiableSolrParams#add(SolrParams) is performing a set operation instead of an add
[ https://issues.apache.org/jira/browse/SOLR-6576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-6576: --- Attachment: SOLR-6576.patch Fix + tests added in attached patch. ModifiableSolrParams#add(SolrParams) is performing a set operation instead of an add Key: SOLR-6576 URL: https://issues.apache.org/jira/browse/SOLR-6576 Project: Solr Issue Type: Bug Reporter: Steve Davids Fix For: 5.0, Trunk Attachments: SOLR-6576.patch Came across this bug by attempting to append multiple ModifiableSolrParam objects together but found the last one was clobbering the previously set values. The add operation should append the values to the previously defined values, not perform a set operation. -- 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-6576) ModifiableSolrParams#add(SolrParams) is performing a set operation instead of an add
[ https://issues.apache.org/jira/browse/SOLR-6576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14154316#comment-14154316 ] Steve Davids commented on SOLR-6576: Yea, this is a bit misleading as ModifiableSolrParams.add( String name, String ... val ) says: bq. Add the given values to any existing name The behavior of this particular method works as expected, I would likewise assume that the add for SolrParams would work just the same way. That would be like saying we had a map with two methods: put(K key, V value) and putAll(Map? extends K,? extends V m) but did two completely different things. So in my head I would think the method for the current functionality would mimic the set capability: bq. Replace any existing parameter with the given name. and should be named appropriately. Also, SolrParams.wrapAppended(SolrParams) is deprecated so that isn't very re-assuring to use :) ModifiableSolrParams#add(SolrParams) is performing a set operation instead of an add Key: SOLR-6576 URL: https://issues.apache.org/jira/browse/SOLR-6576 Project: Solr Issue Type: Bug Reporter: Steve Davids Fix For: 5.0, Trunk Attachments: SOLR-6576.patch Came across this bug by attempting to append multiple ModifiableSolrParam objects together but found the last one was clobbering the previously set values. The add operation should append the values to the previously defined values, not perform a set operation. -- 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-6496) LBHttpSolrServer should stop server retries after the timeAllowed threshold is met
[
https://issues.apache.org/jira/browse/SOLR-6496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Davids updated SOLR-6496:
---
Attachment: SOLR-6496.patch
Updated patch to use nano time. Still thinking of some potential tricks to
*not* use mocks, are there any tests out there that may screw with the jetty
server to make the socket connection arbitrarily long then somehow throw an
exception and verify that the next request isn't made?
On the mocking front I would do something like (note: redundant static
Mockito.* accessors only showed for demonstrative purposes):
{code}
@Test
public void testNoRetryOnTimeout() throws Exception {
LBHttpSolrServer testServer = Mockito.spy(new
LBHttpSolrServer(http://test1;, http://test2;));
Mockito.doAnswer(new AnswerException() {
@Override
public Exception answer(InvocationOnMock invocation) throws Throwable {
Thread.sleep(1);
return new SolrServerException(Mock error.);
}}).when(testServer).doRequest(Mockito.any(HttpSolrServer.class),
Mockito.any(Req.class), Mockito.any(Rsp.class), Mockito.anyBoolean(),
Mockito.anyBoolean(), Mockito.anyString());
testServer.query(SolrTestCaseJ4.params(CommonParams.Q, test,
CommonParams.TIME_ALLOWED, 1));
Mockito.verify(testServer,
Mockito.times(1)).doRequest(Mockito.any(HttpSolrServer.class),
Mockito.any(Req.class), Mockito.any(Rsp.class), Mockito.anyBoolean(),
Mockito.anyBoolean(), Mockito.anyString());
}
{code}
This test actually showed some strange behavior that there are multiple
implemented methods trying to do the same thing. See LBHttpSolrServer's:
# public Rsp request(Req req) throws SolrServerException, IOException
# public NamedListObject request(final SolrRequest request) throws
SolrServerException, IOException
So, depending on if you are using the CloudSolrServer or the
HttpShardHandlerFactory you are going to get different request behavior. We
should probably try to refactor this code to provide consistent behavior
perhaps in a different ticket.
LBHttpSolrServer should stop server retries after the timeAllowed threshold
is met
--
Key: SOLR-6496
URL: https://issues.apache.org/jira/browse/SOLR-6496
Project: Solr
Issue Type: Bug
Affects Versions: 4.9
Reporter: Steve Davids
Assignee: Anshum Gupta
Priority: Critical
Fix For: 5.0
Attachments: SOLR-6496.patch, SOLR-6496.patch, SOLR-6496.patch
The LBHttpSolrServer will continue to perform retries for each server it was
given without honoring the timeAllowed request parameter. Once the threshold
has been met, you should no longer perform retries and allow the exception to
bubble up and allow the request to either error out or return partial results
per the shards.tolerant request parameter.
For a little more context on how this is can be extremely problematic please
see the comment here:
https://issues.apache.org/jira/browse/SOLR-5986?focusedCommentId=14100991page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14100991
(#2)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5986) Don't allow runaway queries from harming Solr cluster health or search performance
[ https://issues.apache.org/jira/browse/SOLR-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14141216#comment-14141216 ] Steve Davids commented on SOLR-5986: Looks good to me, the only nit-picky thing I would say is the QueryTimeoutBase name for an interface is strange, you may consider renaming it to QueryTimeout and rename the current QueryTimeout class to something along the lines of LuceneQueryTimeout / DefaultQueryTimeout / SimpleQueryTimeout? Don't allow runaway queries from harming Solr cluster health or search performance -- Key: SOLR-5986 URL: https://issues.apache.org/jira/browse/SOLR-5986 Project: Solr Issue Type: Improvement Components: search Reporter: Steve Davids Assignee: Anshum Gupta Priority: Critical Fix For: 4.10 Attachments: SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch The intent of this ticket is to have all distributed search requests stop wasting CPU cycles on requests that have already timed out or are so complicated that they won't be able to execute. We have come across a case where a nasty wildcard query within a proximity clause was causing the cluster to enumerate terms for hours even though the query timeout was set to minutes. This caused a noticeable slowdown within the system which made us restart the replicas that happened to service that one request, the worst case scenario are users with a relatively low zk timeout value will have nodes start dropping from the cluster due to long GC pauses. [~amccurry] Built a mechanism into Apache Blur to help with the issue in BLUR-142 (see commit comment for code, though look at the latest code on the trunk for newer bug fixes). Solr should be able to either prevent these problematic queries from running by some heuristic (possibly estimated size of heap usage) or be able to execute a thread interrupt on all query threads once the time threshold is met. This issue mirrors what others have discussed on the mailing list: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200903.mbox/%3c856ac15f0903272054q2dbdbd19kea3c5ba9e105b...@mail.gmail.com%3E -- 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-3120) span query matches too many docs when two query terms are the same unless inOrder=true
[ https://issues.apache.org/jira/browse/LUCENE-3120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated LUCENE-3120: - Attachment: LUCENE-3120.patch A user came across this odd behavior, attached a simple test case that was written before I came across this ticket which demonstrates the discrepancy. span query matches too many docs when two query terms are the same unless inOrder=true -- Key: LUCENE-3120 URL: https://issues.apache.org/jira/browse/LUCENE-3120 Project: Lucene - Core Issue Type: Bug Components: core/search Reporter: Doron Cohen Priority: Minor Fix For: 4.9, 5.0 Attachments: LUCENE-3120.patch, LUCENE-3120.patch, LUCENE-3120.patch spinoff of user list discussion - [SpanNearQuery - inOrder parameter|http://markmail.org/message/i4cstlwgjmlcfwlc]. With 3 documents: * a b x c d * a b b d * a b x b y d Here are a few queries (the number in parenthesis indicates expected #hits): These ones work *as expected*: * (1) in-order, slop=0, b, x, b * (1) in-order, slop=0, b, b * (2) in-order, slop=1, b, b These ones match *too many* hits: * (1) any-order, slop=0, b, x, b * (1) any-order, slop=1, b, x, b * (1) any-order, slop=2, b, x, b * (1) any-order, slop=3, b, x, b These ones match *too many* hits as well: * (1) any-order, slop=0, b, b * (2) any-order, slop=1, b, b Each of the above passes when using a phrase query (applying the slop, no in-order indication in phrase query). This seems related to a known overlapping spans issue - [non-overlapping Span queries|http://markmail.org/message/7jxn5eysjagjwlon] - as indicated by Hoss, so we might decide to close this bug after all, but I would like to at least have the junit that exposes the behavior in JIRA. -- 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-5932) SpanNearUnordered duplicate term counts itself as a match
[ https://issues.apache.org/jira/browse/LUCENE-5932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128971#comment-14128971 ] Steve Davids commented on LUCENE-5932: -- Oops, you are correct - it does appear to be a duplicate. SpanNearUnordered duplicate term counts itself as a match - Key: LUCENE-5932 URL: https://issues.apache.org/jira/browse/LUCENE-5932 Project: Lucene - Core Issue Type: Bug Affects Versions: 4.9 Reporter: Steve Davids Fix For: 4.11 Attachments: LUCENE-5932.patch An unordered span near with the exact same term will count the first position as a match for the second term. A document with values: w1 w2 w3 w4 w5 Query hit: spanNear([w1, w1], 1, false) -- SpanNearUnordered Query miss: spanNear([w1, w1], 1, true) -- SpanNearOrdered (expected) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5932) SpanNearUnordered duplicate term counts itself as a match
[ https://issues.apache.org/jira/browse/LUCENE-5932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids resolved LUCENE-5932. -- Resolution: Duplicate Fix Version/s: (was: 4.11) SpanNearUnordered duplicate term counts itself as a match - Key: LUCENE-5932 URL: https://issues.apache.org/jira/browse/LUCENE-5932 Project: Lucene - Core Issue Type: Bug Affects Versions: 4.9 Reporter: Steve Davids Attachments: LUCENE-5932.patch An unordered span near with the exact same term will count the first position as a match for the second term. A document with values: w1 w2 w3 w4 w5 Query hit: spanNear([w1, w1], 1, false) -- SpanNearUnordered Query miss: spanNear([w1, w1], 1, true) -- SpanNearOrdered (expected) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6496) LBHttpSolrServer should stop server retries after the timeAllowed threshold is met
Steve Davids created SOLR-6496: -- Summary: LBHttpSolrServer should stop server retries after the timeAllowed threshold is met Key: SOLR-6496 URL: https://issues.apache.org/jira/browse/SOLR-6496 Project: Solr Issue Type: Bug Affects Versions: 4.9 Reporter: Steve Davids Priority: Critical Fix For: 4.11 The LBHttpSolrServer will continue to perform retries for each server it was given without honoring the timeAllowed request parameter. Once the threshold has been met, you should no longer perform retries and allow the exception to bubble up and allow the request to either error out or return partial results per the shards.tolerant request parameter. For a little more context on how this is can be extremely problematic please see the comment here: https://issues.apache.org/jira/browse/SOLR-5986?focusedCommentId=14100991page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14100991 (#2) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6496) LBHttpSolrServer should stop server retries after the timeAllowed threshold is met
[ https://issues.apache.org/jira/browse/SOLR-6496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-6496: --- Attachment: SOLR-6496.patch Initial patch that honors the timeAllowed request parameter. There aren't any tests included -- is there any objections to perhaps using a mocking library, it sure would make it much easier to perform unit testing on these negative cases. Mockito is my personal preference and is currently being used in Morphlines, but it will need to be included in the SolrJ test dependencies. LBHttpSolrServer should stop server retries after the timeAllowed threshold is met -- Key: SOLR-6496 URL: https://issues.apache.org/jira/browse/SOLR-6496 Project: Solr Issue Type: Bug Affects Versions: 4.9 Reporter: Steve Davids Priority: Critical Fix For: 4.11 Attachments: SOLR-6496.patch The LBHttpSolrServer will continue to perform retries for each server it was given without honoring the timeAllowed request parameter. Once the threshold has been met, you should no longer perform retries and allow the exception to bubble up and allow the request to either error out or return partial results per the shards.tolerant request parameter. For a little more context on how this is can be extremely problematic please see the comment here: https://issues.apache.org/jira/browse/SOLR-5986?focusedCommentId=14100991page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14100991 (#2) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5986) Don't allow runaway queries from harming Solr cluster health or search performance
[ https://issues.apache.org/jira/browse/SOLR-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14127767#comment-14127767 ] Steve Davids commented on SOLR-5986: bq. I think this should be ok, specially considering the intention is to make sure that the request is killed and doesn't run forever. +1, this is a good starting point and can be further refined in the future if need be. I went ahead and opened SOLR-6496 to account for the LBHttpSolrServer's continual retries. Also, I am a little concerned that the cursorMark doesn't honor the timeAllowed request parameter for some strange reason (the cursorMark ticket didn't provide any rational for it), we may want to revisit that decision in yet another ticket so people can be confident their cursor mark queries won't crash their clusters as well. Thanks for taking this on Anshum! Don't allow runaway queries from harming Solr cluster health or search performance -- Key: SOLR-5986 URL: https://issues.apache.org/jira/browse/SOLR-5986 Project: Solr Issue Type: Improvement Components: search Reporter: Steve Davids Assignee: Anshum Gupta Priority: Critical Fix For: 4.10 Attachments: SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch The intent of this ticket is to have all distributed search requests stop wasting CPU cycles on requests that have already timed out or are so complicated that they won't be able to execute. We have come across a case where a nasty wildcard query within a proximity clause was causing the cluster to enumerate terms for hours even though the query timeout was set to minutes. This caused a noticeable slowdown within the system which made us restart the replicas that happened to service that one request, the worst case scenario are users with a relatively low zk timeout value will have nodes start dropping from the cluster due to long GC pauses. [~amccurry] Built a mechanism into Apache Blur to help with the issue in BLUR-142 (see commit comment for code, though look at the latest code on the trunk for newer bug fixes). Solr should be able to either prevent these problematic queries from running by some heuristic (possibly estimated size of heap usage) or be able to execute a thread interrupt on all query threads once the time threshold is met. This issue mirrors what others have discussed on the mailing list: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200903.mbox/%3c856ac15f0903272054q2dbdbd19kea3c5ba9e105b...@mail.gmail.com%3E -- 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-6496) LBHttpSolrServer should stop server retries after the timeAllowed threshold is met
[ https://issues.apache.org/jira/browse/SOLR-6496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-6496: --- Attachment: SOLR-6496.patch Fixed patch for null safe SolrParams check. LBHttpSolrServer should stop server retries after the timeAllowed threshold is met -- Key: SOLR-6496 URL: https://issues.apache.org/jira/browse/SOLR-6496 Project: Solr Issue Type: Bug Affects Versions: 4.9 Reporter: Steve Davids Priority: Critical Fix For: 4.11 Attachments: SOLR-6496.patch, SOLR-6496.patch The LBHttpSolrServer will continue to perform retries for each server it was given without honoring the timeAllowed request parameter. Once the threshold has been met, you should no longer perform retries and allow the exception to bubble up and allow the request to either error out or return partial results per the shards.tolerant request parameter. For a little more context on how this is can be extremely problematic please see the comment here: https://issues.apache.org/jira/browse/SOLR-5986?focusedCommentId=14100991page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14100991 (#2) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5932) SpanNearUnordered duplicate term counts itself as a match
Steve Davids created LUCENE-5932: Summary: SpanNearUnordered duplicate term counts itself as a match Key: LUCENE-5932 URL: https://issues.apache.org/jira/browse/LUCENE-5932 Project: Lucene - Core Issue Type: Bug Affects Versions: 4.9 Reporter: Steve Davids Fix For: 4.11 An unordered span near with the exact same term will count the first position as a match for the second term. A document with values: w1 w2 w3 w4 w5 Query hit: spanNear([w1, w1], 1, false) -- SpanNearUnordered Query miss: spanNear([w1, w1], 1, true) -- SpanNearOrdered (expected) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5932) SpanNearUnordered duplicate term counts itself as a match
[ https://issues.apache.org/jira/browse/LUCENE-5932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated LUCENE-5932: - Attachment: LUCENE-5932.patch Added patch with test case demonstrating the issue. SpanNearUnordered duplicate term counts itself as a match - Key: LUCENE-5932 URL: https://issues.apache.org/jira/browse/LUCENE-5932 Project: Lucene - Core Issue Type: Bug Affects Versions: 4.9 Reporter: Steve Davids Fix For: 4.11 Attachments: LUCENE-5932.patch An unordered span near with the exact same term will count the first position as a match for the second term. A document with values: w1 w2 w3 w4 w5 Query hit: spanNear([w1, w1], 1, false) -- SpanNearUnordered Query miss: spanNear([w1, w1], 1, true) -- SpanNearOrdered (expected) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6483) Refactor some methods in MiniSolrCloudCluster tests
[ https://issues.apache.org/jira/browse/SOLR-6483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-6483: --- Attachment: SOLR-6483.patch Initial patch which has allowed additional convenience methods in the MiniSolrCloudCluster including: # Upload a config directory to ZooKeeper # Create a collection #* Added ability to provide collection properties # Use a pre-configured CloudSolrServer instance The TestMiniSolrCloudCluster has been refactored to use these new methods. A few additional changes that should still be done: # Provide waitForRecoveriesToFinish convenience method in MiniSolrCloudCluster #* The code in the test is almost a direct copy/past from AbstractDistribZkTestBase.waitForRecoveriesToFinish, it would be nice to refactor this code into a common class (as this is not trivial code to maintain). # All system properties were dropped *except* for solr.solrxml.location zkHost because those are necessary for Jetty to know where to pick up it's configuration on initial startup. It would be nice to see if there is an alternate way of getting that information to Jetty without setting the system property. Refactor some methods in MiniSolrCloudCluster tests --- Key: SOLR-6483 URL: https://issues.apache.org/jira/browse/SOLR-6483 Project: Solr Issue Type: Improvement Affects Versions: 5.0, 4.11 Reporter: Erick Erickson Assignee: Erick Erickson Priority: Minor Attachments: SOLR-6483.patch Looking at whether we can provide some ease-of-use methods in MiniSolrCloudCluster -- 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-4406) RawResponseWriter - doesn't use the configured base writer.
[ https://issues.apache.org/jira/browse/SOLR-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14119803#comment-14119803 ] Steve Davids commented on SOLR-4406: bq. So i took a stab at refactoring it to have test methods that more directly modeled the list of situations you identified Personally I prefer having small, self describing test method names instead of having 3 methods that do everything and making you really dig in there if any one of the tests actually fail. That's why I went the route of building 3 test methods per case I described above: # If a content stream is provided send that back in the writer output stream #* testGetContentType #* testWriteContentStreamViaWriter #* testWriteContentStreamViaOutputStream # If no content stream is provided and no base writer is specified verify the response is serialized with the default writer (XML) #* testDefaultBaseWriterGetContentType #* testDefaultBaseWriterViaWriter #* testDefaultBaseWriterViaOutputStream # If no content stream is provided and a base writer is specified serialize with the specified writer #* testJsonBaseWriterGetContentType #* testJsonBaseWriterViaWriter #* testJsonBaseWriterViaOutputStream Personally I think this is one of those beauty is in the eye of the beholder, I kind of prefer the original test but cleanliness and clarity can sometimes be subjective (though initRawResponseWriter was a poor naming choice, perhaps setBaseWriter would have been better). You are testing a couple more cases that I wasn't looking for before, which is always a good thing. All the other changes look good, I'm not hung up on any of the test changes. RawResponseWriter - doesn't use the configured base writer. - Key: SOLR-4406 URL: https://issues.apache.org/jira/browse/SOLR-4406 Project: Solr Issue Type: Bug Components: Response Writers Affects Versions: 4.0 Reporter: Steve Davids Assignee: Hoss Man Attachments: SOLR-4406.patch, SOLR-4406.patch, SOLR-4406.patch, SOLR-4406.patch, SOLR-4406.patch, SOLR-4406.patch The RawResponseWriter accepts a configuration value for a base ResponseWriter if no ContentStream can be detected. The line of code is commented out that would allow this secondary response writer to work. It would be great to uncomment the line and provide an OutputStreamWriter as the writer argument. -- 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-4406) RawResponseWriter - doesn't use the configured base writer.
[ https://issues.apache.org/jira/browse/SOLR-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14114631#comment-14114631 ] Steve Davids commented on SOLR-4406: [~hossman] Does the supplied tests fit the bill? RawResponseWriter - doesn't use the configured base writer. - Key: SOLR-4406 URL: https://issues.apache.org/jira/browse/SOLR-4406 Project: Solr Issue Type: Bug Components: Response Writers Affects Versions: 4.0 Reporter: Steve Davids Attachments: SOLR-4406.patch, SOLR-4406.patch, SOLR-4406.patch, SOLR-4406.patch, SOLR-4406.patch The RawResponseWriter accepts a configuration value for a base ResponseWriter if no ContentStream can be detected. The line of code is commented out that would allow this secondary response writer to work. It would be great to uncomment the line and provide an OutputStreamWriter as the writer argument. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6233) Provide basic command line tools for checking Solr status and health.
[
https://issues.apache.org/jira/browse/SOLR-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108633#comment-14108633
]
Steve Davids commented on SOLR-6233:
One other note, it looks like you created your own Json parser to provide an
xpath-like experience, there is a library that I have used before which is
great named JsonPath (https://code.google.com/p/json-path/). Not sure if this
specific class warrants bringing in that package but if we start seeing a
higher need for similar mechanisms we may want to consider pulling it in since
it does provide a much readable experience.
Provide basic command line tools for checking Solr status and health.
-
Key: SOLR-6233
URL: https://issues.apache.org/jira/browse/SOLR-6233
Project: Solr
Issue Type: Improvement
Reporter: Timothy Potter
Assignee: Timothy Potter
Priority: Minor
Fix For: 5.0, 4.10
Attachments: SOLR-6233-minor-refactor.patch
As part of the start script development work SOLR-3617, example restructuring
SOLR-3619, and the overall curb appeal work SOLR-4430, I'd like to have an
option on the SystemInfoHandler that gives a shorter, well formatted JSON
synopsis of essential information. I know essential is vague ;-) but right
now using curl to http://host:port/solr/admin/info/system?wt=json gives too
much information when I just want a synopsis of a Solr server.
Maybe something like overview=true?
Result would be:
{noformat}
{
address: http://localhost:8983/solr;,
mode: solrcloud,
zookeeper: localhost:2181/foo,
uptime: 2 days, 3 hours, 4 minutes, 5 seconds,
version: 5.0-SNAPSHOT,
status: healthy,
memory: 4.2g of 6g
}
{noformat}
Now of course, one may argue all this information can be easily parsed from
the JSON but consider cross-platform command-line tools that don't have
immediate access to a JSON parser, such as the bin/solr start script.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6390) Remove unnecessary checked exception for CloudSolrServer constructor
[ https://issues.apache.org/jira/browse/SOLR-6390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14106925#comment-14106925 ] Steve Davids commented on SOLR-6390: I can go ahead and update the patch later this evening. Remove unnecessary checked exception for CloudSolrServer constructor Key: SOLR-6390 URL: https://issues.apache.org/jira/browse/SOLR-6390 Project: Solr Issue Type: Improvement Reporter: Steve Davids Assignee: Shawn Heisey Priority: Trivial Fix For: 5.0 Attachments: SOLR-6390.patch The CloudSolrServer constructors can be simplified and can remove an unnecessary checked exception for one of the 4 constructors. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6390) Remove unnecessary checked exception for CloudSolrServer constructor
[ https://issues.apache.org/jira/browse/SOLR-6390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-6390: --- Attachment: SOLR-6390.patch Updated patch to add more descriptive javadocs for the CloudSolrServer constructors found in issue SOLR-5852. Remove unnecessary checked exception for CloudSolrServer constructor Key: SOLR-6390 URL: https://issues.apache.org/jira/browse/SOLR-6390 Project: Solr Issue Type: Improvement Reporter: Steve Davids Assignee: Shawn Heisey Priority: Trivial Fix For: 5.0 Attachments: SOLR-6390.patch, SOLR-6390.patch The CloudSolrServer constructors can be simplified and can remove an unnecessary checked exception for one of the 4 constructors. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6233) Provide basic command line tools for checking Solr status and health.
[
https://issues.apache.org/jira/browse/SOLR-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Davids updated SOLR-6233:
---
Attachment: SOLR-6233-minor-refactor.patch
I was looking over some of the command line tools (extremely useful), and
refactored some of the code to make it a little more readable.
Provide basic command line tools for checking Solr status and health.
-
Key: SOLR-6233
URL: https://issues.apache.org/jira/browse/SOLR-6233
Project: Solr
Issue Type: Improvement
Reporter: Timothy Potter
Assignee: Timothy Potter
Priority: Minor
Fix For: 5.0, 4.10
Attachments: SOLR-6233-minor-refactor.patch
As part of the start script development work SOLR-3617, example restructuring
SOLR-3619, and the overall curb appeal work SOLR-4430, I'd like to have an
option on the SystemInfoHandler that gives a shorter, well formatted JSON
synopsis of essential information. I know essential is vague ;-) but right
now using curl to http://host:port/solr/admin/info/system?wt=json gives too
much information when I just want a synopsis of a Solr server.
Maybe something like overview=true?
Result would be:
{noformat}
{
address: http://localhost:8983/solr;,
mode: solrcloud,
zookeeper: localhost:2181/foo,
uptime: 2 days, 3 hours, 4 minutes, 5 seconds,
version: 5.0-SNAPSHOT,
status: healthy,
memory: 4.2g of 6g
}
{noformat}
Now of course, one may argue all this information can be easily parsed from
the JSON but consider cross-platform command-line tools that don't have
immediate access to a JSON parser, such as the bin/solr start script.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4406) RawResponseWriter - doesn't use the configured base writer.
[ https://issues.apache.org/jira/browse/SOLR-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-4406: --- Attachment: SOLR-4406.patch Added tests which provides complete code coverage of the RawResponseWriter. I didn't go the mocking route, instead it is an integration test by spinning up a core to assert 3 different cases: 1) If a content stream is provided send that back in the writer output stream 2) If no content stream is provided and no base writer is specified verify the response is serialized with the default writer (XML) 3) If no content stream is provided and a base writer is specified serialize with the specified writer RawResponseWriter - doesn't use the configured base writer. - Key: SOLR-4406 URL: https://issues.apache.org/jira/browse/SOLR-4406 Project: Solr Issue Type: Bug Components: Response Writers Affects Versions: 4.0 Reporter: Steve Davids Attachments: SOLR-4406.patch, SOLR-4406.patch, SOLR-4406.patch The RawResponseWriter accepts a configuration value for a base ResponseWriter if no ContentStream can be detected. The line of code is commented out that would allow this secondary response writer to work. It would be great to uncomment the line and provide an OutputStreamWriter as the writer argument. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4406) RawResponseWriter - doesn't use the configured base writer.
[ https://issues.apache.org/jira/browse/SOLR-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-4406: --- Attachment: SOLR-4406.patch Made a small tweak to use the Java 7 auto-closeable for the Writer/Output streams. RawResponseWriter - doesn't use the configured base writer. - Key: SOLR-4406 URL: https://issues.apache.org/jira/browse/SOLR-4406 Project: Solr Issue Type: Bug Components: Response Writers Affects Versions: 4.0 Reporter: Steve Davids Attachments: SOLR-4406.patch, SOLR-4406.patch, SOLR-4406.patch, SOLR-4406.patch The RawResponseWriter accepts a configuration value for a base ResponseWriter if no ContentStream can be detected. The line of code is commented out that would allow this secondary response writer to work. It would be great to uncomment the line and provide an OutputStreamWriter as the writer argument. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4406) RawResponseWriter - doesn't use the configured base writer.
[ https://issues.apache.org/jira/browse/SOLR-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-4406: --- Attachment: SOLR-4406.patch RawResponseWriter - doesn't use the configured base writer. - Key: SOLR-4406 URL: https://issues.apache.org/jira/browse/SOLR-4406 Project: Solr Issue Type: Bug Components: Response Writers Affects Versions: 4.0 Reporter: Steve Davids Attachments: SOLR-4406.patch, SOLR-4406.patch, SOLR-4406.patch, SOLR-4406.patch, SOLR-4406.patch The RawResponseWriter accepts a configuration value for a base ResponseWriter if no ContentStream can be detected. The line of code is commented out that would allow this secondary response writer to work. It would be great to uncomment the line and provide an OutputStreamWriter as the writer argument. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5986) Don't allow runaway queries from harming Solr cluster health or search performance
[ https://issues.apache.org/jira/browse/SOLR-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102854#comment-14102854 ] Steve Davids commented on SOLR-5986: Correct, I was just providing additional insight into the issues we have been seeing. Don't allow runaway queries from harming Solr cluster health or search performance -- Key: SOLR-5986 URL: https://issues.apache.org/jira/browse/SOLR-5986 Project: Solr Issue Type: Improvement Components: search Reporter: Steve Davids Assignee: Anshum Gupta Priority: Critical Fix For: 4.10 Attachments: SOLR-5986.patch The intent of this ticket is to have all distributed search requests stop wasting CPU cycles on requests that have already timed out or are so complicated that they won't be able to execute. We have come across a case where a nasty wildcard query within a proximity clause was causing the cluster to enumerate terms for hours even though the query timeout was set to minutes. This caused a noticeable slowdown within the system which made us restart the replicas that happened to service that one request, the worst case scenario are users with a relatively low zk timeout value will have nodes start dropping from the cluster due to long GC pauses. [~amccurry] Built a mechanism into Apache Blur to help with the issue in BLUR-142 (see commit comment for code, though look at the latest code on the trunk for newer bug fixes). Solr should be able to either prevent these problematic queries from running by some heuristic (possibly estimated size of heap usage) or be able to execute a thread interrupt on all query threads once the time threshold is met. This issue mirrors what others have discussed on the mailing list: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200903.mbox/%3c856ac15f0903272054q2dbdbd19kea3c5ba9e105b...@mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5986) Don't allow runaway queries from harming Solr cluster health or search performance
[ https://issues.apache.org/jira/browse/SOLR-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14100991#comment-14100991 ] Steve Davids commented on SOLR-5986: We came across the issue again and added a lot more probes to get a grasp on what exactly is happening, I believe further tickets might be necessary to address various pieces. #1) We are setting the timeout request parameter which tells the TimeLimitingCollector to throw a TimeExceededException, though in our logs we see the error messages thrown after about an hour for one of the queries we tried, even though the timeout is set for a couple of minutes. This is presumably due to the query parsing taking about an hour and once the query is finally parsed and handed to the collector the TimeLimitingCollector immediately throws in exception. We should have something similar throw the same exception while in the query building phase (this way the partial results warnings will continue to just work). It looks like the current work is more in the realm of solving this issue which may fix the problems we saw described in #2. #2) We set socket read timeouts on HTTPClient which causes the same query to be sent into the cluster multiple times giving it a slow, painful death. This is even more problematic while using the SolrJ API, what ends up happening from SolrJ's LBHttpSolrServer is that it will loop through *every* host in the cluster and if a socket read timeout happens it tries the next item in the list. Internally every single request made to the cluster from an outside SolrJ client will try to gather the results for all shards in the cluster, once a socket read timeout happens internal to the cluster the same retry logic will attempt to gather results from the next replica in the list. So, if we hypothetically had 10 shards with 3 replicas, and made a request from an outside client it would make 30 (external SolrJ call to each host to request a distributed search) * 30 (each host will be called at least once for the internal distributed request) = 900 overall requests (each individual search host will handle 30 requests). This should probably become it's own ticket to track, to either a) don't retry on a socket read timeout or b) specify a retry timeout of some sort in the LBHttpSolrServer (this is something we did internally for simplicity sake). Don't allow runaway queries from harming Solr cluster health or search performance -- Key: SOLR-5986 URL: https://issues.apache.org/jira/browse/SOLR-5986 Project: Solr Issue Type: Improvement Components: search Reporter: Steve Davids Assignee: Anshum Gupta Priority: Critical Fix For: 4.10 Attachments: SOLR-5986.patch The intent of this ticket is to have all distributed search requests stop wasting CPU cycles on requests that have already timed out or are so complicated that they won't be able to execute. We have come across a case where a nasty wildcard query within a proximity clause was causing the cluster to enumerate terms for hours even though the query timeout was set to minutes. This caused a noticeable slowdown within the system which made us restart the replicas that happened to service that one request, the worst case scenario are users with a relatively low zk timeout value will have nodes start dropping from the cluster due to long GC pauses. [~amccurry] Built a mechanism into Apache Blur to help with the issue in BLUR-142 (see commit comment for code, though look at the latest code on the trunk for newer bug fixes). Solr should be able to either prevent these problematic queries from running by some heuristic (possibly estimated size of heap usage) or be able to execute a thread interrupt on all query threads once the time threshold is met. This issue mirrors what others have discussed on the mailing list: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200903.mbox/%3c856ac15f0903272054q2dbdbd19kea3c5ba9e105b...@mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4406) RawResponseWriter - doesn't use the configured base writer.
[ https://issues.apache.org/jira/browse/SOLR-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-4406: --- Attachment: SOLR-4406.patch Attached a patch which allows the RawResponseWriter to honor it's contract: --snip-- ..if no such ContentStream has been added, then a base QueryResponseWriter will be used to write the response according to the usual contract... --snip-- Performed some minor refactoring to provide a single method to write query responses to an output stream. RawResponseWriter - doesn't use the configured base writer. - Key: SOLR-4406 URL: https://issues.apache.org/jira/browse/SOLR-4406 Project: Solr Issue Type: Bug Components: Response Writers Affects Versions: 4.0 Reporter: Steve Davids Attachments: SOLR-4406.patch The RawResponseWriter accepts a configuration value for a base ResponseWriter if no ContentStream can be detected. The line of code is commented out that would allow this secondary response writer to work. It would be great to uncomment the line and provide an OutputStreamWriter as the writer argument. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4406) RawResponseWriter - doesn't use the configured base writer.
[ https://issues.apache.org/jira/browse/SOLR-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-4406: --- Attachment: SOLR-4406.patch Oops, didn't add the new utility class to SVN - patch updated. RawResponseWriter - doesn't use the configured base writer. - Key: SOLR-4406 URL: https://issues.apache.org/jira/browse/SOLR-4406 Project: Solr Issue Type: Bug Components: Response Writers Affects Versions: 4.0 Reporter: Steve Davids Attachments: SOLR-4406.patch, SOLR-4406.patch The RawResponseWriter accepts a configuration value for a base ResponseWriter if no ContentStream can be detected. The line of code is commented out that would allow this secondary response writer to work. It would be great to uncomment the line and provide an OutputStreamWriter as the writer argument. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6390) Remove unnecessary checked exception for CloudSolrServer constructor
Steve Davids created SOLR-6390: -- Summary: Remove unnecessary checked exception for CloudSolrServer constructor Key: SOLR-6390 URL: https://issues.apache.org/jira/browse/SOLR-6390 Project: Solr Issue Type: Improvement Reporter: Steve Davids Priority: Trivial Fix For: 5.0 The CloudSolrServer constructors can be simplified and can remove an unnecessary checked exception for one of the 4 constructors. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6390) Remove unnecessary checked exception for CloudSolrServer constructor
[ https://issues.apache.org/jira/browse/SOLR-6390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-6390: --- Attachment: SOLR-6390.patch Added patch Remove unnecessary checked exception for CloudSolrServer constructor Key: SOLR-6390 URL: https://issues.apache.org/jira/browse/SOLR-6390 Project: Solr Issue Type: Improvement Reporter: Steve Davids Priority: Trivial Fix For: 5.0 Attachments: SOLR-6390.patch The CloudSolrServer constructors can be simplified and can remove an unnecessary checked exception for one of the 4 constructors. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6312) CloudSolrServer doesn't honor updatesToLeaders constructor argument
[ https://issues.apache.org/jira/browse/SOLR-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-6312: --- Attachment: SOLR-6312.patch Added patch to re-enable the updatesToLeader flag and perhaps spur additional commentary :) CloudSolrServer doesn't honor updatesToLeaders constructor argument --- Key: SOLR-6312 URL: https://issues.apache.org/jira/browse/SOLR-6312 Project: Solr Issue Type: Bug Affects Versions: 4.9 Reporter: Steve Davids Fix For: 4.10 Attachments: SOLR-6312.patch The CloudSolrServer doesn't use the updatesToLeaders property - all SolrJ requests are being sent to the shard leaders. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4406) RawResponseWriter - doesn't use the configured base writer.
[ https://issues.apache.org/jira/browse/SOLR-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101858#comment-14101858 ] Steve Davids commented on SOLR-4406: Yea, this is a somewhat obscure bug I came across since I wanted to send back a raw stream but if an exception occurred I wanted to apply a velocity template to the response instead. I will throw some tests together in the next day or two. RawResponseWriter - doesn't use the configured base writer. - Key: SOLR-4406 URL: https://issues.apache.org/jira/browse/SOLR-4406 Project: Solr Issue Type: Bug Components: Response Writers Affects Versions: 4.0 Reporter: Steve Davids Attachments: SOLR-4406.patch, SOLR-4406.patch The RawResponseWriter accepts a configuration value for a base ResponseWriter if no ContentStream can be detected. The line of code is commented out that would allow this secondary response writer to work. It would be great to uncomment the line and provide an OutputStreamWriter as the writer argument. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6312) CloudSolrServer doesn't honor updatesToLeaders constructor argument
[ https://issues.apache.org/jira/browse/SOLR-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093983#comment-14093983 ] Steve Davids commented on SOLR-6312: Yes, I understand that all updates will always go to the leader, the CPU intensive task in this entire process is running extraction logic using XPaths in the update processor chain before any requests are distributed to the leader/replicas. When the request is distributed to the leader, the leader doesn't need to start the update processor from scratch, instead it continues where the other machine left off in the processing pipeline at the DistributedUpdateProcessor. So if I am able to load balance requests to all replicas the CPU intensive tasks (early update processors) will be shared by multiple machines not just the leader and should result in increased throughput. CloudSolrServer doesn't honor updatesToLeaders constructor argument --- Key: SOLR-6312 URL: https://issues.apache.org/jira/browse/SOLR-6312 Project: Solr Issue Type: Bug Affects Versions: 4.9 Reporter: Steve Davids Fix For: 4.10 The CloudSolrServer doesn't use the updatesToLeaders property - all SolrJ requests are being sent to the shard leaders. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6312) CloudSolrServer doesn't honor updatesToLeaders constructor argument
[ https://issues.apache.org/jira/browse/SOLR-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093533#comment-14093533 ] Steve Davids commented on SOLR-6312: bq. So, if my understanding is correct, what you should be seeing is that queries are randomly distributed to any 1 solr node, while updates are always targeted at the correct leader. [~hossman] You are correct, that is what I am seeing as well. Though I have a re-indexing use-case where I would actually like to distribute update requests to more than just the leader. I am currently performing XPath extraction logic in the update chain before distributed the requests to replicas, the problem I am running into is that the leader's CPU is completely pegged running the XPaths while the replicas are almost idle (~20%). I looked to this feature to allow more throughput by load balancing the extraction logic to the replicas and just forwarding the complete/hydrated document to the leader. I know this is a somewhat fringe case but still think it can be useful. CloudSolrServer doesn't honor updatesToLeaders constructor argument --- Key: SOLR-6312 URL: https://issues.apache.org/jira/browse/SOLR-6312 Project: Solr Issue Type: Bug Affects Versions: 4.9 Reporter: Steve Davids Fix For: 4.10 The CloudSolrServer doesn't use the updatesToLeaders property - all SolrJ requests are being sent to the shard leaders. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6312) CloudSolrServer doesn't honor updatesToLeaders constructor argument
Steve Davids created SOLR-6312: -- Summary: CloudSolrServer doesn't honor updatesToLeaders constructor argument Key: SOLR-6312 URL: https://issues.apache.org/jira/browse/SOLR-6312 Project: Solr Issue Type: Bug Affects Versions: 4.9 Reporter: Steve Davids Fix For: 4.10 The CloudSolrServer doesn't use the updatesToLeaders property - all SolrJ requests are being sent to the shard leaders. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5986) Don't allow runaway queries from harming Solr cluster health or search performance
[ https://issues.apache.org/jira/browse/SOLR-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080124#comment-14080124 ] Steve Davids commented on SOLR-5986: There doesn't appear to be any Lucene code that is specifically honoring a thread interrupt, so if Solr/Lucene is busy enumerating terms in a continual for loop, sending an interrupt won't actually do anything. The Java code needs to check if the thread has been interrupted, if so, then bail on the current process. Blur does this by creating their own ExitableTerms, ExitableTermsEnum, etc where every time the enum next method is called, it will check to see if the thread has been interrupted, if it is then an exception is thrown which halts processing of the query. https://git-wip-us.apache.org/repos/asf?p=incubator-blur.git;a=blob;f=blur-store/src/main/java/org/apache/blur/index/ExitableReader.java;h=8321dd27d3537ee239f876448e56e8296407700b;hb=61480125dee51c469a4921004f6daf590410bca6 Performing the thread interrupt check within Lucene seems reasonable for things that may take a long time to complete, enumerating terms is one of them. Don't allow runaway queries from harming Solr cluster health or search performance -- Key: SOLR-5986 URL: https://issues.apache.org/jira/browse/SOLR-5986 Project: Solr Issue Type: Improvement Components: search Reporter: Steve Davids Priority: Critical Fix For: 4.9 The intent of this ticket is to have all distributed search requests stop wasting CPU cycles on requests that have already timed out or are so complicated that they won't be able to execute. We have come across a case where a nasty wildcard query within a proximity clause was causing the cluster to enumerate terms for hours even though the query timeout was set to minutes. This caused a noticeable slowdown within the system which made us restart the replicas that happened to service that one request, the worst case scenario are users with a relatively low zk timeout value will have nodes start dropping from the cluster due to long GC pauses. [~amccurry] Built a mechanism into Apache Blur to help with the issue in BLUR-142 (see commit comment for code, though look at the latest code on the trunk for newer bug fixes). Solr should be able to either prevent these problematic queries from running by some heuristic (possibly estimated size of heap usage) or be able to execute a thread interrupt on all query threads once the time threshold is met. This issue mirrors what others have discussed on the mailing list: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200903.mbox/%3c856ac15f0903272054q2dbdbd19kea3c5ba9e105b...@mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5986) Don't allow runaway queries from harming Solr cluster health or search performance
[ https://issues.apache.org/jira/browse/SOLR-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14062187#comment-14062187 ] Steve Davids commented on SOLR-5986: In an ideal world it would attempt to provide results for the shards that may be okay, but the end goal is to maintain the health of the cluster for queries that get out of hand. If you can know up front that there is no possible way that a query could complete then it would be reasonable to error out immediately (though that metric may be squishy to know if it will/will not complete). Hopefully that makes sense... Don't allow runaway queries from harming Solr cluster health or search performance -- Key: SOLR-5986 URL: https://issues.apache.org/jira/browse/SOLR-5986 Project: Solr Issue Type: Improvement Components: search Reporter: Steve Davids Priority: Critical Fix For: 4.9 The intent of this ticket is to have all distributed search requests stop wasting CPU cycles on requests that have already timed out or are so complicated that they won't be able to execute. We have come across a case where a nasty wildcard query within a proximity clause was causing the cluster to enumerate terms for hours even though the query timeout was set to minutes. This caused a noticeable slowdown within the system which made us restart the replicas that happened to service that one request, the worst case scenario are users with a relatively low zk timeout value will have nodes start dropping from the cluster due to long GC pauses. [~amccurry] Built a mechanism into Apache Blur to help with the issue in BLUR-142 (see commit comment for code, though look at the latest code on the trunk for newer bug fixes). Solr should be able to either prevent these problematic queries from running by some heuristic (possibly estimated size of heap usage) or be able to execute a thread interrupt on all query threads once the time threshold is met. This issue mirrors what others have discussed on the mailing list: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200903.mbox/%3c856ac15f0903272054q2dbdbd19kea3c5ba9e105b...@mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5986) Don't allow runaway queries from harming Solr cluster health or search performance
[ https://issues.apache.org/jira/browse/SOLR-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14062250#comment-14062250 ] Steve Davids commented on SOLR-5986: bq. I wonder why you would have to restart the replica? I presume this is because that is your only recourse to stop a query that might take days to complete? Yes, that is correct, that is the easiest way to kill a run-away thread. bq. If a query takes that long and is ignoring a specified timeout, that seems like it's own issue that needs resolution. The Solr instance that is distributing the requests to other shards honors the timeout value and stops the collection process once the threshold is met (and returns to the client with partial results if any are available), though the queries remain running on all of the shards that were initially searched in the overall distributed request. If the timeout value is honored on each shard that was used in the distributed request that would probably take care of the problem. bq. IMHO, the primary goal should be to make SolrCloud clusters more resilient to performance degradations caused by such nasty queries described above. +1 resiliency to performance degradations is always a good thing :) bq. The circuit-breaker approach in the linked ES tickets is clever, but it does not seem to be as generally applicable as the ability to view all running queries with an option to stop them. +1 I actually prefer the BLUR route, though being able to see the current queries plus the ability to kill them off across the cluster would be great. Although it is crucial to be able to automatically have queries be killed off after a certain threshold (ideally the timeout value). This is necessary because I don't want to be monitoring the Solr admin page at all hours during the day (though I could create scripts to do the work if an API call is available, but not preferred). bq. My preference would be to have a response mechanism that 1) applies broadly and 2) a dev-ops guy can execute in a UI like Solr Admin, or even by API. +1 if applied broadly means ability to specify a threshold to start killing off queries. Don't allow runaway queries from harming Solr cluster health or search performance -- Key: SOLR-5986 URL: https://issues.apache.org/jira/browse/SOLR-5986 Project: Solr Issue Type: Improvement Components: search Reporter: Steve Davids Priority: Critical Fix For: 4.9 The intent of this ticket is to have all distributed search requests stop wasting CPU cycles on requests that have already timed out or are so complicated that they won't be able to execute. We have come across a case where a nasty wildcard query within a proximity clause was causing the cluster to enumerate terms for hours even though the query timeout was set to minutes. This caused a noticeable slowdown within the system which made us restart the replicas that happened to service that one request, the worst case scenario are users with a relatively low zk timeout value will have nodes start dropping from the cluster due to long GC pauses. [~amccurry] Built a mechanism into Apache Blur to help with the issue in BLUR-142 (see commit comment for code, though look at the latest code on the trunk for newer bug fixes). Solr should be able to either prevent these problematic queries from running by some heuristic (possibly estimated size of heap usage) or be able to execute a thread interrupt on all query threads once the time threshold is met. This issue mirrors what others have discussed on the mailing list: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200903.mbox/%3c856ac15f0903272054q2dbdbd19kea3c5ba9e105b...@mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5757) Need ref-guide coverage of using Solr(Cloud) with SSL
[ https://issues.apache.org/jira/browse/SOLR-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14045475#comment-14045475 ] Steve Davids commented on SOLR-5757: bq. Alternatively, to require clients to authenticate, you can set the jetty.ssl.clientAuth system property to true (default is false): Perhaps we should mention that this is the two-way SSL mechanism. Also, it may be worth pointing out that this won't work with self-signed certs as HttpClient needs to be configured to use the TrustSelfSignedStrategy at which point a Solr property does not currently exist to perform this configuration. Need ref-guide coverage of using Solr(Cloud) with SSL - Key: SOLR-5757 URL: https://issues.apache.org/jira/browse/SOLR-5757 Project: Solr Issue Type: Task Components: documentation Reporter: Hoss Man Assignee: Steve Rowe Fix For: 4.9, 5.0 need doc updates explaining: * basics of running SolrCloud with SSL * how to setup/config client auth certs for bi-directional auth -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5757) Need ref-guide coverage of using Solr(Cloud) with SSL
[
https://issues.apache.org/jira/browse/SOLR-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14045507#comment-14045507
]
Steve Davids commented on SOLR-5757:
Interesting, when writing unit tests in order to get the two-way SSL to work I
needed to configure the HttpClient to use the TrustSelfSignedStrategy as seen
in {code}SSLTestConfig.buildSSLContext(){code} The only noticeable difference
is that you are generating a new key vice using the key distributed located at
solr/example/etc/solrtest.keystore generated via the
create-solrtest.keystore.sh script (though it looks the same). I will need to
take a closer and will follow the steps you have specified to see if I have an
issue with the hand shake failing for internal Solr Cloud HTTPS requests.
Need ref-guide coverage of using Solr(Cloud) with SSL
-
Key: SOLR-5757
URL: https://issues.apache.org/jira/browse/SOLR-5757
Project: Solr
Issue Type: Task
Components: documentation
Reporter: Hoss Man
Assignee: Steve Rowe
Fix For: 4.9, 5.0
need doc updates explaining:
* basics of running SolrCloud with SSL
* how to setup/config client auth certs for bi-directional auth
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6207) SolrQueryRequestBase.getParamString() is misleading if an updated value is set
Steve Davids created SOLR-6207: -- Summary: SolrQueryRequestBase.getParamString() is misleading if an updated value is set Key: SOLR-6207 URL: https://issues.apache.org/jira/browse/SOLR-6207 Project: Solr Issue Type: Bug Reporter: Steve Davids Fix For: 4.10 SolrQueryRequestBase.getParamString() is printing out the original request parameters instead of the current request parameter values which can be misleading. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6207) SolrQueryRequestBase.getParamString() is misleading if an updated value is set
[ https://issues.apache.org/jira/browse/SOLR-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-6207: --- Attachment: SOLR-6207.patch Attached trivial patch. SolrQueryRequestBase.getParamString() is misleading if an updated value is set -- Key: SOLR-6207 URL: https://issues.apache.org/jira/browse/SOLR-6207 Project: Solr Issue Type: Bug Reporter: Steve Davids Fix For: 4.10 Attachments: SOLR-6207.patch SolrQueryRequestBase.getParamString() is printing out the original request parameters instead of the current request parameter values which can be misleading. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5986) Don't allow runaway queries from harming Solr cluster health or search performance
[ https://issues.apache.org/jira/browse/SOLR-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-5986: --- Description: The intent of this ticket is to have all distributed search requests stop wasting CPU cycles on requests that have already timed out or are so complicated that they won't be able to execute. We have come across a case where a nasty wildcard query within a proximity clause was causing the cluster to enumerate terms for hours even though the query timeout was set to minutes. This caused a noticeable slowdown within the system which made us restart the replicas that happened to service that one request, the worst case scenario are users with a relatively low zk timeout value will have nodes start dropping from the cluster due to long GC pauses. [~amccurry] Built a mechanism into Apache Blur to help with the issue in BLUR-142 (see commit comment for code, though look at the latest code on the trunk for newer bug fixes). Solr should be able to either prevent these problematic queries from running by some heuristic (possibly estimated size of heap usage) or be able to execute a thread interrupt on all query threads once the time threshold is met. This issue mirrors what others have discussed on the mailing list: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200903.mbox/%3c856ac15f0903272054q2dbdbd19kea3c5ba9e105b...@mail.gmail.com%3E was: The intent of this ticket is to have all distributed search requests stop wasting CPU cycles on requests that have already timed out. We have come across a case where a nasty wildcard query within a proximity clause was causing the cluster to enumerate terms for hours even though the query timeout was set to minutes. This caused a noticeable slowdown within the system which made us restart the replicas that happened to service that one request. [~amccurry] Built a mechanism into Apache Blur to help with the issue in BLUR-142 (see commit comment for code, though look at the latest code on the trunk for newer bug fixes). Ideally Solr will distribute the timeout request parameter and automatically interrupt all query threads once the threshold is met. This issue mirrors what others have discussed on the mailing list: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200903.mbox/%3c856ac15f0903272054q2dbdbd19kea3c5ba9e105b...@mail.gmail.com%3E Summary: Don't allow runaway queries from harming Solr cluster health or search performance (was: When a query times out all distributed searches shouldn't continue on until completion) As a follow up, we are still experiencing frequent issues with this specific issue which is getting more and more frequent. Upon further research it looks like this is a somewhat common problem that afflicts various Lucene community members. As noted in the description Apache Blur has implemented a mechanism for coping but more recently Elastic Search has also implemented their own solution which performs an up-front query heap estimation and will pull the circuit breaker if it exceeds a threshold, thus not allowing the query to crash their cluster. Documentation: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/index-modules-fielddata.html#fielddata-circuit-breaker Ticket: https://github.com/elasticsearch/elasticsearch/issues/2929 https://github.com/elasticsearch/elasticsearch/pull/4261 If anyone has any suggestions on how we can limp by for the time being that would also be greatly appreciated (unfortunately our user base needs to keep using nested proximity wildcards but willing to have mechanisms in place to a kill subset of problematic queries). Don't allow runaway queries from harming Solr cluster health or search performance -- Key: SOLR-5986 URL: https://issues.apache.org/jira/browse/SOLR-5986 Project: Solr Issue Type: Improvement Components: search Reporter: Steve Davids Priority: Critical Fix For: 4.9 The intent of this ticket is to have all distributed search requests stop wasting CPU cycles on requests that have already timed out or are so complicated that they won't be able to execute. We have come across a case where a nasty wildcard query within a proximity clause was causing the cluster to enumerate terms for hours even though the query timeout was set to minutes. This caused a noticeable slowdown within the system which made us restart the replicas that happened to service that one request, the worst case scenario are users with a relatively low zk timeout value will have nodes start dropping from the cluster due to long GC pauses. [~amccurry] Built a mechanism into Apache Blur to help with the issue in BLUR-142 (see commit
[jira] [Commented] (SOLR-5994) Add Jetty configuration to serve JavaDocs
[ https://issues.apache.org/jira/browse/SOLR-5994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13976367#comment-13976367 ] Steve Davids commented on SOLR-5994: It feels somewhat odd to make a head request to see if the local javadoc is available, then if it isn't swap it out with the javadocs on Apache's website - I am sure if someone had firebug open there would be a few question marks going through their mind watching the traffic. I do like the idea of providing the link in the admin-extra (or something similar jetty context page?) that can be easily thrown away/overwritten when it actually comes to your production deployment. Add Jetty configuration to serve JavaDocs -- Key: SOLR-5994 URL: https://issues.apache.org/jira/browse/SOLR-5994 Project: Solr Issue Type: Improvement Components: documentation, web gui Affects Versions: 4.7 Reporter: Alexandre Rafalovitch Priority: Minor Labels: javadoc Fix For: 5.0 Attachments: SOLR-5994.patch, javadoc-jetty-context.xml It's possible to add another context file for Jetty that will serve Javadocs from the server. This avoids some Javascript issues, makes the documentation more visible, and opens the door for better integration in the future. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5776) Look at speeding up using SSL with tests.
[ https://issues.apache.org/jira/browse/SOLR-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973567#comment-13973567 ] Steve Davids commented on SOLR-5776: Looks like there are a few issues with the previous checkin: 1) SolrTestCase4j has hard coded trySsl = true vice the random boolean value 2) JettySolrRunner is trying to configure the SecureRandomAlgorithm but that value isn't set in the SSLTestConfig thus that algorithm isn't actually being set in Jetty. You may want to make the buildSSLContext method Public and set the Jetty SSLContext with the return value which will then use the NullSecureRandom. Look at speeding up using SSL with tests. - Key: SOLR-5776 URL: https://issues.apache.org/jira/browse/SOLR-5776 Project: Solr Issue Type: Test Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.9, 5.0 Attachments: SOLR-5776.patch, SOLR-5776.patch We have to disable SSL on a bunch of tests now because it appears to sometime be ridiculously slow - especially in slow envs (I never see timeouts on my machine). I was talking to Robert about this, and he mentioned that there might be some settings we could change to speed it up. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5776) Look at speeding up using SSL with tests.
[ https://issues.apache.org/jira/browse/SOLR-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973610#comment-13973610 ] Steve Davids commented on SOLR-5776: It is important to note that the SSLTestConfig buildSSLContext is currently only being used in the context of building HttpClient on the client side, not on the Jetty side. So you will still be susceptible to the NativePRNG SecureRandom instance on the server side (and thus the long pauses). Look at speeding up using SSL with tests. - Key: SOLR-5776 URL: https://issues.apache.org/jira/browse/SOLR-5776 Project: Solr Issue Type: Test Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.9, 5.0 Attachments: SOLR-5776.patch, SOLR-5776.patch We have to disable SSL on a bunch of tests now because it appears to sometime be ridiculously slow - especially in slow envs (I never see timeouts on my machine). I was talking to Robert about this, and he mentioned that there might be some settings we could change to speed it up. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5757) Need ref-guide coverage of using Solr(Cloud) with SSL
[
https://issues.apache.org/jira/browse/SOLR-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973678#comment-13973678
]
Steve Davids commented on SOLR-5757:
Just to get some initial notes on the record:
* See the example jetty.xml file to see how to configure Jetty w/ SSL in the
SslSelectChannelConnector
** Set needClientAuth to true to enable two-way SSL, can be configured in the
example via -Djetty.ssl.clientAuth=true
* Set the URL Scheme in ZooKeeper to let the cluster know that it needs to use
https when building the various replica URLs
** ZK Command: {code}./zkcli.sh -zkhost localhost:9983 -cmd put
/clusterprops.json
{\urlScheme\:\https\}{code}
** Note: possible improvement is to provide some bootstrapping mechanism?
* Set the javax.net.ssl.* system properties to configure SSL for HttpClient,
this will also allow two-way SSL to work...
** javax.net.ssl.keyStore, javax.net.ssl.keyStorePassword,
javax.net.ssl.trustStore, javax.net.ssl.trustStorePassword
* Clients can use a generic certificate and use the ALLOW_ALL_HOSTNAME_VERIFIER
(SOLR-5868) by setting the solr.ssl.checkPeerName system property
(-Dsolr.ssl.checkPeerName=true). This makes it so clients don't need to specify
*every* machine in the cluster in the alt subject names within the certificate
(as it may change and be a pain to manage).
Need ref-guide coverage of using Solr(Cloud) with SSL
-
Key: SOLR-5757
URL: https://issues.apache.org/jira/browse/SOLR-5757
Project: Solr
Issue Type: Task
Components: documentation
Reporter: Hoss Man
Assignee: Mark Miller
Fix For: 4.9, 5.0
need doc updates explaining:
* basics of running SolrCloud with SSL
* how to setup/config client auth certs for bi-directional auth
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5776) Look at speeding up using SSL with tests.
[ https://issues.apache.org/jira/browse/SOLR-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973684#comment-13973684 ] Steve Davids commented on SOLR-5776: bq. ...perhaps because I was not taking care of the issue on the client side - which seems to be where the real trouble point is? That seems strange, I thought it *should* be a problem on both sides, though I'm definitely not an expert on this subject, nor have I come across the problem of trying to generate a SecureRandom value out in the wild. Look at speeding up using SSL with tests. - Key: SOLR-5776 URL: https://issues.apache.org/jira/browse/SOLR-5776 Project: Solr Issue Type: Test Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.9, 5.0 Attachments: SOLR-5776.patch, SOLR-5776.patch We have to disable SSL on a bunch of tests now because it appears to sometime be ridiculously slow - especially in slow envs (I never see timeouts on my machine). I was talking to Robert about this, and he mentioned that there might be some settings we could change to speed it up. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5994) Add Jetty configuration to serve JavaDocs
[ https://issues.apache.org/jira/browse/SOLR-5994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973693#comment-13973693 ] Steve Davids commented on SOLR-5994: The link on the Admin UI is great in theory only in the context of users pulling up Solr from the solr examples distribution. Out in production environments it would be extremely odd that users will be pushing out the javadocs with the rest of their configuration, thus resulting in an aggravating 404 page. I believe Jetty will show the various contexts when hitting the root ie http://localhost:8080 -- this would then show you links for /javadoc /solr which would probably be sufficient. Add Jetty configuration to serve JavaDocs -- Key: SOLR-5994 URL: https://issues.apache.org/jira/browse/SOLR-5994 Project: Solr Issue Type: Improvement Components: documentation, web gui Affects Versions: 4.7 Reporter: Alexandre Rafalovitch Priority: Minor Labels: javadoc Fix For: 5.0 Attachments: javadoc-jetty-context.xml It's possible to add another context file for Jetty that will serve Javadocs from the server. This avoids some Javascript issues, makes the documentation more visible, and opens the door for better integration in the future. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5776) Look at speeding up using SSL with tests.
[ https://issues.apache.org/jira/browse/SOLR-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-5776: --- Attachment: SOLR-5776.patch Attached a patch that tells Jetty to use the SHA1PRNG secure random algorithm for tests. Look at speeding up using SSL with tests. - Key: SOLR-5776 URL: https://issues.apache.org/jira/browse/SOLR-5776 Project: Solr Issue Type: Test Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.9, 5.0 Attachments: SOLR-5776.patch, SOLR-5776.patch We have to disable SSL on a bunch of tests now because it appears to sometime be ridiculously slow - especially in slow envs (I never see timeouts on my machine). I was talking to Robert about this, and he mentioned that there might be some settings we could change to speed it up. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
