[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tomcat-dev
Subject:    Re: Plans for AJP
From:       Mark Thomas <markt () apache ! org>
Date:       2018-06-30 16:51:30
Message-ID: 98169745-c1c1-7af6-5b02-3ad27162a2de () apache ! org
[Download RAW message or body]

On 27/06/18 18:09, Mark Thomas wrote:
> On 27/06/18 17:50, Rainer Jung wrote:

<snip/>

>> So what do people think about:
>>
>> 1) adding a statement to the mod_jk docs, that we don't plan any feature
>> enhancements and suggest users to migrate to mod_proxy_http and the TC
>> HTTP connectors (but what about IIS? I think there are reverse proxy
>> modules there as well?)
> 
> I believe there is, but we should investigate it a little first to see
> what the feature set is. I have a full set of current Windows OSes plus
> IIS VMs. I'm happy to look into this aspect.

I've spent a little bit of time looking at this.

My test environment is:

- 4 * Linux VMs running Tomcat trunk
- Clustered with Delta Manager
- Running a simple test app that reports current node, session ID, etc
- Windows 2016 with IIS 10

Microsoft provide a supported extension, Application Request Routing [1]
that can be used for load-balancing and/or reverse proxying.

After a little experimentation, I was able to configure it to act as a
combined load-balancer and reverse proxy for my 4 node Tomcat cluster.

I did some simple testing, including failover testing, and made the
following notes:

a) You can see the http and https ports to use with the back-end server
   when adding the server to the 'Server Farm'.
b) I haven't yet been able to find a way to view or edit those port
   settings once the 'Server Farm' has been created.
c) Failover and recovery is controlled by configuring the Health Test.
d) There is no concept of retrying a failed required on another node.
e) No pre request ping (neither has mod_proxy_http).
f) Sticky sessions possible via separate ARR cookie. No linkage with
   Tomcat session.


Of all of the above, d) is the one that concerns me the most. It means
that, after a node failure, at least one end-user is going to see a 5xx
response. [2] indicates that the IIS considered implementing retries but
decided not to because "nobody would use it". I disagree. There are some
scenarios where I wouldn't use it but also some where I would.

The question is, does this limitation provide sufficient justification
for continuing to support AJP and the ISAPI redirector?

The argument could be made that we drop AJP and if IIS users complain
about the lack of retries we point them to the IIS team. That does seem
a little harsh.

As a side note, the AJP code on Tomcat side is just under 800 lines of code.

Thoughts?

Mark


[1] https://www.iis.net/downloads/microsoft/application-request-routing
[2]
https://forums.iis.net/t/1161778.aspx?ARR+v2+RC+Monitoring+and+Management+Form+Failed+Request+Stats

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]