Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: 2.1
    • Component/s: Transports
    • Labels:
      None
    • Environment:
      Apache front end with Tomcat connected via the AJP protocol.

      Description

      understanding that this is not support but it does open the ESB up for different uses and different configurations. I guess the ultimate problem I'm having is that I have an apache front end which interfaces with Tomcat via AJP 1.3... Being able to just use the ESB admin port to see/execute the proxy services I create just as if it were running through the NIO listener/sender would allow me to not have to open another port or proxy in the requests through apache...

      This is essential because when trying to proxy in a PKI SSL request it is extremely slow. I have tested this by opening up the admin port and there is a huge increase in performance...

      I guess based on what I explained if the ESB's admin port was not opened is there a way to add an AJP listener/sender? This would solve my problem and still keeps the admin UI/port doing only admin stuff.

        Activity

        Hide
        Hiranya Jayathilaka added a comment -

        It doesn't look like this is going anywhere. There hasn't been much interest on this from the community, but there certainly has been a few comments questioning the usefulness of this feature. If somebody is interested in implementing this please feel free to reopen and start working on it. We might be able to provide any help/assistance needed.

        Show
        Hiranya Jayathilaka added a comment - It doesn't look like this is going anywhere. There hasn't been much interest on this from the community, but there certainly has been a few comments questioning the usefulness of this feature. If somebody is interested in implementing this please feel free to reopen and start working on it. We might be able to provide any help/assistance needed.
        Hide
        Supun Kamburugamuva added a comment -

        As for my understanding, mod_jk is a module to Apache which acts as a content generator. When a request is received by Apache, if it is for Tomcat mod_jk gives this request to Tomcat using a TCP connection. Tomcat has a worker listening for these TCP connections and handles the request as in a normal http request. Only difference is now the request comes via the AJP protocol instead of HTTP.

        Here are some of my thoughts about writing a seperate AJP transport.

        AJP is a protocol tightly coupled to Tomcat. The goal was to deploy Tomcat in to servers like Apache which uses native code. So one part of AJP is inheretly coupled to Tomcat. Idea of AJP is to write the other part (using a module like mod_jk) so that Tomcat can be deployed in to servers like Apache.

        If we write a AJP based transport for Synapse it will be a direct bridge between native code (Apache or IIS) and Synapse. In case of httpd, it cannot handle the request asynchronously. I'm not sure how AJP is implemented inside Tomcat. So I cannot be certain weather a AJP transport can be asynchronous or not.

        Also modules like mod_jk are specifically written for tomcat. If we write a AJP transport, we may need to write both ends of the protocol.

        If we are using a servelet based HTTP transport for Synapse, when Tomcat is deployed in to a server like Apache, we automatically get the benifit of AJP. So I still don't see the benifit of writing a seperate AJP based transport (which can be difficult) vs using a servelet based transport.

        Show
        Supun Kamburugamuva added a comment - As for my understanding, mod_jk is a module to Apache which acts as a content generator. When a request is received by Apache, if it is for Tomcat mod_jk gives this request to Tomcat using a TCP connection. Tomcat has a worker listening for these TCP connections and handles the request as in a normal http request. Only difference is now the request comes via the AJP protocol instead of HTTP. Here are some of my thoughts about writing a seperate AJP transport. AJP is a protocol tightly coupled to Tomcat. The goal was to deploy Tomcat in to servers like Apache which uses native code. So one part of AJP is inheretly coupled to Tomcat. Idea of AJP is to write the other part (using a module like mod_jk) so that Tomcat can be deployed in to servers like Apache. If we write a AJP based transport for Synapse it will be a direct bridge between native code (Apache or IIS) and Synapse. In case of httpd, it cannot handle the request asynchronously. I'm not sure how AJP is implemented inside Tomcat. So I cannot be certain weather a AJP transport can be asynchronous or not. Also modules like mod_jk are specifically written for tomcat. If we write a AJP transport, we may need to write both ends of the protocol. If we are using a servelet based HTTP transport for Synapse, when Tomcat is deployed in to a server like Apache, we automatically get the benifit of AJP. So I still don't see the benifit of writing a seperate AJP based transport (which can be difficult) vs using a servelet based transport.
        Hide
        Andreas Veithen added a comment -

        Mmh, can somebody please clarify this issue and its status. I was assuming that this was about an AJP transport, i.e. an Axis2 transport that implements the AJP protocol, but it seems that in fact it's about tweaking the servlet (and/or commons-http) based transport. Also can somebody rephrase this issue without making reference to WSO2 ESB specific concepts and explain what this issue means for Synapse?

        Show
        Andreas Veithen added a comment - Mmh, can somebody please clarify this issue and its status. I was assuming that this was about an AJP transport, i.e. an Axis2 transport that implements the AJP protocol, but it seems that in fact it's about tweaking the servlet (and/or commons-http) based transport. Also can somebody rephrase this issue without making reference to WSO2 ESB specific concepts and explain what this issue means for Synapse?
        Hide
        Jonathan Holmes added a comment -

        Interestingly enough the new 2.0.1 has solved this issue as explained. You are now able to deploy the ESB to your own tomcat server with an apache front end and instead of using the NIO adapters extend the org.apache.axis2.transport.http.CommonsHTTPTransportSender transport to use the apache httpd certificates. This can be done buy adding your own protocal in the init method.

        Now with that said Andreas bring up a very good point when saying "Why would writing an AJP listener automatically imply having a blocking HTTP transport? Can you substantiate that claim based on your knowledge of the architecture of Apache HTTPD and the way the AJP protocol works?"

        Thanks,
        J

        Show
        Jonathan Holmes added a comment - Interestingly enough the new 2.0.1 has solved this issue as explained. You are now able to deploy the ESB to your own tomcat server with an apache front end and instead of using the NIO adapters extend the org.apache.axis2.transport.http.CommonsHTTPTransportSender transport to use the apache httpd certificates. This can be done buy adding your own protocal in the init method. Now with that said Andreas bring up a very good point when saying "Why would writing an AJP listener automatically imply having a blocking HTTP transport? Can you substantiate that claim based on your knowledge of the architecture of Apache HTTPD and the way the AJP protocol works?" Thanks, J
        Hide
        Eric Hubert added a comment -

        Andreas, some background might be taken from http://wso2.org/forum/thread/3937

        Show
        Eric Hubert added a comment - Andreas, some background might be taken from http://wso2.org/forum/thread/3937
        Hide
        Andreas Veithen added a comment -

        Why would writing an AJP listener automatically imply having a blocking HTTP transport? Can you substantiate that claim based on your knowledge of the architecture of Apache HTTPD and the way the AJP protocol works?

        Independently of that question (non-blocking transports are not essential in every use case) I think that the reporter of this issue gave two key reasons why an AJP listener would be interesting:

        • It would allow to offload the SSL related workload to HTTPD (which will always be faster than any Java based implementation).
        • Security: e.g. would you want to allow direct connections from the public Internet to Synapse?
        Show
        Andreas Veithen added a comment - Why would writing an AJP listener automatically imply having a blocking HTTP transport? Can you substantiate that claim based on your knowledge of the architecture of Apache HTTPD and the way the AJP protocol works? Independently of that question (non-blocking transports are not essential in every use case) I think that the reporter of this issue gave two key reasons why an AJP listener would be interesting: It would allow to offload the SSL related workload to HTTPD (which will always be faster than any Java based implementation). Security: e.g. would you want to allow direct connections from the public Internet to Synapse?
        Hide
        Supun Kamburugamuva added a comment -

        AFAIK AJP allows Tomcat to be deployed in servers like Apache or IIS. In case of Apache, mod_jk is responsible for sending the request to tomcat. But synapse has its own non blocking HTTP transport for handing requests. It only uses Tomcat for admin services. So writing a AJP listenet/sender means implementing a blocking HTTP transport for synapse. So I cannot see a value in developing another HTTP transport which is blocking. Please correct me if I'm wrong.

        Show
        Supun Kamburugamuva added a comment - AFAIK AJP allows Tomcat to be deployed in servers like Apache or IIS. In case of Apache, mod_jk is responsible for sending the request to tomcat. But synapse has its own non blocking HTTP transport for handing requests. It only uses Tomcat for admin services. So writing a AJP listenet/sender means implementing a blocking HTTP transport for synapse. So I cannot see a value in developing another HTTP transport which is blocking. Please correct me if I'm wrong.

          People

          • Assignee:
            Supun Kamburugamuva
            Reporter:
            Jonathan Holmes
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development