Re: cvs commit: jakarta-tomcat-connectors/ajp/proxy mod_proxy.h
[EMAIL PROTECTED] wrote: Log: Remove proxyhost and proxyport from pre_request hook. They are not needed for finding apropriate worker. They are needed for the use of mod_proxy as a forward proxy. The correct way of handling these in the AJP case is to DECLINE the request if proxyhost and proxyport are present, because in this case the request is supposed to be handled by proxy_http. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: cvs commit: jakarta-tomcat-connectors/ajp/proxy mod_proxy.h
[EMAIL PROTECTED] wrote: Log: Remove proxyhost and proxyport from pre_request hook. They are not needed for finding apropriate worker. Reading this again, I see better what is happening. The proxyhost and proxyport are used when a downstream proxy is used, would the balancer ever want to balancer these downstream connections? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
RE: cvs commit: jakarta-tomcat-connectors/ajp/proxy mod_proxy.h
Graham Leggett wrote: > > > Log: > > Remove proxyhost and proxyport from pre_request hook. > > They are not needed for finding apropriate worker. > > They are needed for the use of mod_proxy as a forward proxy. > > The correct way of handling these in the AJP case is to > DECLINE the request if proxyhost and proxyport are present, > because in this case the request is supposed to be handled by > proxy_http. > 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. 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). 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. Regards, MT. smime.p7s Description: S/MIME cryptographic signature
Re: cvs commit: jakarta-tomcat-connectors/ajp/proxy mod_proxy.h
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
RE: cvs commit: jakarta-tomcat-connectors/ajp/proxy mod_proxy.h
Seams that the minotaur is behaving badly, so I'm getting mails with couple of hours delay :) Graham Leggett wrote: > > 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. > They are planned to be the same. I'll make a generic obtain_connection that will be pulled out from the worker (connection pool), with opened socket (if closed). The way how it gets processed further depends on how the scheme handler says. For http connector the connection will be bound to the client connection. It will be returned to the pool (and closing the socket) when their connection id's are different. I have to see how to resolve the case when client breaks the connection. any ideas? For ajp connector the connection will be returned to the pool on request end (AJP can handle different clients trough the same socket). The ftp will probably call 'login' for new connections, but I'll first finish the upper two cases, and deal with ftp later (couple of days :) MT. smime.p7s Description: S/MIME cryptographic signature
