RE: cvs commit: jakarta-tomcat-connectors/ajp/proxy proxy_ajp.c
Graham Leggett wrote: > > > Bounding to client connection is not needed(?). > > Since AJP can serve multiple request trough the same > > backend connection, no need to create separate conn_rec. > > For now comment out all the set/get module config. > > Is there still a reason why in proxy_http the backend > connection still needs to be broken when the frontend client > breaks the connection? This behaviour was originally done > like that because there was no pool (until now :)). > I don't think so. The backend connection will have to be made using HTTP/1.1 no mater what the client actually wants. If that doesn't break any RFC then we can use that. Well, I've designed the connection pool to support that, but I've choose the conservative approach (for now :)). > In theory, as long as the backend connection is made using > HTTP/1.1, and has keepalive enabled, that keepalive > connection could be reused for other frontend connections > from different clients. > Sure, but only if that's really allowed. I'm a little bit concerned about ssl connections, but in that case we can make a decision and either bound to the client or not. I can make a configurable test solution that will allow us to test how this 'unbound mode' behaves in real-world situations. It is very easy to do (just change conn->close_on_recycle to 0). Right now it's hard-coded inside each scheme handler, but it can be set as configurable option. For serving static content from cluster of backend servers it wouldn't make a difference, not sure for other contents. Of course it would be a performance boost not needing to reconnect all the time, but rather when the backend disconnects. MT. smime.p7s Description: S/MIME cryptographic signature
Re: cvs commit: jakarta-tomcat-connectors/ajp/proxy proxy_ajp.c
[EMAIL PROTECTED] wrote: Bounding to client connection is not needed(?). Since AJP can serve multiple request trough the same backend connection, no need to create separate conn_rec. For now comment out all the set/get module config. Is there still a reason why in proxy_http the backend connection still needs to be broken when the frontend client breaks the connection? This behaviour was originally done like that because there was no pool (until now :)). In theory, as long as the backend connection is made using HTTP/1.1, and has keepalive enabled, that keepalive connection could be reused for other frontend connections from different clients. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: cvs commit: jakarta-tomcat-connectors/ajp/proxy proxy_ajp.c
Mladen Turk wrote:
[EMAIL PROTECTED] commited
+/* read the first bloc of data */
+if (bufsiz > 0) {
+status = ajp_send_data_msg(p_conn->sock, r,
Just wondering. Can we send initial POST data together with header?
Not sure what the spec are saying abut that, but think we can.
I think different versions of ajp do send the first chunk of data. Since
many POSTs are small, this can save a roundtrip. But it resulted in a
lot of patches and weird code in the retry logic.
Costin
Also I think you can use client_block logic, cause it is using the same
logic like you've witten.
Take a look at ap_get_client_block inside http_request.c
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/ajp/proxy proxy_ajp.c
[EMAIL PROTECTED] commited
>
>
> +/* read the first bloc of data */
>
> +if (bufsiz > 0) {
> +status = ajp_send_data_msg(p_conn->sock, r,
Just wondering. Can we send initial POST data together with header?
Not sure what the spec are saying abut that, but think we can.
Also I think you can use client_block logic, cause it is using the same
logic like you've witten.
Take a look at ap_get_client_block inside http_request.c
MT.
smime.p7s
Description: S/MIME cryptographic signature
Re: cvs commit: jakarta-tomcat-connectors/ajp/proxy proxy_ajp.c
Graham Leggett wrote:
[EMAIL PROTECTED] wrote:
First try to get proxy using ajp (Note that is for httpd-2.1).
Couple of comments (realising this is first try code):
/*
* Canonicalise http-like URLs.
* scheme is the scheme for the URL
* urlis the URL starting with the first '/'
* def_port is the default port for this scheme.
*/
int ap_proxy_ajp_canon(request_rec *r, char *url)
^^
As I understand it, the canonicalisation step should only try touch
ajp:// URLs (I am assuming that proxy_ajp will serve URLs with a scheme
of ajp: - is that correct?
That is correct.
{
char *host, *path, *search, sport[7];
const char *err;
const char *scheme;
apr_port_t port, def_port;
ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server,
"proxy: HTTP: canonicalising URL %s", url);
Log messages should all say proxy: AJP throughtout.
Of course ;-)
Regards,
Graham
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/ajp/proxy proxy_ajp.c
[EMAIL PROTECTED] wrote:
First try to get proxy using ajp (Note that is for httpd-2.1).
Couple of comments (realising this is first try code):
/*
* Canonicalise http-like URLs.
* scheme is the scheme for the URL
* urlis the URL starting with the first '/'
* def_port is the default port for this scheme.
*/
int ap_proxy_ajp_canon(request_rec *r, char *url)
^^
As I understand it, the canonicalisation step should only try touch
ajp:// URLs (I am assuming that proxy_ajp will serve URLs with a scheme
of ajp: - is that correct?
{
char *host, *path, *search, sport[7];
const char *err;
const char *scheme;
apr_port_t port, def_port;
ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server,
"proxy: HTTP: canonicalising URL %s", url);
Log messages should all say proxy: AJP throughtout.
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
