Change the balancer workers area to the address of workers instead copying the workers.
Arrange lbmethod accordingly.
Move the creation of conf->forward worker to mod_proxy child_init().
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@771940 13f79535-47bb-0310-9956-ffa450edef68
transformations which currently fail for balancer://foo targets, but
work just fine with other ProxyReverse targets.
The balancer comparison is a bit trickier. Given the context
BalancerMember balancer://alias http://example.com/foo
ProxyPassReverse /bash balancer://alias/bar
translate url http://example.com/foo/bar/that to /bash/that
E.g. there may be several different url-suffixes (1st order) of any
particular BalancerMember set e.g. /app1, /app1 and /appbeta while
there may be additional suffixes associated with the actual
ProxyPassReverse directive. Neither were properly reversed, now
both should be properly handled.
One *critical* assumption;
BalancerMember balancer://alias/foo http://example.com/bar
should be documented as a meaningless construct, since one cannot
have two members, balancer://alias/foo and balancer://alias/bar,
and the balancer member structures discard this path.
Note one more existing error case as an XXX comment due to invalid
uri comparisons.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@771587 13f79535-47bb-0310-9956-ffa450edef68
reset (initialize) and "age" their data, useful when
adding new workers, or when workers come back into
the fold....
Logic and code to come in a bit :)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@769020 13f79535-47bb-0310-9956-ffa450edef68
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
