Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-5753

Standalone install does not work with Apache + mod_proxy_ajp + SSL

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved (View Workflow)
    • Major
    • Resolution: Won't Fix
    • core
    • None
    • CentOS release 5.4 (Final)
      2.6.18-164.10.1.el5xen (64 bit)
      java version "1.6.0_16"
      hudson-1.347-1.1
      httpd-2.2.3-31.el5.centos.2

    Description

      I've configured hudson to only use the ajp connector using a command line similar to

      /usr/lib/jvm/java-1.6.0/bin/java -Dcom.sun.akuma.Daemon=daemonized -Djava.awt.headless=true -Xmx64m -DHUDSON_HOME=/space/hudson -jar /usr/lib/hudson/hudson.war --logfile=/var/log/hudson/hudson.log --daemon --prefix=hudson --httpPort=-1 --ajp13Port=8109 --debug=5 --handlerCountMax=10 --handlerCountMaxIdle=0
      

      I'm using the following apache configuration file

          ProxyRequests Off
          ProxyPreserveHost On
      
          <Proxy *>
              Order deny,allow
              Allow from all
          </Proxy>
      
          ProxyPass /hudson ajp://localhost:8109/hudson retry=1
          ProxyPassReverse /hudson ajp://localhost:8109/hudson
      
      

      When accessing https://host/hudson , I get a 503 error page from Apache. The apache logs contain:

      [Wed Feb 24 23:58:04 2010] [error] ajp_read_header: ajp_ilink_receive failed
      [Wed Feb 24 23:58:04 2010] [error] (120006)APR does not understand this error code: proxy: read response failed from (null) (localhost)
      

      while the winstone logs contain:

      [Winstone 2010/02/24 23:58:04] - Error within request handler thread
      java.lang.StringIndexOutOfBoundsException: String index out of range: 1065
              at java.lang.String.checkBounds(String.java:401)
              at java.lang.String.<init>(String.java:442)
              at winstone.ajp13.Ajp13IncomingPacket.readString(Ajp13IncomingPacket.java:275)
              at winstone.ajp13.Ajp13IncomingPacket.parsePacket(Ajp13IncomingPacket.java:189)
              at winstone.ajp13.Ajp13Listener.allocateRequestResponse(Ajp13Listener.java:179)
              at winstone.RequestHandlerThread.run(RequestHandlerThread.java:79)
              at java.lang.Thread.run(Thread.java:619)
      

      It's worth mentioning that this was working with Tomcat 6.0.20 , but stopped working when I tried to move over to the standalone install.

      I've tried various combinations with or without prefix, and the only one which seems to work is ajp without any prefix.

      Attachments

        Issue Links

          Activity

            danielbeck Daniel Beck added a comment -

            Has this issue been fixed as a side effect of the switch to Jetty in 1.535? Anyone else experience Felix's problem?

            danielbeck Daniel Beck added a comment - Has this issue been fixed as a side effect of the switch to Jetty in 1.535? Anyone else experience Felix's problem?

            I was already on 1.558 when I experienced the issue, as mentioned in the previous comment. I haven't tried using AJP since then.

            felixbuenemann Felix Buenemann added a comment - I was already on 1.558 when I experienced the issue, as mentioned in the previous comment. I haven't tried using AJP since then.
            danielbeck Daniel Beck added a comment -

            Jenkins 2.0 upgraded the embedded Jetty-Winstone to Jetty 9, which no longer has AJP support, making this issue obsolete.

            danielbeck Daniel Beck added a comment - Jenkins 2.0 upgraded the embedded Jetty-Winstone to Jetty 9, which no longer has AJP support, making this issue obsolete.
            mirabilos mirabilos added a comment -

            You mean “breaks AJP setups completely”, right?

            There’s a reason we don’t proxy HTTP in the normal case.

            mirabilos mirabilos added a comment - You mean “breaks AJP setups completely”, right? There’s a reason we don’t proxy HTTP in the normal case.
            danielbeck Daniel Beck added a comment -

            You mean “breaks AJP setups completely”, right?

            Yes. We have no control over features implemented in upstream. If you want/need AJP, you can always use a different container.

            danielbeck Daniel Beck added a comment - You mean “breaks AJP setups completely”, right? Yes. We have no control over features implemented in upstream. If you want/need AJP, you can always use a different container.

            People

              Unassigned Unassigned
              rombert Robert Munteanu
              Votes:
              16 Vote for this issue
              Watchers:
              26 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: