RE: cpu 100%
Date: Thu, 31 Mar 2011 19:25:58 +0200
Subject: Re: cpu 100%
From: sor...@gmail.com
To: modules-dev@httpd.apache.org
On Thu, Mar 31, 2011 at 19:10, Niko Goutte ngou...@hotmail.com wrote:
Date: Thu, 31 Mar 2011 18:22:34 +0200
Subject: Re: cpu 100%
From: sor...@gmail.com
To: modules-dev@httpd.apache.org
---
HERE IS:
#include httpd.h
#include http_config.h
#include http_protocol.h
#include http_request.h
#include http_log.h
#include ap_compat.h
#include apr_buckets.h
#include apr_strings.h
#define ASE_FILE_SIZE512000
#define ASE_BUFFER_SIZE 104858
module AP_MODULE_DECLARE_DATA ase_mod_module;
#define ASE_MOD_HANDLER ase-mod.extensions
static int ase_mod_handler(request_rec *r)
{
apr_status_t rv = APR_SUCCESS;
apr_bucket_brigade* bb = NULL;;
apr_bucket* b = NULL;;
char filename[256];
/* First, some housekeeping. */
if (((!r-handler) != 0)|| (strcmp(r-handler, ASE_MOD_HANDLER)))
{
/* r-handler wasn't ase_mod, so it's none of our business */
ap_log_error(APLOG_MARK, APLOG_ERR, 0, r-server,Decline
processing file %s is not %s and handler %s,
r-filename,ASE_MOD_HANDLER,r-handler);
return DECLINED;
}
if (r-method_number != M_GET)
{
ap_log_error(APLOG_MARK, APLOG_ERR, 0, r-server,Error
METHOD_NOT_ALLOWED (%d),r-method_number);
return HTTP_METHOD_NOT_ALLOWED;
}
ap_log_error(APLOG_MARK, APLOG_INFO, 0,
r-server,%s,r-the_request);
// Construct filename
strncpy(filename, r-filename, sizeof(filename) / sizeof(char) - 1);
filename[sizeof(filename) / sizeof(char) - 1] = '\0';
ap_log_error(APLOG_MARK, APLOG_INFO, 0, r-server,filename =
%s,filename);
int DataSize = ASE_FILE_SIZE;
ap_set_content_type(r, video/ase);
ap_update_mtime(r, r-finfo.mtime);
ap_set_last_modified(r);
apr_table_setn(r-headers_out, Accept-Ranges, bytes);
r-vlist_validator = apr_pstrcat(r-pool, X,apr_itoa(r-pool,
DataSize), \, NULL);
ap_set_etag(r);
char content_range[64];
sprintf(content_range,bytes
%d-%d/%d,0,ASE_FILE_SIZE-1,ASE_FILE_SIZE);
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r-server,Add content range
%s,content_range);
apr_table_setn(r-headers_out, Content-Range,content_range);
r-status = HTTP_OK;
bb = apr_brigade_create(r-pool, r-connection-bucket_alloc);
char* Buf;
Buf = apr_palloc(r-pool,ASE_BUFFER_SIZE);
int size = ASE_BUFFER_SIZE;
unsigned int count = 0;
while(DataSize0)
{
if((DataSize - size)0)
{
size = DataSize;
}
memset(Buf,count,size);
b = apr_bucket_pool_create(Buf ,size, r-pool,
r-connection-bucket_alloc) ;
APR_BRIGADE_INSERT_TAIL(bb, b);
APR_BRIGADE_INSERT_TAIL(bb,apr_bucket_flush_create(bb-bucket_alloc));
if(DataSize = size)
{
APR_BRIGADE_INSERT_TAIL(bb,apr_bucket_eos_create(bb-bucket_alloc));
ap_log_error(APLOG_MARK, APLOG_INFO, 0,
r-server,APR_BRIGADE_INSERT_TAIL EOS Bucket);
}
rv = ap_pass_brigade(r-output_filters, bb);
if (rv != APR_SUCCESS)
{
ap_log_error(APLOG_MARK, APLOG_ERR, 0,
r-server,HTTP_INTERNAL_SERVER_ERROR ap_pass_brigade );
r-status = HTTP_INTERNAL_SERVER_ERROR;
return r-status;
}
DataSize = DataSize - size;
count++;
ap_log_error(APLOG_MARK, APLOG_INFO, 0,
r-server,ap_pass_brigade, DataSize = %d and Size = %d,DataSize, size
);
apr_brigade_cleanup(bb);
}
ap_log_error(APLOG_MARK, APLOG_INFO, 0, r-server,Out of While);
apr_bucket_delete(b);
Try to remove this apr_bucket_delete from here. apr_brigade_cleanup in
the while loop deletes the buckets in the brigade. I think you delete
b twice.
Sorin
That's true, I've no more the segmentation fault but in wireshark capture
on the client side, I've this error message only in prefork mode:
GET /mmrk_dummy_2mbps_10s.mmrk?TxId=8 HTTP/1.1
Range: bytes=0-511999
User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5
OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: 192.X.X.X
Accept: */*
Cache-Control: no-cache
HTTP/1.1 200 OK
Date: Thu, 31 Mar 2011 16:53:57 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Fri, 25 Mar 2011 11:18:16 GMT
Accept-Ranges: bytes
ETag: 12a8006-4e2e90-49f4cc0186e00;512000
Content-Range: bytes 0-511999/512000
Connection: close
Transfer-Encoding: chunked
Content-Type: video/ase
Re: Handling APR_HAS_LARGE_FILES
2011/3/31 Ignaz Birnstingl ign...@gmail.com: 2011/3/30 Ben Noordhuis i...@bnoordhuis.nl: On Wed, Mar 30, 2011 at 16:25, Ignaz Birnstingl ign...@gmail.com wrote: we are trying to develop a proprietary (i.e. closed-source, binary-shipped) Apache module and have run into troubles with binary incompatibilities because of APR_HAS_LARGE_FILES being either 0 or 1. I have only found http://osdir.com/ml/apache.apr.devel/2003-05/msg00028.html but this does not exactly describe our problem. The problem is that depending on APR_HAS_LARGE_FILES the sizes and offsets of structs (e.g. request_rec) change, breaking binary compatibility. Now we could compile the module twice - once with large file support and once without large file support but this leads to yet more binaries we would have to ship (32/64bit, Apache2.0/2.2, LFS=0/LFS=1). Besides, I guess most customers do not know/care if their httpd was compiled with LFS or without. So my question: How do you handle these kinds of problems? (Are there any proprietary Apache modules out there? ;-)) Are there some best practices or is there something I am missing? Is there a way to find out at run-time if httpd was compiled with LFS or without? If you have to ship a binary blob, you are probably best off shipping a module for each supported platform and supply some glue source code that loads the appropriate module at runtime, akin to what the NVIDIA Linux driver does. But if you are going to support a multitude of platforms and architectures, you really should reconsider your 'binary only' policy. I assure you support is going to be a royal pain, not to mention the irate customers. This is the voice of experience speaking. Thank you for the hint - I guess we will have to develop something like a mod_stable_abi which offers a stable binary interface (get_uri_from_request(void *request_rec), ... *sigh*), loads our blob at run-time and which can be compiled with apxs (or statically if mod_so is missing). As for shipping the source: Compiling our module is not very easy (as it is developed in C++ and incorporates different libraries, including a static version of APR 1.3.9) and definitely not possible with apxs. I don't think it would be any easier for our customers to compile it themselves besides the obvious issue that not every web server administrator has the necessary build environment installed and we do not want to support all build environments (compilers, linkers) out there. -- Ignaz Just to clarify: I confused the Windows and Unix header files when choosing the title of this discussion. What I meant was that apr_off_t gets typedef'ed to either off64_t, off_t or long. This caused the binary incompatibility at our module (we built it with apr_off_t=off64_t while on another Linux box httpd was compiled with apr_off_t=long). -- Ignaz
Changing request method
Hi all, I'm trying to write a module that will improve REST compatibility with Flex JS by implementing support for X-Http-Method-Override to change the request method when only GET/POST are the only methods supported from the client. I've read the modules book and looked through lots of other modules, but I can't figure out the right way to do this. I've implemented a input filter, but it always seems like the request has been read by the time my filter runs and I only get body content (I've tried registering it at AP_FTYPE_CONNECTION and even AP_FTYPE_CONNECTION+1, but never see the raw request) Looking at hooks, it seems like the earliest I can hook in is post_read_request; also too late. Another direction I went was to create a subrequest and execute that instead of the current request. That worked fine, but ended up executing my current request twice. Is this the right way to go? If so, 1) how do I stream data to the subrequest (e.g. POST and PUT) 2) how do I terminate the current processing chain so it stops after my subrequest (and doesn't execute again)? I tried ap_internal_fast_redirect, but that ended up crashing mod_php in the subrequest.
Re: Changing request method
Sent from my iPhone
On Apr 4, 2011, at 5:49 PM, Ben Noordhuis i...@bnoordhuis.nl wrote:
On Tue, Apr 5, 2011 at 00:10, Jason Cwik ja...@connecticinc.com wrote:
I'm trying to write a module that will improve REST compatibility with Flex
JS by implementing support for X-Http-Method-Override to change the
request method when only GET/POST are the only methods supported from the
client.
I've read the modules book and looked through lots of other modules, but I
can't figure out the right way to do this. I've implemented a input filter,
but it always seems like the request has been read by the time my filter
runs and I only get body content (I've tried registering it at
AP_FTYPE_CONNECTION and even AP_FTYPE_CONNECTION+1, but never see the raw
request)
Looking at hooks, it seems like the earliest I can hook in is
post_read_request; also too late.
Well... you can add your input filter at the end of the chain, buffer
everything until you see the X-Http-Method-Override header and then
pass on the buffered input with a modified request line. But that's a
hack and probably a can of worms, I really wouldn't recommend it.
The problem is that wherever I try to insert my filter, I don't ever seem to
see the request, I only get one bucket that contains the body. Should I be
using something other than the register input filter hook? (and then
SetInputFilter in httpd.conf)
Another direction I went was to create a subrequest and execute that instead
of the current request. That worked fine, but ended up executing my current
request twice. Is this the right way to go? If so,
1) how do I stream data to the subrequest (e.g. POST and PUT)
2) how do I terminate the current processing chain so it stops after my
subrequest (and doesn't execute again)? I tried ap_internal_fast_redirect,
but that ended up crashing mod_php in the subrequest.
Depends on what you want to do. To trick mod_php into thinking that a
POST is really a PUT, add a fixup hook where you update r-method and
r-method_number. The drawback is that you break Limit directives
this way.
Out of curiosity, why don't you handle this from within PHP itself?
if (isset($_SERVER['HTTP_X_HTTP_METHOD_OVERRIDE'])) {
$_SERVER['REQUEST_METHOD'] = $_SERVER['HTTP_X_HTTP_METHOD_OVERRIDE'];
}
That should be all it takes, right?
The problem here is that I don't have access to the web service code (it's not
really php either, I'm just using
Php for testing).
I want to implement it as a filter so it's generic and completely transparent
to the web service itself.
In the module source, r-method is const and the comments say look, but don't
touch. That said, besides breaking the limit directive will it work?
Re: svn commit: r1087862 - /httpd/httpd/trunk/modules/slotmem/mod_slotmem_shm.c
On Apr 3, 2011, at 9:36 AM, Ruediger Pluem wrote: @@ -436,6 +443,7 @@ static apr_status_t slotmem_attach(ap_sl res = (ap_slotmem_instance_t *) apr_pcalloc(gpool, sizeof(ap_slotmem_instance_t)); res-name = apr_pstrdup(gpool, fname); +res-fbased = 1; Basically, fbased is simply a flag to determine whether or not the apr_shm_create() used a real name or NULL.
Re: slotmem_plain slotmem consumers
On Apr 2, 2011, at 7:28 PM, Gregg L. Smith wrote: Nor would I expect you to. At minimum a hint in the consumers that mod_slotmem_shm should be loaded. The current error message is not very clear to a user IMO. mod_heartmonitor does this, explicitly says mod_watchdog is needed should it not be loaded also. Well, as they say in the Wizard of Oz: that's a horse of a different color. I better error message is different that simply adding in another provider, whether it works or not.
re: 5.3.6
hi, Sorry for creating a new thread, I tried to get the thread in separate mails but failed, and for the late reply. dev Digest of: get.71102_71118 Topics (messages 71102 through 71118): PHP5.3.6 -- Forwarded message -- From: Rich Bowen rbo...@rcbowen.com To: dev@httpd.apache.org Date: Fri, 18 Mar 2011 10:24:48 -0400 Subject: PHP5.3.6 I wanted to be sure that folks are aware of what's going on in the Windows/PHP world. I know that, in one sense, it's not our problem, but it *feels* like our problem to me, and to many of our users. PHP5.3.6 was just released, and the Windows binaries are built with VC9, meaning that it won't work with our Windows binaries. I know that it's been discussed before, and there's a plan to move to VC9, but as of last week, the official PHP build doesn't run with the official Apache httpd build. The PHP website recommends that folks use the Apache Lounge build. This sucks. It is nothing new, we have been provided VC9 builds since 5.3.0. As we did not initially plan to drop VC6 support in 5.3.x, we did not have any other choice at this point. It sucks that our users have to jump through additional hoops. It sucks even more that there wasn't (or at least, it appears to me that there wasn't) conversation between the two communities prior to this happening. The folks in php-land are aware that it's a problem, but don't see to really think that it's *their* problem. For our part, we seem to be unaware that anything happened. We had contacts and discussions with Bill before (his post later in this thread was by the way a surprise to me, like it was a totally new thing that php has VC9 builds for 5.3 and that we never ever discussed it and what should be done, I will reply to his reply in details and later). I'm not sure exactly what I'm suggesting we do about this. It would be nice if we could provide binaries built with VC9, or if we could recommend on the download site that people get binaries from ApacheLounge. I don't know if either of these is really an option. How would folks feel about our download site encouraging folks to use ApacheLounge's version of 2.2? I suspect that there'd be some resistance to this, based on our previous interactions with them. It is a recommendation and apachelounge can be trusted just as good as apache.org's builds. Which are, according to Bill, convenience builds not official builds. On the other hand, I'm working with the leading packager (xamp, wamp or easyphp) to get them migrate to VC9 for their 5.3 packages. Easyphp did it already, xamp will follow shortly. Like it or not, this undesired step moves the ball forward. I have a foot in the documentation team of both projects, I wonder how you did not hear about this issue in our php internals list, our RC announcements, etc. then. so I tend to hear both sides of the conversation at least from that perspective. I'd like for us to be more proactive about strengthening the community bond between us and what is probably the most important third-party Apache httpd module. There seems to be a pretty strong they don't ever listen to us attitude on both sides, and I'm not sure that it's really warranted. That's not accurate. We have discussed together about what we should do, together, sync'ed. Bill's replies so far was pretty much the same as what he has written later here. Much theories and co but no solution, alternative or even correct information or backlogs. It was also told that apache will use whatever is available at that time, which is what we did as well by the time of the 5.3.0 release. PHP next major version is another story and we are willing to be sure that such problems won't ever happen again (see below). To summarize: We have been waiting for apache for years to move to something more decent than the dead VC6. It took us a lot of resource to keep VC6 support (actually it costs me a lot of time). And that's something we/I can't afford anymore, the recent floating point bug in 5.3.5 forces us to end the VC6 support. The positive side of this move is that recent versions of VC9 gives us tools to provide CRT agnostic binaries (SxS being one). It could a very valid solution. It is also much easier to write clean enough code with these versions than with the VC6 crt (mingw included), clean enough to be loaded and used by an app compiled against a different crt (I have some VC10 php working just fine with a VC9 apache). There are a couple of things we have to take care about, but I'm confident we can solve them as well. Cheers, - Hide quoted text - -- Pierre @pierrejoye | http://blog.thepimp.net
Re: 5.3.6
On 4/4/2011 5:53 PM, Pierre Joye wrote: It is also much easier to write clean enough code with these versions than with the VC6 crt (mingw included) Just to clarify, the mingw stuff I've been watching is at msvcr80, not msvcrt. YMMV.
