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

Standalone install does not work with Apache + mod_proxy_ajp + SSL

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Won't Fix
    • Component/s: core
    • Labels:
      None
    • Environment:
      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
    • Similar Issues:

      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

            Hide
            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?

            Show
            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?
            Hide
            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.

            Show
            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.
            Hide
            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.

            Show
            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.
            Hide
            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.

            Show
            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.
            Hide
            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.

            Show
            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

              • Assignee:
                Unassigned
                Reporter:
                rombert rombert
              • Votes:
                16 Vote for this issue
                Watchers:
                27 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: