backend connection bucket allocator and front end connection bucket allocator.
Instead copy the buckets from the backend over to ones that have been created
using the front end bucket allocator. For metabucket this is done by recreating
them, for data buckets this is done by reading them and putting the read data
in a transient bucket.
PR: 45792
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@712375 13f79535-47bb-0310-9956-ffa450edef68
flushed by using the main requests bytes_count field instead of the
subrequest field.
* Do not reset conn->need_flush. This prevents SegFaults from not flushing
buckets in the filter chain.
PR: 45792
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@706921 13f79535-47bb-0310-9956-ffa450edef68
The call to apr_socket_timeout_set before apr_socket_connect already sets the
socket to non-blocking mode because the timeout of the socket is -1 after creation. A further
call to apr_socket_timeout_set (after the connect call does not do this, because the old
and the new timeout are >=0). The further code expects the socket to be in non-blocking
mode, otherwise we have regressions with ssl. This can be notified by running t/ssl/proxy
on 2.2.x which runs much much slower with the patch applied. This does not happen
on trunk because the socket is set back to non blocking by the core output filter
(async write completion).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@704753 13f79535-47bb-0310-9956-ffa450edef68
pooled connections if the client connection is an initial connection.
This avoids the "proxy: error reading status line from remote server"
error caused by the race condition that the backend server closed the
connection after the connection check on our side and before our data
reached the backend. Yes, this downgrades performance, especially with
HTTP/1.0 clients. Hence it is configurable and off by default.
PR: 37770
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@684351 13f79535-47bb-0310-9956-ffa450edef68
apr-util this causes a lock during shutdown as at the point of time we would
execute apr_reslist_destroy the reslist is already destroyed, because we are
in a cleanup of the same pool where the reslist registered itself as
precleanup.
With apr-util 1.3.x calling apr_reslist_destroy is not really useful and
needed in this case as we are in a cleanup that was registered against the
same pool that is used by the reslist. As it was registered *after* the
reslist was created it just runs *before* the reslist cleanup would run. This
is somewhat pointless here and we could leave the job of destroying the
reslist to the reslist cleanup.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@682369 13f79535-47bb-0310-9956-ffa450edef68
leak when connections get created and destroyed frequently by the reslist
(e.g. destroying idle elements of the reslist). So use the subpool
dedicated for the proxy_conn_rec structure to allocate the memory for the
structure itself.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@605838 13f79535-47bb-0310-9956-ffa450edef68
before that could still be buffered in the network filter. This is the case
if we have sent an EOS bucket or if we actually sent buckets with
data down the chain. In all other cases we either have not sent any
buckets at all down the chain or we only sent meta buckets that are
not EOS buckets down the chain. The only meta bucket that remains in
this case is the flush bucket which would have removed all possibly
buffered buckets in the network filter.
If we sent a flush bucket in the case where not ANY buckets were
sent down the chain, we break error handling which happens AFTER us.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@605314 13f79535-47bb-0310-9956-ffa450edef68
network filters get flushed to the network. This is needed since
these buckets have been created with the bucket allocator of the
backend connection. This allocator either gets destroyed if
conn->close is set or the worker address is not reusable which
causes the connection to the backend to be closed or it will be used
again by another frontend connection that wants to recycle the
backend connection.
In this case we could run into nasty race conditions (e.g. if the
next user of the backend connection destroys the allocator before we
sent the buckets to the network).
Remark 1: Doing a setaside does not help here as the buckets remain
created by the wrong allocator in this case.
Remark 2: Yes, this creates a possible performance penalty in the case
of pipelined requests as we may send only a small amount of data over
the wire.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@604447 13f79535-47bb-0310-9956-ffa450edef68
it was needed to register connection_cleanup as a cleanup for the frontend
connection memory pool (c->pool) to ensure that connection returns into the
connection pool if the memory pool of the frontend connection memory pool
gets destroyed / cleared. Now we ensure explicitly the connection returns
to the connection pool once we finished handling the request.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@603543 13f79535-47bb-0310-9956-ffa450edef68
data structure alive in the reslist, the live time of c->pool is too long.
r->pool has the correct live time since rp dies before r.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@603502 13f79535-47bb-0310-9956-ffa450edef68
member of the proxy_conn_rec struct as we destroy this data more frequently
than other data in the proxy_conn_rec struct like hostname and addr (at least
in the case where we have keepalive connections that timed out and were
closed by the backend).
This fixes a memory leak with short lived and broken connections.
PR: 44026
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@603237 13f79535-47bb-0310-9956-ffa450edef68
Basicly the persistence is created by keeping the conn_rec structure
created for our backend connection (whether http or https) in the connection
pool. This required to adjust scoreboard.c in a way that its functions can
properly deal with a NULL scoreboard handle by ignoring the call or returning
an error code.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@602542 13f79535-47bb-0310-9956-ffa450edef68
1 - worker->timeout
2 - proxy_conf->timeout
3 - server->timeout.
ap_get_module_config() is not perfect by that is easy to port back to 2.2.x.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@550514 13f79535-47bb-0310-9956-ffa450edef68
actually update APR and apr_socket_recvfrom()
to know about APR_MSG_OOB, APR_MSG_PEEK, etc...
this code won't need to be adjusted. Also,
make nicer for 2.2 backport.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@535354 13f79535-47bb-0310-9956-ffa450edef68
more important an error code at all, as currently APR_SUCCESS is returned
in the error case.
PR: 40865
Submitted by: Andrew Rucker Jones <arjones simultan.dyndns.org>
Reviewed by: rpluem
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@470076 13f79535-47bb-0310-9956-ffa450edef68
It works for sure on win32,linux and solaris.
I do not have access to other platforms so can not
verify it works on them.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@451896 13f79535-47bb-0310-9956-ffa450edef68
It works on win32 and linux for sure, so that's why
I put it inside the #ifdef.
Of course something like that needs APR abstraction.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@451580 13f79535-47bb-0310-9956-ffa450edef68
worker->s->status, but we need to check here if it is set in worker->status.
As PROXY_WORKER_INITIALIZED is set in worker->s->status in
ap_proxy_initialize_worker_share, which is called just before
ap_proxy_initialize_worker we never initialize the worker. This is very bad
as we create no reslist for the pool in this case.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@443503 13f79535-47bb-0310-9956-ffa450edef68