Mladen Turk wrote:
The removed proxyhost and port are from new hook 'pre_request' that is used to obtain a valid worker and/or balancer for a scheme. It has nothing to do with the way the connection is going to be made.
Cool, this makes sense.
The load balancer if present will decide to which route (worker) the connection is going to be made or return HTTP_SERVER_BUSY, if no further connection to the cluster can be made. If there is no load balancer or it returns DECLINED then the worker will be pulled out from the created set of workers during ProxyPass initialization. I've changed ProxyPass from TAKE12 to RAW_ARGS, so that you can directly initialize connection pool without load balancer (if not required for example).
Cool.
The way that the worker connects to backend depends on scheme handler itself (direct or via proxy). The worker connection itself will be either bound to the client connection (http) or to a backend connection (ajp), and that is also set in scheme handler. I have to figure out how to effectively skip that for ftp scheme handler.
Ideally all three (http, ajp and ftp) should work the same way using a pool: The http method of only reusing the connection if the client reuses the connection is a bit bogus, there really should be a pool.
Ftp is the same - there should be a pool of ftp connections. In the case of ftp, all it needs to do is logout completely but keep the connection open, or - for extra points teaching the pool that some connections require login (like ftp) and to reuse connections wheree the login details match might also be an idea.
Ajp supports a pool anyway.
Making all three the same - ie all three come from a pool would solve this problem I think. The timeout characteristics on each protocol would be different (I would imagine that ajp would have a long lived connection, while http connections would be constrained by the timeout on HTTP keepalives on backend servers) but this is details.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
