[jira] Commented: (MODPYTHON-220) In PSP pages, 'import' doesn't map through to apache.import_module().
[
https://issues.apache.org/jira/browse/MODPYTHON-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506331
]
Graham Dumpleton commented on MODPYTHON-220:
Workaround is that instead of using:
import module
use:
from mod_python import apache
module = apache.import_module(module)
In PSP pages, 'import' doesn't map through to apache.import_module().
-
Key: MODPYTHON-220
URL: https://issues.apache.org/jira/browse/MODPYTHON-220
Project: mod_python
Issue Type: Improvement
Components: psp
Affects Versions: 3.3.1
Reporter: Graham Dumpleton
When Python code appears in SSI files, a trick is performed such that the
Python code in the SSI files is seen as having been originally imported using
the new module importer. This means that if 'import' is used with the Python
code, it will map through to apache.import_module() and first use that
mechanism to try and import code modules. This trick is not performed for PSP
pages however.
What needs to be done for PSP pages is the equivalent of the SSI trick:
class _InstanceInfo:
def __init__(self, label, file, cache):
self.label = label
self.file = file
self.cache = cache
self.children = {}
filter.req.ssi_globals[__file__] = filter.req.filename
filter.req.ssi_globals[__mp_info__] = _InstanceInfo(
None, filter.req.filename, None)
filter.req.ssi_globals[__mp_path__] = []
What this is doing is setting up in the environment of the SSI code object
the magic variables that 'import' hook looks for to allow it to map to
apache.import_module().
If same done in PSP pages then 'import' will map to apache.import_module()
for PSP pages also as first step.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: ProxyTimeout does not work as documented
On Mon, 2007-06-18 at 13:57 +0200, Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: Jean-Frederic Gesendet: Montag, 18. Juni 2007 12:06 An: dev@httpd.apache.org Betreff: Re: ProxyTimeout does not work as documented On Sat, 2007-06-16 at 17:40 +0200, Ruediger Pluem wrote: Digging somewhat deeper to actually do this I found the following obstacle (hopefully I am wrong): 1. The right place to fix this is in ap_proxy_connect_backend (around line 2215 in proxy_util.c). The Timeout is the Default value already See c-base_server-timeout in core_pre_connection(). This happens afterwards in ap_proxy_connection_create and not for mod_proxy_ajp as mod_proxy_ajp does not call ap_proxy_connection_create. This was fixed by your patch in r546128. Ok in AJP we really need to check the 3 timeouts. 2. We do not have a proxy_server_conf parameter in ap_proxy_connect_backend like in ap_proxy_connect_to_backend. 3. ap_proxy_connect_backend is part of a public API (mod_proxy.h). 4. Fixing the prototype of ap_proxy_connect_backend to add a proxy_server_conf parameter thus requires a major bump. Thus this would not be backportable :-(. I am not quite sure if we can do void *sconf = s-module_config; proxy_server_conf *conf = (proxy_server_conf *) ap_get_module_config(sconf, proxy_module); See modules/proxy/mod_proxy_balancer.c Thanks for the pointer, but I stick to my opinion that this is ugly there. But possibly we can go for the ugly way in 2.2.x and for the API change in trunk. BTW: ping is not documented in the 2.2 doc, why? Nobody backported the docs so far ;-). Seriously, currently I see no other reason than this. I have committed the changes in manual/mod/mod_proxy.xml Cheers Jean-Frederic Regards Rüdiger
Re: [Slightly OT] Re: httpd x64 windows binaries
I've update my page: http://www.blackdot.be/?inc=apache/binaries Would this be sufficient?
Improving trace in http-proxy
Hi,
mod_proxy_http uses ap_getline() to read from the backend but it would
be nice to have more information about what happened with the backend
server.
I would like to apply the attached patch (for trunk). The patch is need
to investigate errors like the one reported in in bugzilla 37770.
Comments?
Cheers
Jean-Frederic
Index: modules/proxy/mod_proxy_http.c
===
--- modules/proxy/mod_proxy_http.c (revision 546396)
+++ modules/proxy/mod_proxy_http.c (working copy)
@@ -1184,6 +1184,28 @@
}
static
+apr_status_t ap_proxygetline(char *s, int n, request_rec *r,
+ int fold, int *writen)
+{
+char *tmp_s = s;
+apr_status_t rv;
+apr_size_t len;
+apr_bucket_brigade *tmp_bb;
+
+tmp_bb = apr_brigade_create(r-pool, r-connection-bucket_alloc);
+rv = ap_rgetline(tmp_s, n, len, r, fold, tmp_bb);
+apr_brigade_destroy(tmp_bb);
+
+if (rv == APR_SUCCESS) {
+*writen = (int) len;
+} else {
+*writen = -1;
+}
+
+return rv;
+}
+
+static
apr_status_t ap_proxy_http_process_response(apr_pool_t * p, request_rec *r,
proxy_conn_rec *backend,
conn_rec *origin,
@@ -1215,15 +1237,17 @@
*/
rp-proxyreq = PROXYREQ_RESPONSE;
do {
+apr_status_t rc;
+
apr_brigade_cleanup(bb);
-len = ap_getline(buffer, sizeof(buffer), rp, 0);
+rc = ap_proxygetline(buffer, sizeof(buffer), rp, 0, len);
if (len == 0) {
/* handle one potential stray CRLF */
-len = ap_getline(buffer, sizeof(buffer), rp, 0);
+rc = ap_proxygetline(buffer, sizeof(buffer), rp, 0, len);
}
if (len = 0) {
-ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+ap_log_rerror(APLOG_MARK, APLOG_ERR, rc, r,
proxy: error reading status line from remote
server %s, backend-hostname);
return ap_proxyerror(r, HTTP_BAD_GATEWAY,
Mod_proxy / mod_proxy_balancer question: How to take workers gracefully out of service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, If someone has information on how to take balanced workers gracefully out of service, please let me know! I've been searching the Apache docs in vain, and Google doesn't provide an answer either. I've posted this also to the user list, but no info there, so I'm hoping to get lucky in the dev list. Thanks in advance! THE PROBLEM I am using mod_proxy to balance requests to two workers. The sessions are made sticky using a cookie CellColor. This works like a charm, so far no problems. However, here's the problem. I will occasionally need to take a worker out of service, but I will need to do so gracefully. The procedure should be: * I inform the balancer that the worker will go down eventually * As for running sessions, the balancer keeps sending them to this worker * But new sessions all go to other workers, which are not marked as will go down * I simply wait for an hour or so, until running sessions to the target worker die out * Then I can stop the worker and service it. THE CONFIGURATION Here is the balancer configuration in a lab environment. There are two sample wokers, at localhost:8010 and 8020 (the last two at 8000 and 8001 are hot-standby). Session stickiness is enforced as follows: * In the webserver at localhost:8010 a cookie is added: Header add Set-Cookie CellColor=balancer.red * And on 8020 it is: Header add Set-Cookie CellColor=balancer.blue Listen 8030 VirtualHost*:8030 # All URI's go through red or blue cell, sticky by CellColor # except for the purple manager ProxyPass /purple-manager ! ProxyPass / balancer://purple/ stickysession=CellColor \ maxattempts=3 timeout=5 # Web interface to the manager Location /purple-manager SetHandler balancer-manager Order allow,deny Allow from all /Location # Tag for passing requests Header add CellColor purple # The workers Proxy balancer://purple BalancerMember http://localhost:8010 route=red BalancerMember http://localhost:8020 route=blue BalancerMember http://localhost:8000 status=+H BalancerMember http://localhost:8001 status=+H /Proxy /VirtualHost THE QUESTION How do I take the worker at http://localhost:8010 gracefully out of service, without interrupting already running sessions? Given the above config, I can surf to http://localhost:8030/purple-manager and set the red worker to disabled, but if I do that, then all requests will immediately go to the blue worker, even if there's a cookie CellColor=balancer.red in the request. It looks as though there are only two states (enabled or disabled) while for what I want there should be one more (something like: working, but don't use it). Thanks in advance.. Karel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) iD8DBQFGd+6v23FrzRzybNURAru3AKDE+jbSQqu4pQYjDZt+jVqsU5nYwgCgm/3+ x4r2EPDXKlvbrdS0E3wl5sQ= =liab -END PGP SIGNATURE-
Re: Mod_proxy / mod_proxy_balancer question: How to take workers gracefully out of service
-Ursprüngliche Nachricht- Von: Karel Kubat Gesendet: Dienstag, 19. Juni 2007 16:57 An: dev@httpd.apache.org Betreff: Mod_proxy / mod_proxy_balancer question: How to take workers gracefully out of service 8030 VirtualHost*:8030 # All URI's go through red or blue cell, sticky by CellColor # except for the purple manager ProxyPass /purple-manager ! ProxyPass / balancer://purple/ stickysession=CellColor \ maxattempts=3 timeout=5 # Web interface to the manager Location /purple-manager SetHandler balancer-manager Order allow,deny Allow from all /Location # Tag for passing requests Header add CellColor purple # The workers Proxy balancer://purple BalancerMember http://localhost:8010 route=red BalancerMember http://localhost:8020 route=blue BalancerMember http://localhost:8000 status=+H BalancerMember http://localhost:8001 status=+H /Proxy /VirtualHost THE QUESTION How do I take the worker at http://localhost:8010 gracefully out of service, without interrupting already running sessions? Given the above config, I can surf to http://localhost:8030/purple-manager and set the red worker to disabled, but if I do that, then all requests will immediately go to the blue worker, even if there's a cookie CellColor=balancer.red in the request. It looks as though there are only two states (enabled or disabled) while for what I want there should be one more (something like: working, but don't use it). Try Proxy balancer://purple BalancerMember http://localhost:8010 route=red lbset=0 BalancerMember http://localhost:8020 route=blue lbset=0 BalancerMember http://localhost:8000 status=+H lbset=0 BalancerMember http://localhost:8001 status=+H lbset=0 /Proxy and then use the balancer manager to set the lbset for http://localhost:8010 from 0 to 1. After it all sessions for this worker died, disable it via the balancer manager. For reactivation just enable it again and set lbset to 0. Regards Rüdiger
Re: mod_proxy_ajp or mod_proxy_http?
William A. Rowe, Jr. wrote: Bill Stoddard wrote: I'm trying to understand why mod_proxy_ajp exists and what it provides that mod_proxy_http doesn't. ajp13 is a binary protocol which should make the ajp13 tomcat connector a bit more efficient than the http11 connector; an incremental performance improvement. obtained at the expense of added complexity. Does mod_proxy_ajp provide any other function not available in mod_proxy_http? I'm trying to decide which horse to put my chips on :-) If it works, mod_proxy_ajp - efficient fast and slightly easier to secure. Thanks for the info everyone! Bill, mod_proxy_ajp is easier to secure? Does mod_proxy_ajp support SSL? Bill
