You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Jayson Minard (JIRA)" <ji...@apache.org> on 2014/11/12 03:02:35 UTC
[jira] [Comment Edited] (SOLR-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14207518#comment-14207518 ]
Jayson Minard edited comment on SOLR-4792 at 11/12/14 2:01 AM:
---------------------------------------------------------------
This is unnecessary change. A WAR can be shipped and still be used in embedded runner while still retaining the ability to be configured and used in an application server.
See: https://github.com/bremeld/solr-undertow
Uses Undertow.io to create an easy to configure Solr (and SolrCloud) server by extracting the WAR to create the web site and the classpath then executes Solr embedded with a high performance server. And yet still retains the ability to add additional functionality such as request rate limiting (released), auth, ssl, other port configures, and other features in the future due to capabilities of Undertow.
I think the problem with WAR in the past is that there is little reasonable documentation for current Jetty, current Tomcat, current Wildfly for Solr, and most old resources on the internet are very old and dated on the topics for Solr. A small Doc effort, and killing these old outdated resources would go a long way to fixing that issue.
Regardless, there are other options that keep a WAR while providing a simple to configure and start server that is as fast or faster than Jetty. (Solr-Undertow uses far fewer threads for the same throughput for one, and its configuration is more sane than the default Jetty configuration has been in the past)
I am the author of Solr-Undertow but also a user of Solr with experience in almost every app server and deployment model possible; so this small project was a way to fix the problem while retaining war deployment.
WAR deployment could use a simpler model and less environment variables. Maybe one -D system property to identify a configuration file (URL, that can be downloaded) would be a better model and easier to add to most Application server startups.
was (Author: jayson.minard):
This is unnecessary change. A WAR can be shipped and still be used in embedded runner while still retaining the ability to be configured and used in an application server.
See: https://github.com/bremeld/solr-undertow
Uses Undertow.io to create an easy to configure Solr (and SolrCloud) server by extracting the WAR to create the web site and the classpath then executes Solr embedded with a high performance server. And yet still retains the ability to add additional functionality such as request rate limiting (released), auth, ssl, other port configures, and other features in the future.
I think the problem with WAR in the past is that there is little reasonable documentation for current Jetty, current Tomcat, current Wildfly for Solr, and most old resources on the internet are very old and dated on the topics for Solr. A small Doc effort, and killing these old outdated resources would go a long way to fixing that issue.
> stop shipping a war in 5.0
> --------------------------
>
> Key: SOLR-4792
> URL: https://issues.apache.org/jira/browse/SOLR-4792
> Project: Solr
> Issue Type: Task
> Components: Build
> Reporter: Robert Muir
> Assignee: Robert Muir
> Fix For: Trunk
>
> Attachments: SOLR-4792.patch
>
>
> see the vote on the developer list.
> This is the first step: if we stop shipping a war then we are free to do anything we want.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org