Details

    • Type: Task Task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0-ALPHA
    • Component/s: None
    • Labels:
      None

      Description

      Solr is currently tested (and bundled) with a patched jetty-6 version.

      Ideally we can release and test with a standard version.

      Jetty-6 (at codehaus) is just maintenance now. New development and improvements are now hosted at eclipse. Assuming performance is equivalent, I think we should switch to Jetty 8.

        Issue Links

          Activity

          Hide
          Scott Stults added a comment -

          It looks like the SolrJetty wiki page needs some love. Should that be tracked here or in a separate issue?

          Show
          Scott Stults added a comment - It looks like the SolrJetty wiki page needs some love. Should that be tracked here or in a separate issue?
          Hide
          Massimo Carro added a comment -

          I use solr 4 with jetty 8 : highlight inside qt definition doesn't go.

          Show
          Massimo Carro added a comment - I use solr 4 with jetty 8 : highlight inside qt definition doesn't go.
          Hide
          Bill Bell added a comment -

          Can you point to the JENKINS issue? If there is not one, we should post an issue on the JENKINS JIRA...

          Are you saying that it might be isolated to JENKINS? I have been avoiding NIO - maybe for the wrong reasons. I heard that BIO ran better on Windows 2008 ?

          (DOn't ask why we are running SOLR on Windows).

          Show
          Bill Bell added a comment - Can you point to the JENKINS issue? If there is not one, we should post an issue on the JENKINS JIRA... Are you saying that it might be isolated to JENKINS? I have been avoiding NIO - maybe for the wrong reasons. I heard that BIO ran better on Windows 2008 ? (DOn't ask why we are running SOLR on Windows).
          Hide
          Yonik Seeley added a comment -

          From that link, it looks like it should probably be:

              <Call name="setAttribute">
                <Arg>org.eclipse.jetty.server.Request.maxFormContentSize</Arg>
                <Arg>200000</Arg>
              </Call>
          

          Can anyone test and confirm this works?

          These are the same settings we had for jetty 6, but I do not know if this is still the best choice. In particular, I'm not sure about the .bio.SocketConnector vs .nio.SelectChannelConnector

          The NIO connector was causing intermittent failures on Jenkins. I have no idea if the bugs were ever found/fixed in Jetty land - but it's a risk. It would be nice to move to the NIO connector if it is now stable though, since it could possibly allow for better logging/debugging (i.e. if we can specify our own thread pool to handle requests such that we can tell different jetty instances apart during logging).

          Show
          Yonik Seeley added a comment - From that link, it looks like it should probably be: <Call name= "setAttribute" > <Arg>org.eclipse.jetty.server.Request.maxFormContentSize</Arg> <Arg>200000</Arg> </Call> Can anyone test and confirm this works? These are the same settings we had for jetty 6, but I do not know if this is still the best choice. In particular, I'm not sure about the .bio.SocketConnector vs .nio.SelectChannelConnector The NIO connector was causing intermittent failures on Jenkins. I have no idea if the bugs were ever found/fixed in Jetty land - but it's a risk. It would be nice to move to the NIO connector if it is now stable though, since it could possibly allow for better logging/debugging (i.e. if we can specify our own thread pool to handle requests such that we can tell different jetty instances apart during logging).
          Hide
          Bill Bell added a comment - - edited

          For sharding we probably want to add back the equivalent for MAX POST size.

              <!-- Increase the maximum POST size to 1 MB to be able to handle large shard requests -->
              <Call class="java.lang.System" name="setProperty">
                <Arg>org.mortbay.jetty.Request.maxFormContentSize</Arg>
                <Arg>1000000</Arg>
              </Call>
          

          To something like:

             <Call class="java.lang.System" name="setProperty">
                <Arg>org.eclipse.jetty.Request.maxFormContentSize</Arg>
                <Arg>1000000</Arg>
              </Call>
          

          See http://wiki.eclipse.org/Jetty/Howto/Configure_Form_Size#Changing_the_Maximum_Form_Size_for_All_Apps_on_a_Server

          Show
          Bill Bell added a comment - - edited For sharding we probably want to add back the equivalent for MAX POST size. <!-- Increase the maximum POST size to 1 MB to be able to handle large shard requests --> <Call class= "java.lang. System " name= "setProperty" > <Arg>org.mortbay.jetty.Request.maxFormContentSize</Arg> <Arg>1000000</Arg> </Call> To something like: <Call class= "java.lang. System " name= "setProperty" > <Arg>org.eclipse.jetty.Request.maxFormContentSize</Arg> <Arg>1000000</Arg> </Call> See http://wiki.eclipse.org/Jetty/Howto/Configure_Form_Size#Changing_the_Maximum_Form_Size_for_All_Apps_on_a_Server
          Hide
          Bill Bell added a comment -

          Is this back ported to 3x? There is also a BIO issue in Jetty 6

          https://jira.codehaus.org/browse/JETTY-1458

          The ticket for 3159 only says Solr 4.

          Show
          Bill Bell added a comment - Is this back ported to 3x? There is also a BIO issue in Jetty 6 https://jira.codehaus.org/browse/JETTY-1458 The ticket for 3159 only says Solr 4.
          Hide
          Ryan McKinley added a comment -

          We can open a new issue for any subsequent problems

          Show
          Ryan McKinley added a comment - We can open a new issue for any subsequent problems
          Hide
          Stefan Matheis (steffkes) added a comment -

          Another little glitch i just noticed is that aparently with the new jetty configs JSP support isn't enabled? loading http://localhost:8983/solr/ works fine, but http://localhost:8983/solr/admin/dataimport.jsp gives a 500 error "JSP support not configured"

          Yepp, just created SOLR-3234 for that. We have just missed them, while sorting out all JSP-Files in SOLR-3202. They should be no longer required ,since we use now Handlers and Servlets for all the UI related stuff.

          Show
          Stefan Matheis (steffkes) added a comment - Another little glitch i just noticed is that aparently with the new jetty configs JSP support isn't enabled? loading http://localhost:8983/solr/ works fine, but http://localhost:8983/solr/admin/dataimport.jsp gives a 500 error "JSP support not configured" Yepp, just created SOLR-3234 for that. We have just missed them, while sorting out all JSP-Files in SOLR-3202 . They should be no longer required ,since we use now Handlers and Servlets for all the UI related stuff.
          Hide
          Ryan McKinley added a comment -

          They had a real 8.1.2 release... and I upgraded the .jar files in revision: 1299325

          Show
          Ryan McKinley added a comment - They had a real 8.1.2 release... and I upgraded the .jar files in revision: 1299325
          Hide
          Steve Rowe added a comment -

          Wierdly, I don't see an annoucement for v8.1.2

          Sorry .. poor wording on my part: the issue is marked fixed in 8.1.2 but the jetty Jira system lists 8.1.2 as unreleased (ie: fixed on jetty's 8.1 branch for hte next release i guess)

          Well, the weirdness from my perspective is that 8.1.2 is downloadable and marked as a release: http://download.eclipse.org/jetty/

          Show
          Steve Rowe added a comment - Wierdly, I don't see an annoucement for v8.1.2 Sorry .. poor wording on my part: the issue is marked fixed in 8.1.2 but the jetty Jira system lists 8.1.2 as unreleased (ie: fixed on jetty's 8.1 branch for hte next release i guess) Well, the weirdness from my perspective is that 8.1.2 is downloadable and marked as a release: http://download.eclipse.org/jetty/
          Hide
          Hoss Man added a comment -

          Wierdly, I don't see an annoucement for v8.1.2

          Sorry .. poor wording on my part: the issue is marked fixed in 8.1.2 but the jetty Jira system lists 8.1.2 as unreleased (ie: fixed on jetty's 8.1 branch for hte next release i guess)

          Another little glitch i just noticed is that aparently with the new jetty configs JSP support isn't enabled? loading http://localhost:8983/solr/ works fine, but http://localhost:8983/solr/admin/dataimport.jsp gives a 500 error "JSP support not configured"

          Show
          Hoss Man added a comment - Wierdly, I don't see an annoucement for v8.1.2 Sorry .. poor wording on my part: the issue is marked fixed in 8.1.2 but the jetty Jira system lists 8.1.2 as unreleased (ie: fixed on jetty's 8.1 branch for hte next release i guess) — Another little glitch i just noticed is that aparently with the new jetty configs JSP support isn't enabled? loading http://localhost:8983/solr/ works fine, but http://localhost:8983/solr/admin/dataimport.jsp gives a 500 error "JSP support not configured"
          Hide
          Steve Rowe added a comment -

          apparently fixed in 8.1.2 ?

          Wierdly, I don't see an annoucement for v8.1.2 on the jetty-announce list archives (unlike v8.1.1, which was announced), and the Maven artifacts haven't shown up in Maven central (again, unlike the v8.1.1 artifacts).

          The full 8.1.2 version name is 8.1.2.v20120302, where AFAICT the suffix is the release date, six days ago.

          Unlike 8.1.2, the Maven Central artifacts for 8.1.0 and 8.1.1 are dated one day after the (assumed) release date from the version number.

          Show
          Steve Rowe added a comment - apparently fixed in 8.1.2 ? Wierdly, I don't see an annoucement for v8.1.2 on the jetty-announce list archives (unlike v8.1.1, which was announced), and the Maven artifacts haven't shown up in Maven central (again, unlike the v8.1.1 artifacts). The full 8.1.2 version name is 8.1.2.v20120302, where AFAICT the suffix is the release date, six days ago. Unlike 8.1.2, the Maven Central artifacts for 8.1.0 and 8.1.1 are dated one day after the (assumed) release date from the version number.
          Hide
          Shawn Heisey added a comment -

          The pile of config files in etc are for the various features you can enable – this just includes the ones I think we need

          I checked out trunk from SVN and took a look at the example etc directory. It only includes jetty.xml and webdefault.xml, so once things on this issue have settled down, I'll compare my config with yours and go ahead with an upgrade on my test server.

          Show
          Shawn Heisey added a comment - The pile of config files in etc are for the various features you can enable – this just includes the ones I think we need I checked out trunk from SVN and took a look at the example etc directory. It only includes jetty.xml and webdefault.xml, so once things on this issue have settled down, I'll compare my config with yours and go ahead with an upgrade on my test server.
          Hide
          Hoss Man added a comment -

          https://jira.codehaus.org/browse/JETTY-1489 - apparently fixed in 8.1.2 ?

          Show
          Hoss Man added a comment - https://jira.codehaus.org/browse/JETTY-1489 - apparently fixed in 8.1.2 ?
          Hide
          Hoss Man added a comment -

          FWIW: on trunk, using an svn checkout, and runing "java -jar start.jar" i'm getting the following error in the jetty logging after solr starts up...

          2012-03-08 15:16:09.382:WARN:oejw.WebAppContext:Failed startup of context o.e.j.w.WebAppContext{/.svn,file:/home/hossman/lucene/dev/solr/example/webapps/.svn/},/home/hossman/lucene/dev/solr/example/webapps/.svn
          java.lang.StringIndexOutOfBoundsException: String index out of range: 0
          	at java.lang.String.charAt(String.java:686)
          	at org.eclipse.jetty.util.log.StdErrLog.condensePackageString(StdErrLog.java:210)
          	at org.eclipse.jetty.util.log.StdErrLog.<init>(StdErrLog.java:105)
          	at org.eclipse.jetty.util.log.StdErrLog.<init>(StdErrLog.java:97)
          	at org.eclipse.jetty.util.log.StdErrLog.newLogger(StdErrLog.java:569)
          	at org.eclipse.jetty.util.log.AbstractLogger.getLogger(AbstractLogger.java:21)
          	at org.eclipse.jetty.util.log.Log.getLogger(Log.java:438)
          	at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:677)
          	at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:454)
          	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
          	at org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:36)
          	at org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:183)
          	at org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:491)
          	at org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:138)
          	at org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:142)
          	at org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:53)
          	at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:604)
          	at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:535)
          	at org.eclipse.jetty.util.Scanner.scan(Scanner.java:398)
          	at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:332)
          	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
          	at org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:118)
          	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
          	at org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:552)
          	at org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:227)
          	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
          	at org.eclipse.jetty.util.component.AggregateLifeCycle.doStart(AggregateLifeCycle.java:58)
          	at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:53)
          	at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:91)
          	at org.eclipse.jetty.server.Server.doStart(Server.java:263)
          	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
          	at org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1215)
          	at java.security.AccessController.doPrivileged(Native Method)
          	at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1138)
          	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          	at java.lang.reflect.Method.invoke(Method.java:597)
          	at org.eclipse.jetty.start.Main.invokeMain(Main.java:457)
          	at org.eclipse.jetty.start.Main.start(Main.java:602)
          	at org.eclipse.jetty.start.Main.main(Main.java:82)
          

          ...solr is functioning just fine, but it seems like something has changed subtley in either how jetty handles the webapps dir, or how we have it configured to handle the webapps dir, such that it is trying to load .svn as a webapp.

          Show
          Hoss Man added a comment - FWIW: on trunk, using an svn checkout, and runing "java -jar start.jar" i'm getting the following error in the jetty logging after solr starts up... 2012-03-08 15:16:09.382:WARN:oejw.WebAppContext:Failed startup of context o.e.j.w.WebAppContext{/.svn,file:/home/hossman/lucene/dev/solr/example/webapps/.svn/},/home/hossman/lucene/dev/solr/example/webapps/.svn java.lang.StringIndexOutOfBoundsException: String index out of range: 0 at java.lang.String.charAt(String.java:686) at org.eclipse.jetty.util.log.StdErrLog.condensePackageString(StdErrLog.java:210) at org.eclipse.jetty.util.log.StdErrLog.<init>(StdErrLog.java:105) at org.eclipse.jetty.util.log.StdErrLog.<init>(StdErrLog.java:97) at org.eclipse.jetty.util.log.StdErrLog.newLogger(StdErrLog.java:569) at org.eclipse.jetty.util.log.AbstractLogger.getLogger(AbstractLogger.java:21) at org.eclipse.jetty.util.log.Log.getLogger(Log.java:438) at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:677) at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:454) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:36) at org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:183) at org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:491) at org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:138) at org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:142) at org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:53) at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:604) at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:535) at org.eclipse.jetty.util.Scanner.scan(Scanner.java:398) at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:332) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:118) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:552) at org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:227) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.eclipse.jetty.util.component.AggregateLifeCycle.doStart(AggregateLifeCycle.java:58) at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:53) at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:91) at org.eclipse.jetty.server.Server.doStart(Server.java:263) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1215) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1138) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.jetty.start.Main.invokeMain(Main.java:457) at org.eclipse.jetty.start.Main.start(Main.java:602) at org.eclipse.jetty.start.Main.main(Main.java:82) ...solr is functioning just fine, but it seems like something has changed subtley in either how jetty handles the webapps dir, or how we have it configured to handle the webapps dir, such that it is trying to load .svn as a webapp.
          Hide
          Steve Rowe added a comment -

          Maven configuration: [...] Committing shortly.

          Done: r1298247

          Show
          Steve Rowe added a comment - Maven configuration: [...] Committing shortly. Done: r1298247
          Hide
          Steve Rowe added a comment -

          Maven configuration:

          1. Removed from top-level POM the installation to local Maven repository of optional/test-only Jetty artifacts.
          2. Switched Jetty dependencies to v8.1.1 Maven Central artifacts
          3. Switched Servlet API dependecy to Jetty Orbit jar (this will need to be fixed if/when the 2.4 servlet jar is put back into solr/lib/

          Committing shortly.

          Show
          Steve Rowe added a comment - Maven configuration: Removed from top-level POM the installation to local Maven repository of optional/test-only Jetty artifacts. Switched Jetty dependencies to v8.1.1 Maven Central artifacts Switched Servlet API dependecy to Jetty Orbit jar (this will need to be fixed if/when the 2.4 servlet jar is put back into solr/lib/ Committing shortly.
          Hide
          Uwe Schindler added a comment -

          This was also the reason why before Ryans commit in the lib/ folder was a genric servlet-api-2.4.jar while in the example there was the jetty-supplied.

          For compiling the solr source code we should in all cases use 2.4, otherwise we cannot gurantee that we are still compatible with older servlet containers like JBoss or Tomcat 6.

          Show
          Uwe Schindler added a comment - This was also the reason why before Ryans commit in the lib/ folder was a genric servlet-api-2.4.jar while in the example there was the jetty-supplied. For compiling the solr source code we should in all cases use 2.4, otherwise we cannot gurantee that we are still compatible with older servlet containers like JBoss or Tomcat 6.
          Hide
          Steve Rowe added a comment -

          Am I missing something?

          Woohoo! Found it!: org.eclipse.jetty.orbit:javax.servlet:3.0.0.v201112011016

          Show
          Steve Rowe added a comment - Am I missing something? Woohoo! Found it!: org.eclipse.jetty.orbit:javax.servlet:3.0.0.v201112011016
          Hide
          Uwe Schindler added a comment - - edited

          That should not matter as the servlet-api.jar is just a interface hull, version is irrelevant. To compile solr, an older servlet API would be even better as requirement, so the WAR is enforced to also run in older tomcats

          So I would revert the jar file in the lib/ folder for compiling of solr to 2.4 and only use the 3.0 one for executing jetty8 in the example or when running tests.

          Show
          Uwe Schindler added a comment - - edited That should not matter as the servlet-api.jar is just a interface hull, version is irrelevant. To compile solr, an older servlet API would be even better as requirement, so the WAR is enforced to also run in older tomcats So I would revert the jar file in the lib/ folder for compiling of solr to 2.4 and only use the 3.0 one for executing jetty8 in the example or when running tests.
          Hide
          Steve Rowe added a comment -

          Hi Ryan,

          I'm trying to fix the Maven build to use Jetty 8, and I see that you've upgraded servlet-api jar to v3.0, but I can't find that version in the Maven Central repository. The two closest I found are javax.servlet:javax-servlet.api:3.0.1 and javax.servlet:servlet-api:3.0-alpha-1. Am I missing something?

          If you don't know of a 3.0 Maven artifact, can we upgrade to the 3.0.1 artifact in Maven central? (I did not test this myself.)

          Show
          Steve Rowe added a comment - Hi Ryan, I'm trying to fix the Maven build to use Jetty 8, and I see that you've upgraded servlet-api jar to v3.0, but I can't find that version in the Maven Central repository. The two closest I found are javax.servlet:javax-servlet.api:3.0.1 and javax.servlet:servlet-api:3.0-alpha-1 . Am I missing something? If you don't know of a 3.0 Maven artifact, can we upgrade to the 3.0.1 artifact in Maven central? (I did not test this myself.)
          Hide
          Ryan McKinley added a comment -

          is 8.x just stable enough?

          I'm confident the server is stable. I am not confident we have the most appropriate settings in solr/example/etc/jetty.xml

          These are the same settings we had for jetty 6, but I do not know if this is still the best choice. In particular, I'm not sure about the .bio.SocketConnector vs .nio.SelectChannelConnector

          Uwe: to backport, we can use the same setup (jetty 8) but need to add in the JSP jar files and change docs about starting the example. Unlike the commons-csv issue, I am not concerned about the patched dependency here because if someone wants to use a different jetty release they can do it and avoid the JAR hell problems.

          Show
          Ryan McKinley added a comment - is 8.x just stable enough? I'm confident the server is stable. I am not confident we have the most appropriate settings in solr/example/etc/jetty.xml These are the same settings we had for jetty 6, but I do not know if this is still the best choice. In particular, I'm not sure about the .bio.SocketConnector vs .nio.SelectChannelConnector Uwe: to backport, we can use the same setup (jetty 8) but need to add in the JSP jar files and change docs about starting the example. Unlike the commons-csv issue, I am not concerned about the patched dependency here because if someone wants to use a different jetty release they can do it and avoid the JAR hell problems.
          Hide
          Robert Muir added a comment -

          I mean i lean towards jetty 8 anyway, because the work is already done

          We can't just look at the stability of jetty itself: having the single jetty version across both trunk/branch_3x
          will mean we have more testing for our integration, which is probably what matters the most anyway.

          Just asking questions.... not an opinion on this patch because i don't have enough knowledge.

          as long as my unicode test passes I am +1!

          Show
          Robert Muir added a comment - I mean i lean towards jetty 8 anyway, because the work is already done We can't just look at the stability of jetty itself: having the single jetty version across both trunk/branch_3x will mean we have more testing for our integration, which is probably what matters the most anyway. Just asking questions.... not an opinion on this patch because i don't have enough knowledge. as long as my unicode test passes I am +1!
          Hide
          Ryan McKinley added a comment -

          weird – I'm guessing that page is out of date... but it is not confidence inspiring!

          Jetty 7/8 have been around since 2009. Work has even started on Jetty 9

          Show
          Ryan McKinley added a comment - weird – I'm guessing that page is out of date... but it is not confidence inspiring! Jetty 7/8 have been around since 2009. Work has even started on Jetty 9
          Hide
          Uwe Schindler added a comment -

          I would strongly suggest to upgrade jetty also on 3.x, otherwise we could get the commons-csv proble a second time here...

          In Jetty 8 the unicode bug seems fixed, not sure about Jetty 7. The work for upgrade should not be so hard here, because Jetty already uses the eclipse package name? so its just a backport with Jetty 7 JARs?

          Show
          Uwe Schindler added a comment - I would strongly suggest to upgrade jetty also on 3.x, otherwise we could get the commons-csv proble a second time here... In Jetty 8 the unicode bug seems fixed, not sure about Jetty 7. The work for upgrade should not be so hard here, because Jetty already uses the eclipse package name? so its just a backport with Jetty 7 JARs?
          Hide
          Robert Muir added a comment -

          As far as 3.x, i don't quite understand http://wiki.eclipse.org/Jetty/Starting/Jetty_Version_Comparison_Table

          What does this mean? does 'experimental' mean like Lucene's FST APIs or does it just mean its only a few years old

          Stable/experimental is not absolute and I'm just curious what opinions are.

          Obviously jetty7 for 3.x is possibly an option?

          but

          Are the unicode bug fixes applied there?
          Ryan already did the work for 8.x, 7.x would cost much more man hours...? is 8.x just stable enough?

          Show
          Robert Muir added a comment - As far as 3.x, i don't quite understand http://wiki.eclipse.org/Jetty/Starting/Jetty_Version_Comparison_Table What does this mean? does 'experimental' mean like Lucene's FST APIs or does it just mean its only a few years old Stable/experimental is not absolute and I'm just curious what opinions are. Obviously jetty7 for 3.x is possibly an option? but Are the unicode bug fixes applied there? Ryan already did the work for 8.x, 7.x would cost much more man hours...? is 8.x just stable enough?
          Hide
          Ryan McKinley added a comment -

          committed to trunk in #1298108

          What are thoughts on porting to 3.x? I am -0 for a few reasons:

          • 3.6 is hopefully soon – I would like to see this test for a while
          • JSP complications
            • requires JDK (not just JRE)
            • the start.jar would need to be run with:
              java -jar start.jar -OPTIONS=jsp
              
          • - - -

          Shawn, to run this with any .war file you can put the .war file in webapps

          The pile of config files in etc are for the various features you can enable – this just includes the ones I think we need

          Show
          Ryan McKinley added a comment - committed to trunk in #1298108 What are thoughts on porting to 3.x? I am -0 for a few reasons: 3.6 is hopefully soon – I would like to see this test for a while JSP complications requires JDK (not just JRE) the start.jar would need to be run with: java -jar start.jar -OPTIONS=jsp - - - Shawn, to run this with any .war file you can put the .war file in webapps The pile of config files in etc are for the various features you can enable – this just includes the ones I think we need
          Hide
          Shawn Heisey added a comment -

          I asked this on the mailing list, got zero response. I would like to know if there are any good reasons to upgrade to Jetty 8 with an older release, specifically 3.5.0. Also, the Jetty 8 distribution has a fair number of config files in etc, but the example Solr only has jetty.xml and webdefault.xml. What sort of recommendations do you have as far as config changes when upgrading?

          I am using the JDK, so I would I be OK with the presence of JSP in the pre-trunk version? Solr is not directly reachable from the outside world, it is used on the internal network by our web application.

          Show
          Shawn Heisey added a comment - I asked this on the mailing list, got zero response. I would like to know if there are any good reasons to upgrade to Jetty 8 with an older release, specifically 3.5.0. Also, the Jetty 8 distribution has a fair number of config files in etc, but the example Solr only has jetty.xml and webdefault.xml. What sort of recommendations do you have as far as config changes when upgrading? I am using the JDK, so I would I be OK with the presence of JSP in the pre-trunk version? Solr is not directly reachable from the outside world, it is used on the internal network by our web application.
          Hide
          Ryan McKinley added a comment -

          Without JSP, jetty 8 can run on JDK or JRE

          Show
          Ryan McKinley added a comment - Without JSP, jetty 8 can run on JDK or JRE
          Hide
          Ryan McKinley added a comment -

          Check:
          https://svn.apache.org/repos/asf/lucene/dev/branches/solr_3159_jetty8/

          Can someone with a benchmarking setup take it for a spin?

          If things look good, I'll sort out the JSP issues.

          Show
          Ryan McKinley added a comment - Check: https://svn.apache.org/repos/asf/lucene/dev/branches/solr_3159_jetty8/ Can someone with a benchmarking setup take it for a spin? If things look good, I'll sort out the JSP issues.
          Hide
          Ryan McKinley added a comment -

          I will make a branch for this so that it is easy to compare the two options.

          One kicker is that JSP in Jetty 7 or 8 requires a JDK, not just the JRE.

          But with progress on the new UI, I think we can drop JSP entirely (good riddance!)

          Show
          Ryan McKinley added a comment - I will make a branch for this so that it is easy to compare the two options. One kicker is that JSP in Jetty 7 or 8 requires a JDK, not just the JRE. But with progress on the new UI, I think we can drop JSP entirely (good riddance!)

            People

            • Assignee:
              Ryan McKinley
              Reporter:
              Ryan McKinley
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development